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

Paul,

Your suspicion is correct, there was a "broken" history, here's a snippet from the logs where the copy occurred.

----------------------------------------------------
r49990 | asdf | 2006-10-12 08:38:59 -0400 (Thu, 12 Oct 2006) | 1 line
Changed paths:
   A /branches/branch1 (from /branches/branch1:49987)
----------------------------------------------------

The branch was accidentally deleted, and then restored a few revs later.

The svnmerge-integrated property before running the script was
/branches/branch1:1-53669

I'm not sure you understood my question about error checking of svn:mergeinfo on commits and the svnmerge-migrate-history.py script, so I'll try to restate it.

My general thought is that there should be no way for the migrate script to commit an invalid svn:mergeinfo property to the repository. I expect there to be bugs in 3rd party scripts, especially with a new complex feature, but I also expect the subversion code should be a bit more robust and protect itself from this by blocking any commits that contain invalid svn:mergeinfo properties. It seems like there is a lot of error checking of the svn:mergeinfo property when "reading" the data (ie. the errors I'm seeing), but not when the property was "written" to the repository. Are there svn:mergeinfo property checks in the subversion code on commits? If yes, how did the migrate script bypass them? If no, then the checks should be added.

Thanks,
Gunter

-----Original Message-----
From: Paul Burba [mailto:ptburba_at_gmail.com]
Sent: Friday, January 23, 2009 2:37 PM
To: Gunter Woytowitz
Cc: users_at_subversion.tigris.org; dev_at_subversion.tigris.org
Subject: Re: Issue with order of svn:mergeinfo revision ranges vs. svnmerge-migrate-history.py..

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.

Gunter,

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
DELETED_BRANCH_at_REV_BRANCH_STILL_EXISTED'.

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:

http://svn.collab.net/viewvc/svn?view=revision&revision=35358

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.

Paul

>
> Thanks,
> Gunter

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1045338

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-23 21:24:53 CET