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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-04-06 04:30:46 CEST