[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn branching/merging regression.

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 10 Jan 2012 18:40:50 -0500

2012/1/8 Paweł Sikora <pluto_at_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_at_1 to
branches/feature-bar and then then copied trunk/file.txt_at_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_at_1 the reintegrate merge
tries to merge the difference between ^/trunk_at_1 and
^/branches/feature-bar_at_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.
Received on 2012-01-11 00:41:23 CET

This is an archived mail posted to the Subversion Dev mailing list.