On Wed, Apr 27, 2011 at 1:40 PM, Philip Martin <[email protected]> wrote: > I was looking at the fix for issue 3650, "log -g duplicate output" > > http://subversion.tigris.org/issues/show_bug.cgi?id=3650 > > which is marked fixed and nominated for 1.6. I don't understand whether > the 1.7 output is correct or not because I don't know what log -g is > expected to produce. > > Here's my script. It creates a file "A/f" and then modifies it on two > branches "X/f" and "Y/f" which both get merged back to "A/f". > > #!/bin/sh -e > svn=svn > svnadmin=svnadmin > svnmucc=svnmucc > url=file:///`pwd`/repo > rm -rf repo wc > $svnadmin create repo > $svn mkdir -mm $url/A > $svnmucc -mm -- put - $url/A/f <<EOD > Af > x > Af > y > Af > EOD > $svn cp -mm $url/A $url/X > $svnmucc -mm -- put - $url/X/f <<EOD > Af > xxxx > Af > y > Af > EOD > $svn cp -mm $url/A $url/Y > $svnmucc -mm -- put - $url/Y/f <<EOD > Af > x > Af > yyyy > Af > EOD > $svn co $url/A wc > $svn merge --reintegrate ^/X wc > $svn ci -mm wc > $svn sw $url/Y wc > $svn merge ^/A wc > $svn ci -mm wc > $svn sw $url/A wc > $svn merge --reintegrate ^/Y wc > $svn ci -mm wc > > > Running "svn log -gvq file://`pwd`/repo/A/f" using 1.6 gives duplicate > output and the duplication is indeed reduced in 1.7, but 1.7 still has > duplicates: > > ------------------------------------------------------------------------ > r9 | pm | 2011-04-27 18:09:18 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /A > M /A/f > ------------------------------------------------------------------------ > r8 | pm | 2011-04-27 18:09:15 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /Y > M /Y/f > Merged via: r9 > ------------------------------------------------------------------------ > r7 | pm | 2011-04-27 18:09:12 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /A > M /A/f > Merged via: r9, r8 > ------------------------------------------------------------------------ > r4 | pm | 2011-04-27 18:09:09 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /X/f > Merged via: r9, r8, r7 > ------------------------------------------------------------------------ > r3 | pm | 2011-04-27 18:09:09 +0100 (Wed, 27 Apr 2011) > Changed paths: > A /X (from /A:2) > Merged via: r9, r8, r7 > ------------------------------------------------------------------------ > r6 | pm | 2011-04-27 18:09:10 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /Y/f > Merged via: r9 > ------------------------------------------------------------------------ > r5 | pm | 2011-04-27 18:09:09 +0100 (Wed, 27 Apr 2011) > Changed paths: > A /Y (from /A:4) > Merged via: r9 > ------------------------------------------------------------------------ > r7 | pm | 2011-04-27 18:09:12 +0100 (Wed, 27 Apr 2011) > Changed paths: > M /A > M /A/f > ------------------------------------------------------------------------ > r2 | pm | 2011-04-27 18:09:09 +0100 (Wed, 27 Apr 2011) > Changed paths: > A /A/f > ------------------------------------------------------------------------ > > r7 appears twice, one instance is a direct change to A/f, the other is > via merge. Is it correct that r7 should appear twice?
Hi Philip, r7 (the reintegration of ^/X to ^/A) appears twice because revision 7 touches more than the log target ^/A/f, it effects ^/A too. That matters because the smallest unit merge tracking tracks is a revision. Let me hopefully explain what I mean using your example: In your script the change to ^/A is only the recording of mergeinfo describing the reintegration. We could safely drop it from the list of "merged via" revs without losing any meaning since r7 is part of ^/A/f's natural history and will eventually be listed in the log. But what if r7 included a change outside of ^/A, how do we know if that part of r7 was merged to ^/A/f? The current code errs on the side of caution and includes it in the "merged via" list for this reason. To differentiate between the two cases would require that we have a way to determine if a given revision really was merged, regardless of what the mergeinfo implies. And that gets to the heart of http://subversion.tigris.org/issues/show_bug.cgi?id=2897, which has proven rather difficult to address within the current merge tracking design. > The other confusing thing is that branch creations, r3 and r5, appear in > the output although the file was not modified in those revisions. Is it > correct for those revisions to appear? A similar problem, paraphrasing http://subversion.tigris.org/issues/show_bug.cgi?id=3650#desc5: Revs 3 and 5 in your example are only copies, but they could easily contain changes in addition to the copy. Since we are dealing with revisions as the smallest divisible unit that merge-tracking tracks, we err on the side of safety and include those revisions. Paul > -- > Philip >
