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)? -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
