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

Re: Issue with order of svn:mergeinfo revision ranges vs. svnmerge-migrate-history.py..

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 23 Jan 2009 14:36:30 -0500

On Fri, Jan 23, 2009 at 1:33 PM, Gunter Woytowitz
<Gunter.Woytowitz_at_jdsu.com> wrote:
> Hi Paul,
> I did not use the --naïve-mode, and I am positive the svnmerge-migrate-history.py script did this.


That's good news in the sense that it keeps the problem in the
migration scripts (which are small) rather than in the core code
(which isn't).

> I have just copied the one line of svn:mergeinfo that was corrupted.
> I have many (40+) branches that are branched and merged between each other like crazy. If you think it would be helpful I can track down the exact path of branches and merges given some time,

For now just two questions:

Do you have any broken history in the path with the range-overlapping
mergeinfo? By which I mean you deleted the path and later resurrected
it with some variant of 'svn copy

What was the value of the svnmerge-integrated property on the path
prior to running the migration script?

> but the short term need is to relax the error checking to allow unordered/overlapping versions on reads of svn:mergeinfo data.

I will look into this today. It's not quite as straight forward as
fixing the unordered rangelist problem (r35297). Not to bore you with
the details, but I need to deal with the potential for overlapping
ranges where one range is inheritable and the other is not...just want
to be sure not to introduce new problems while fixing old.

> BTW, I'm still not clear how a corrupted svn:mergeinfo property can be committed. Does the svnmerge-migrate-history.py script bypass these checks somehow?

It was possible due to a bug in the scripts that was recently fixed:


I'm not sure if the svnmerge/svnmerge-migrate-history*.py scripts can
still result in overlapping ranges, or if they were simply a
side-effect of the unordered ranges problem fixed in r35358.


> Thanks,
> Gunter

Received on 2009-01-23 20:38:09 CET

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