Merge Scenario & Expectations

I was talking with a co-worker today about Subversion and
merges.  He  
is evaluating other version control systems for a possible
move away  
from Subversion.  Lack of integrated merge tracking is a
huge issue  
-- I encouraged him to hold out for Subversion 1.5 before
making any  
final decisions.

In the course of our discussion, he brought up one of the
test  
scenarios he's using to evaluate the different version
control  
systems.  Subversion (at least in 1.4.x) does not currently
pass his  
test, so I thought it would be worthwhile sharing the test.

Step 1:
Create a branch1 area containing:
file1: contents "file1"
file2: contents "file2"

Step 2:
Copy branch1 to branch2

Step 3:
In a working copy of branch1:
rename file1 to newfile1
add a line change2 to file2
check in these changes

Step 4:
In a working copy of branch2
add a line change1 to file1
rename file2 to newfile2
check in these changes

Step 5:
Merge the changes from Step 3 into branch2

His expectation at this point is that branch2 will now
contain:
newfile1: contents "file1nchange1"
newfile2: contents "file2nchange2"

But that is not what happens.

Here is a simple bash shell script that demonstrates this
situation  
using svnmerge.py to provide the correct revision range for
the merge  
in Step 5:

# create a test repository in /tmp
svnadmin create /tmp/svntest
REPO=file:///tmp/svntest

# Step 1
svn mkdir -mbranch1 $REPO/branch1
svn co $REPO/branch1 && cd branch1
echo file1 > file1
echo file2 > file2
svn add file1 file2
svn ci -mfiles
cd ..

# Step 2
svn cp -mbranch2 $REPO/branch1 $REPO/branch2
svn co $REPO/branch2 && cd branch2
svnmerge.py init
svn ci -mtracking

# Step 3
cd ../branch1
svn mv file1 newfile1
echo change2 >> file2
svn ci -mchange1

# Step 4
cd ../branch2
echo change1 >> file1
svn mv file2 newfile2
svn ci -mchange2

# Step 5
svnmerge.py -s merge

# At this point what you have in branch2 wc
# is almost certainly not what you want

Is Subversion 1.5 expected to do a better job handling this
scenario  
or is this sort of merging-of-renamed-items still further on
down the  
roadmap?

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

This scenario isn't actually a merge deficiency, but a
deficiency in
the way in which the server applies changes to the working
copy in
*any* scenario.  It happens, for example, in basic updates. 
If your
friend commits a change that renames file1 to newfile1, and
you have a
local edit on your private file1, then 'svn up' won't
actually rename
your edited file1 to newfile1;  instead, it will delete your
edited
file1 (making it unversioned, since it has edits), and
"add" a new
file from the server called newfile1, which has the old file
contents.

This problem stems from two deeper flaws:

1. svn doesn't have moves, it has copy+delete.

2. The server should be telling the client, "copy the
file you already
have to a new name", rather than just "here's a
new file" (which just
happens to have been copied from some other repository
file.)

So this isn't so much a merge-tracking issue, as it is a
"flaw in
updates" issue.  And it's well known.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org