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

Re: Do we need to store redundant mergeinfo?

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 10 Nov 2011 18:13:02 +0000

Mark Phippard <markphip_at_gmail.com> writes:

> On Thu, Nov 10, 2011 at 12:13 PM, Julian Foad <julian.foad_at_wandisco.com>wrote:
>> 2 3 4 5
>> BranchA--o-----------------------------------------
>> \
>> \ "A:2"
>> BranchB-----o---o----------------------------------
>> \
>> \ "A:2 B:3-4"
>> BranchC------------o-------------------------------
>> Philip and I were prompted by a customer to consider why Subversion copies
>> mergeinfo from branch to branch, in transitive merges (branch A -> branch B
>> -> branch C). Why do we need mergeinfo on branch C that refers directly to
>> A? If, as I believe to be the case, Subversion only supports merge
>> tracking if the branching graph is tree-shaped, then the only merges
>> allowed to or from branch C are those to or from branch B (and those to or
>> any further branches to the "right" of it: D1, D2).
> This statement is not true. You can still merge BranchA to BranchC in the
> above scenario. SVN does not have any limits on where you can merge from
> and to.

Yes, Subversion allows one do it, but it doesn't work reliably. It's
the standard cyclic merge problem. If we mix merges that go A-to-B-to-C
with merges from A-to-C then conflicts can occur. You must know this:

svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svn cp -mm file://`pwd`/repo/A ^/B
svn cp -mm file://`pwd`/repo/A ^/C
svn mkdir -mm file://`pwd`/repo/A/Q1
svn mkdir -mm file://`pwd`/repo/A/Q2
svn co file://`pwd`/repo/B wc
svn merge ^/A_at_4 wc # A-to-B
svn ci -mm wc
svn sw ^/C wc
svn merge ^/B wc # (A-to-)B-to-C
svn ci -mm wc
svn merge ^/A wc # A-to-C
svn ci -mm wc
svn sw ^/B wc
svn merge ^/A wc # A-to-B
svn ci -mm wc
svn sw ^/C wc
svn merge ^/B wc # (A-to-)B-to-C conflict!

This is a known limitation of merge tracking. How can the user avoid
such problems? The only real way is to avoiding cyclic merges. If we
start from the premise that the user should not do cyclic merges because
of the limitations of merge tracking then the redundant info has no
benefit. The only time the redundant info is useful is when the user is
doing merges that don't always "work".

uberSVN: Apache Subversion Made Easy
Received on 2011-11-10 19:13:42 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.