[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 11:29:11 -0500

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


Received on 2009-01-23 17:30:17 CET

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