On Wed, Apr 27, 2011 at 1:40 PM, Philip Martin
<philip.martin_at_wandisco.com> 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
>
Received on 2011-05-02 17:39:53 CEST