RE: HEADS UP: Damaged mergeinfo in our history; likely pain in our future.

> -----Original Message-----
> From: C. Michael Pilato [mailto:[email protected]]
> Sent: woensdag 9 december 2009 22:08
> To: Subversion Development
> Subject: HEADS UP: Damaged mergeinfo in our history; likely pain in our
> future.
> 
> 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)?

I think we can (and probably should) be a bit more flexible here. I don't see major issues in accepting paths without a '/' here.

I would actually prefer repository root relative paths without '/', but we can't change the design on these values. (The new svn_relpath_ functions should be used on them but can't because they have a leading '/')

I hope we can fix this by just updating the code that parses the property into our internal representation, but I think Paul can answer that easily.

	Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2429139

Please start new threads on the <[email protected]> mailing list.
To subscribe to the new list, send an empty e-mail to <[email protected]>.