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)?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand