On Fri, Jul 27, 2012 at 08:03:22AM -0700, Arunmozhi wrote:
>
> I am resending the initial mail as the mail format other than text is not supported.
>
> I feel that the SVN branching and merging/integration algorithm is
> flawed. However I am not sure if this is a known limitation of SVN. I
> did 2 tests to compare SVN against Perforce/git. The intention of the test
> is to see if a change done by a user at some point in time and taken to
> multiple branches comes back to the main branch duplicated multiple
> times without indicating a conflict.
>
> Please look into the attached tests.txt. Each column shows the contents of a file as we
> do successive changes to the file. Also please refer below the explanatory steps.
>
> I use tortoisesvn 1.7.5 as the user interface and hence I can just list
>
> the menu commands corresponding to each step and not the exact SVN
> commands (I am not used to the command line). The following are the
> steps I executed for Test 1.
>
> (1) Create a file myfile.txt with following contents and add it to the repository (TortoiseSVN -> Add, SVN Commit).
> a
> b
> c
> z
>
> (2) Branch the file myfile.txt to a new location (TortoiseSVN -> Branch/Tag
> (From:myfile.txt To:branch1/myfile.txt), SVN update). Now the contents
> of branch1/myfile.txt is
> a
> b
> c
> z
>
> (3) Edit the branch1/myfile.txt by inserting a line 'd' as follows and then commit the changes (SVN Commit). Now the contents of branch1/myfile.txt is
> a
> b
> c
> d
> z
>
> (4) Now branch the file branch1/myfile.txt to branch2/myfile.txt (TortoiseSVN -> Branch/Tag (From:branch1/myfile.txt To:branch2/myfile.txt), SVN update). Now the contents of branch2/myfile.txt is
> a
> b
> c
> d
> z
>
> (5) Now edit the file branch2/myfile.txt by changing the 'c' to 'x' and
> then commit the changes (SVN commit). Now the contents of branch2/myfile.txt is
> a
> b
> x
> d
> z
>
> (6) Now integrate the branch1/myfile.txt back to myfile.txt (TortoiseSVN
> -> Merge (Reintegrate a branch From:branch1/myfile.txt To working
> copy:myfile.txt), SVN commit). Now the contents of myfile.txt is
> a
> b
> c
> d
> z
>
> (7) Now integrate the branch2/myfile.txt back to myfile.txt (TortoiseSVN -> Merge (Reintegrate a branch From:branch2/myfile.txt To working copy:myfile.txt), SVN commit). Now the contents of myfile.txt is
> a
> b
> x
> d
> d
> z
>
> You can see that the line 'd' appears twice in the integrated file. 'd' is
> inserted only once in the revision history. The expected output
> (verified in perforce and git) is
> a
> b
> x
> d
> z
Yes, I can see the problem now, thanks.
I suppose it depends on the way Subversion selects a common ancestor to
use as merge base. Git, perforce and svn internally all use the diff3
algorithm to perform file merges. The result of that algorithm depends
on the set of input files, often called "base", "merge-left", "merge-right",
where the merge-left and merge-right version of the file are both derived
from the same "base" file. Subversion's selection of the common ancestor
(the "base") is affected by mergeinfo. The order in which merges are
performed matters since it affects merge-tracking information present
during the final merge.
If you reintegrate branch2/myfile.txt into branch1/myfile.txt first,
and then reintegrate branch1/myfile.txt to /myfile.txt, the result
of the last merge is the same as with git and perforce:
$ svn diff
Index: myfile.txt
===================================================================
--- myfile.txt (revision 7)
+++ myfile.txt (working copy)
@@ -1,4 +1,5 @@
a
b
-c
+x
+d
z
If you want to understand in more detail how Subversion's merges behaves
I'd recommend reading http://wiki.apache.org/subversion/SymmetricMerge
Git and perforce perform merge-tracking in a different way, and might
always select the same common ancestor independently of the order merges
are performed in.
Received on 2012-07-31 15:53:12 CEST