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

"log -g" and multiple merge routes

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 15 May 2012 14:59:55 +0100

This may not be a strictly supported scenario but it is the sort of
thing users do.

We have a trunk 'A' and 3 branches 'X', 'Y' and 'Z'. A change on 'X' is
merged to 'Y' and 'Z' and then 'Y' and 'Z' are merged back to 'A'.

svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svnmucc -mm -- put - file://`pwd`/repo/A/f <<EOD
Af
EOD
svn cp -mm file://`pwd`/repo/A ^/X
svn cp -mm file://`pwd`/repo/A ^/Y
svn cp -mm file://`pwd`/repo/A ^/Z
svnmucc -mm -- put - file://`pwd`/repo/X/f <<EOD
Af2
EOD
svn co file://`pwd`/repo/Y wc
svn merge ^/X wc
svn ci -mm wc
svn sw ^/Z wc
svn merge ^/X wc
svn ci -mm wc
svn sw ^/A wc
svn merge --reintegrate ^/Y wc
svn ci -mm wc # r9
svn sw ^/A wc
svn merge --reintegrate ^/Z wc
svn ci -mm wc # r10

r6 is the change to the file on branch X. The r9 merge changes
svn:mergeinfo on A to include /X:6 so when I run 'svn log -gr9' I see
the r6 change getting merged via r9.

Now /X:6 is also a change made to Z but the r10 merge cannot add /X:6 to
A since it is already present. However 'svn log -gr10' still shows r6
as the "log -g" follows the mergeinfo change to Z where the r6 change is
present.

I don't really know whether "log -g" is doing the right thing here. Is
this simply an unsupported scenario? Is it doing the right thing and
showing that r6 could have been merged via r10? Is it doing the wrong
thing by showing r6 for r10? If it's doing the wrong thing does that
mean that the "log -g" should not be recursing but should only be
looking at the first level of mergeinfo changes?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-05-15 16:00:32 CEST

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.