Paul Burba wrote: > P.S. There are clearly some opportunities in this code to be more > conservative in requesting access to the repos root. If > REPOS_REL_PATH has explicit mergeinfo we only need access to that > path. Only if it has none and we need to find inherited mergeinfo do > we need access further up the repos tree...and even then we'd never > need access to the root (since how can it have an mergeinfo?). > > Ideally we could check REPOS_REL_PATH for mergeinfo, if we found none > then reparent to REPOS_REL_PATH's immediate parent and check that, and > repeat as needed. Of course that is not going to do any favors to > performance. Regardless, these are changes that need to be made on > trunk; libsvn_client:mergeinfo.c:get_mergeinfo() on 1.6.x is > completely broken right now when operating on a URL.
As was discussed in IRC today, the whole point of the issue #3242 backport
was to be "more conservative in requesting access to the repos root", so
we'd really prefer to take that option.
Unfortunately, making that correction has taken me into a rat's nest of code
problems. Let's see if I can enumerate them:
1. All the RA layers depend on a helper function
svn_mergeinfo__remove_prefix_from_catalog() to convert repos abspaths
into paths relative to the session baton. Unfortunately, that function
is a touch braindead and doesn't return consistent relpaths at all.
2. libsvn_client/mergeinfo.c:get_mergeinfo(), which is used by several
public APIs, claims to return a catalog keyed on repository relpaths.
But in the is_url case, it ... uh ... doesn't.
I'm currently looking into both of these problems, but clearly won't make
any more progress tonight.
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
