Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > RE: HEADS UP: Damaged mergeinfo in our history; likely pain in our future.

subversion
Discussion topic

Back to topic list

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

Author rhuijben
Full name Bert Huijben
Date 2009-12-10 01:25:10 PST
Message > -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato at collab dot 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:8​72050-872529
> subversion/branches/​diff-callbacks3:8700​59-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

« Previous message in topic | 1 of 3 | Next message in topic »

Messages

Show all messages in topic

RE: HEADS UP: Damaged mergeinfo in our history; likely pain in our future. rhuijben Bert Huijben 2009-12-10 01:25:10 PST
     Re: HEADS UP: Damaged mergeinfo in our history; likely pain in our future. Paul Burba <ptburba at gmail dot com> Paul Burba <ptburba at gmail dot com> 2009-12-10 08:47:23 PST
         Re: HEADS UP: Damaged mergeinfo in our history; likely pain in our future. cmpilato C. Michael Pilato 2009-12-10 09:12:10 PST
Messages per page: