2012/1/8 Paweł Sikora <pl...@agmk.net>:
> Hi,
>
> i've noticed that a new subversion-1.7.2 can't reintegrate a trivial branch.
Hi Paweł,
This isn't really a bug and it isn't limited to reintegrate merges.
Explanation follows below.
> attached script produces on svn-1.5.2 following correct results:
>
> $ ./merge-test.sh
> + export LANG=C
> + pwd
> + readlink -m /home/users/pluto
> + here=/home/users/pluto
> + rm -rf repo.svn repo.svn.wc repo.git
> + svnadmin create repo.svn
> + svn co file:///home/users/pluto/repo.svn repo.svn.wc
> Checked out revision 0.
> + cd repo.svn.wc
> + mkdir -p trunk branches tags
> + svn add branches tags trunk
> A branches
> A tags
> A trunk
> + svn ci -m std layout
> Adding branches
> Adding tags
> Adding trunk
>
> Committed revision 1.
> + cd trunk
> + echo foo
> + > file.txt
> + svn add file.txt
> A file.txt
> + svn ci file.txt -m foo
> Adding file.txt
> Transmitting file data .
> Committed revision 2.
> + cd ..
> + svn cp trunk branches/feature-bar
You don't update your working copy here, so you are copying a
mixed-revision tree; trunk itself is at r1 and trunk/file.txt is at
r2. This is clear from the log for r3:
svn.1.5.7-client>svn log -v -r3
------------------------------------------------------------------------
r3 | pburba | 2012-01-10 16:15:17 -0500 (Tue, 10 Jan 2012) | 1 line
Changed paths:
A /branches/feature-bar (from /trunk:1)
A /branches/feature-bar/file.txt (from /trunk/file.txt:2)
bar feature branch
------------------------------------------------------------------------
This is exactly the same as if you branched trunk@1 to
branches/feature-bar and then then copied trunk/file.txt@2 to
branches/feature-bar/file.txt.
Copying a mixed-revision working copy is usually a bad idea and often
lead to non-obvious results with mergetracking. So unless you have a
good reason for doing so they should be avoided.
If all you want to know how to avoid this, just update your working
copy to a uniform revision before doing WC-to-WC branches or use a
URL-to-URL copy. Everything that follows is the "long answer" :-)
> A branches/feature-bar
> + svn ci branches -m bar feature branch
> Adding branches/feature-bar
> Adding branches/feature-bar/file.txt
>
> Committed revision 3.
> + svn up
> At revision 3.
> + cd trunk
> + svn merge --reintegrate
> file:///home/users/pluto/repo.svn/branches/feature-bar .
> --- Merging differences between repository URLs into '.':
> A file.txt
> U .
Since your branch root is a copy of trunk@1 the reintegrate merge
tries to merge the difference between ^/trunk@1 and
^/branches/feature-bar@HEAD into the trunk working copy. Which is why
we see r2, the addition of file.txt, merged as a result. That file
already exists in trunk of course, so it is a no-op (though if we had
edited file.txt on trunk the merge would result in a text conflict).
svn.1.5.7-client>svn merge %URL%/branches/feature-bar . --reintegrate
--- Merging differences between repository URLs into '.':
A file.txt
Notice the noop (except for the mergeinfo change):
>svn st
M .
And that mergeinfo change shows that r2 was merged from the branch:
svn.1.5.7-client>svn diff
Property changes on: .
___________________________________________________________________
Added: svn:mergeinfo
Merged /branches/feature-bar:r2-3
> + svn ci -m merge feature bar
> Sending trunk
>
> Committed revision 4.
> + cd ..
>
>
> but on svn-1.7.2 it fails:
>
> $ ./merge-test.sh
> + export LANG=C
> + pwd
> + readlink -m /home/users/pluto/src/git-svn-test
> + here=/home/users/pluto/src/git-svn-test
> + rm -rf repo.svn repo.svn.wc repo.git
> + svnadmin create repo.svn
> + svn co file:///home/users/pluto/src/git-svn-test/repo.svn repo.svn.wc
> Checked out revision 0.
> + cd repo.svn.wc
> + mkdir -p trunk branches tags
> + svn add branches tags trunk
> A branches
> A tags
> A trunk
> + svn ci -m std layout
> Adding branches
> Adding tags
> Adding trunk
>
> Committed revision 1.
> + cd trunk
> + echo foo
> + >file.txt
> + svn add file.txt
> A file.txt
> + svn ci file.txt -m foo
> Adding file.txt
> Transmitting file data .
> Committed revision 2.
> + cd ..
> + svn cp trunk branches/feature-bar
> A branches/feature-bar
> + svn ci branches -m bar feature branch
> Adding branches/feature-bar
> Adding branches/feature-bar/file.txt
>
> Committed revision 3.
> + svn up
> Updating '.':
> At revision 3.
> + cd trunk
Ok, now on to 1.7. The exact same thing as above is happening, it's
just that in 1.6 we introduced the concept of tree conflicts, so the
previous no-op addition of file.txt is now caught as a tree conflict:
> + svn merge --reintegrate
> file:///home/users/pluto/src/git-svn-test/repo.svn/branches/feature-bar .
> --- Merging differences between repository URLs into '.':
> C file.txt
> --- Recording mergeinfo for merge between repository URLs into '.':
> U .
> Summary of conflicts:
> Tree conflicts: 1
Notice that status tells us exactly what the problem is:
1.7-client>svn st
M .
A + trunk
C file.txt
> local add, incoming add upon merge
Summary of conflicts:
Tree conflicts: 1
So in conclusion, the merge is doing exactly what we ask it.
Paul
> + svn ci -m merge feature bar
> svn: E155015: Commit failed (details follow):
> svn: E155015: Aborting commit:
> '/home/users/pluto/src/git-svn-test/repo.svn.wc/trunk/file.txt' remains in
> conflict
> + cd ..
>
>
> BR,
> Paweł.
>
> please CC me on reply.
