views:

65

answers:

4

I have seen where changes have been made on one code file by two developers code like this:

x++

End up like this:

x++
x++

where due to carriage returns being inserted/removed (I think) one line has become silently merged as two lines of the same code (no conflicts) Everything compiles but suddenly tests are failing and weird behaviour ensues.

Should this be possible? How do I guard against it?

+1  A: 

It certainly should not be possible. SVN merge usually recognizes that the same change has already been made locally. Even if line-breaks change, it should at least recognize the changed context and fail.

You can guard against this by checking the diffs before actually committing, and by automatic tests (as you already did).

Can you reproduce this behavior?

Peter Lang
Not re-producible yet. I'm fairly certain it's us being dumb-asses somewhere. I'm no SVN guru I'm trying to track back through the log to see how it was introduced. I thought it may have occured on a branch merge back to trunk, but it's looking like it occured in the branch before coming back into the trunk.
HollyStyles
+1  A: 

I've seen this where merges have gone wrong, and somebody has resolved the conflict, deleted the two merge versions and committed the main file which has still got both versions merged together (as you are supposed to tell SVN which is correct.)

Andy Shellam
Hmm yeah manually resolved conflicts, how do I find that action in SVN history?
HollyStyles
We've always seen other indicators, like the presence if <<<< REVISION 96 MINE (or something similar.) (One mistake actually made it into production once - it was an auto-updating website.) If this is the case with you, the committer could have stripped these out manually and not noticed this duplication, in which case there's no way to check - just watch out for it again and catch it as early as possible, then you can ask the committer who may remember ("ooh yeah, it did do something weird...")
Andy Shellam
+2  A: 

To avoid merging problems due to line endings, just set the svn:eol-style property on those files.

Stefan
Wow the lead dev himself! Hi. Will check out this property although I don't think line endings are my issue, but they just might be.
HollyStyles
+1  A: 

This shouldn't be a problem, unless the developer doing the merge marks the conflict as resolved without reviewing it. SVN will always warn about a conflict.

Careful merge tracking, which is required anyway, should avoid any problems.

Also, a small test shows that SVN is smart enough to avoid conflicting if the changes being merged have been already applied already.

The following example (warning, messes up with the current directory; requires Unix-like tools) simulates the situation you just described.

# Initialize repository
svnadmin create repo
REPO_URL="file:///$PWD/repo"
svn mkdir "$REPO_URL/trunk" "$REPO_URL/branches" -m "Initialize repository structure"

# Add main program
svn co "$REPO_URL" wc1
cd wc1/trunk
cat > main.pl << "EOF"
my $x=0;
print("$x\n");
EOF
svn add main.pl
svn ci -m "Add main.pl"
cd ../..

# Create branch
svn cp "$REPO_URL/trunk" "$REPO_URL/branches/exp" -m "Create \"exp\" branch"

# Branch developer makes a change
svn co "$REPO_URL" wc2
cd wc2/branches/exp
perl -i -wpe 'print("\$x++;\n") if $. == 2' main.pl
svn ci -m "Increment x"
cd ../../..

# Trunk developer makes the same change
cd wc1/trunk
perl -i -wpe 'print("\$x++;\n") if $. == 2' main.pl
svn ci -m "Increment x"

# Merge changes from branch
svn up
svn merge --reintegrate "$REPO_URL/branches/exp" .
cat main.pl
Danilo Piazzalunga
Thanks for the sim nice !
HollyStyles
I hope it helps!You can also tweak it a bit and simulate a conflicting change.
Danilo Piazzalunga