[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 09 Dec 2009 16:08:11 -0500

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 .

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

Received on 2009-12-09 22:08:54 CET

This is an archived mail posted to the Subversion Dev mailing list.