> at the last rev in the search range and works backwards, looking for the

> last time a path existed. In the above scenario this takes a long time
> because a 50k rev files need to be opened. At the time I'd thought the
> linear was the only way to go because a path might be deleted, re-added
> and deleted many times, so a binary search wouldn't work. But as Mark
> pointed out to me, we don't really care if a path of the same name was
> later added then deleted, that is for the path's parent to care about in

For anyone who missed it, we discussed this patch at length on IRC on
10/27:

Essentially the conclusion was that a binary search would work to find the
*first* time a path was deleted. Problem was, my binary search algorithm
in r22139 made incorrect assumptions about how svn_fs_compare_ids()
behaved when comparing copied/modified nodes. I addressed these problems
in r22234 of svn/branches/ood-status-info. I also made an effort to
clearly document how the binary search works in the comments for
svn_repos_deleted_rev()...it might be worth look at those comments first
if you have any questions on this.