On Wed, Dec 9, 2009 at 4:08 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> While trying to figure out why my attempt at performing a catch-up merge of
> the 'issue-3242-dev' branch with ^/subversion/trunk was conflicting like
> crazy for me today, I discovered something unhappy:
>
> $ svn pget svn:mergeinfo .
> subversion/branches/1.5.x-r30215:870312
> subversion/branches/bdb-reverse-deltas:872050-872529
> subversion/branches/diff-callbacks3:870059-870761
> [...]
>
> See the leading slashes on those mergeinfo paths? Oh, that's right, you
> can't see them *because they aren't there*!
>
> A quick glance at the code behind 'svnadmin load --parent-dir' which is
> supposed to prepend the parent directory onto each of the mergeinfo paths
> confirms that the code naively does this prepending without any attention to
> the possibility that the parent directory lacks a leading slash. While
> that's not an errorful situation in general (parent_dir lacking the leading
> slash), the slash-less value certainly should have been detected and
> corrected before being used in a storage format that cares deeply about such
> things (like our svn:mergeinfo property format does).
>
> So. Bug in libsvn_repos loading code. Filed as issue #3547. I'm testing a
> fix for that now.
>
> But the bigger question is, "Where do we go from here?" I suspect that
> *all* of our repository-stored mergeinfo -- the entire history thereof -- is
> technically, syntactically invalid at this point. Do we try to repair it?
> Or do we take this opportunity to make our merge tracking code a little more
> ... flexible (always storing one format, but accepting either)?
Looking into making the code tolerant of either (i.e. always treating
it as repos absolute regardless of the leading slash).
Paul
Received on 2009-12-09 22:14:30 CET