On Wed, Dec 9, 2009 at 4:08 PM, C. Michael Pilato <cmpil...@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
