"log -g" and multiple merge routes

[Philip Martin <ph...@wandisco.com>]

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