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
