[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.6.10 up for testing/signing

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 6 Apr 2010 11:59:42 +0200

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
Received on 2010-04-06 12:00:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.