On Mon, Apr 05, 2010 at 10:30:06PM -0400, C. Michael Pilato wrote: > 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.
Should we delay the #3242 fix until 1.6.12 and release 1.6.11 ASAP? That would give us plenty of time to do the #3242 backport properly, and would give users access to the other 1.6.11 backport items. Stefan
