> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> 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 <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.
Received on 2009-12-10 10:25:26 CET