Hi Paul,
I did not use the --naïve-mode, and I am positive the svnmerge-migrate-history.py script did this.
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, but the short term need is to relax the error checking to allow unordered/overlapping versions on reads of svn:mergeinfo data.
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?
Thanks,
Gunter
-----Original Message-----
From: Paul Burba [mailto:ptburba_at_gmail.com]
Sent: Friday, January 23, 2009 11:29 AM
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 Thu, Jan 22, 2009 at 3:11 PM, Gunter Woytowitz
<gunter.woytowitz_at_jdsu.com> wrote:
> I have the same problem with out of order AND overlapping svn:mergeinfo properties created by the svnmerge-migrate-history.py script. The problem is that I was not aware of the error for some time and many revisions were commited to the repository with improper svn:mergeinfo data. I have since fixed the invalid svn:mergeinfo properties, but now when someone tries to merge older revisions with a "bad" svn:mergeinfo property I get the "out of order" or "overlapping" revision errors.
>
> THIS IS A HUGE PROBLEM FOR ME!!
>
> Here's the svn:mergeinfo property that's giving me problems.
>
> /branches/branch1:43832-45742,49990-53669,43832-49987
>
> As you can see it is both out of order (43832 is after 53669) and overlapping (43832-45742 overlaps 43832-49987)
>
> This issue and a partial fix for it is discussed in Issue# 3302.
> Here's a copy of the comment of interest for this Issue
>
> ------- Additional comments from Paul T. Burba Fri Jan 16 17:54:55 -0800 2009 -------
>
> In r35297 I loosened svn_mergeinfo_parse()'s restrictions on unsorted
> rangelists. It now tolerates them, but still returns mergeinfo with a sorted
> rangelist.
> --------------------
>
> I have built subversion from sources using the latest trunk revision (r35389), which has the above mentioned change in it. This fixes the "out of order" problem, but not the "overlapping" problem.
>
> The subversion code needs to be modified to relax the tests for overlapping revisions too.
>
> I would accept, as a temporary workaround, some way to completely disable all svn:mergeinfo processing and make the svn client behave as if the repository format was rev 4 instead of rev 5. I would lose svn:mergeinfo data, but at this point I just need to get a merge done!!!
>
> Please help, I need this fixed ASAP!!!
Hi Gunter,
I am looking into this right now.
A few quick questions:
Do you recall if you used the --naive-mode option when running the
svnmerge-migrate-history.py script?
You say that the "overlapping svn:mergeinfo properties (were) created
by the svnmerge-migrate-history.py script". You are absolutely sure
of this, you checked the logs/diffs and saw that it came into being
when you committed the changes made by the
svnmerge-migrate-history.py? Forgive me for questioning your fairly
clear statement, I just want to be absolutely sure I shouldn't be
looking for a bug in the core Subversion code that created this
overlapping mergeinfo!
The path that the mergeinfo
'/branches/branch1:43832-45742,49990-53669,43832-49987' is set on,
let's call it 'N'. Was '/branches/branch1' copied from N or was N
copied from '/branches/branch1'?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1045182
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-23 19:36:23 CET