Question about SVN update will cause the unexpect merge result.

[Dcma Tsai -蔡孟甫 <Dc...@zyxel.com.tw>]

Dear All
SVN update will automatically merge the difference from trunk to working copy.
But we found that in some cases, the automatically merge result is not what we want.
The reason is about "blank line".
Take an example.
 
The Base revision is 
----------------------------------------------
for( i = 0; i < 100; i++ ) {
    
    a[i]++;
}
-----------------------------------------------
Then both A and B modify the code to fix the same bug.
When A modifies the code.
He adds the code at "blank line" and commits first.
This commit is revision R1.
Revision R1.
----------------------------------------------
for( i = 0; i < 100; i++ ) {
    a[i]*=2;    /* A fixs the bug */
    a[i]++;
}
-----------------------------------------------
But at the same time, B modifies the code to fix the same bug.
He adds the code below "blank line".
Following is the code he modified.
----------------------------------------------
for( i = 0; i < 100; i++ ) {
 
    a[i]*=2;    /* B fixs the bug */
    a[i]++;
}
-----------------------------------------------
When B wants to commit the code, he needs to perform update first and this will merge the code from trunk.
And this will cause the following situation in B's working copy.
No conflict! Just merge!! And the merge result cause another bug!!!
----------------------------------------------
for( i = 0; i < 100; i++ ) {
    a[i]*=2;    /* A fixs the bug */
    a[i]*=2;    /* B fixs the bug */
    a[i]++;
}
-----------------------------------------------
 
This situation is dangerous. Can SVN update ignore the difference of blank line??
If blank line is ignore, then B will find that his modification is conflict with A's modification.
 
Best regards
Dylan

Re: Question about SVN update will cause the unexpect merge result.

[Ben Collins-Sussman <su...@red-bean.com>]

Hi,

The problem you describe is one of *thousands* of examples that
demonstrate that automatic merging does not always produce correct
code.  And it's not specific to Subversion ... it can happen in any
version control system which allows two people to work on the same
file at the same time (which is almost every version control system!)

When a version control system merges changes together, it can only
prevent loss of data.  It does this by making sure changes don't
overlap.  However, as you have discovered, this does *not* mean that
the resulting merge is correct, or that it even compiles.

There are no technical solutions to this problem -- computers cannot
understand code, or know whether things are compilable, or whether
merged code is buggy.  The only correct solutions to this problem are
from human behavior.  Humans need to communicate better:  for example
-- why are person A and B both fixing the same bug at the same time?
They should be telling each other what they're working on.

Just as important:  after person B updates, but before person B
commits her change, she should follow a disciplined routine:

  * make sure the code compiles
  * make sure the code passes all unit tests
  * make sure 'svn diff' looks correct

In your example, the code would compile, but it would certainly fail
unit tests, and a simple examination of 'svn diff' would show the bad
merge as well.

In short:  svn cannot ignore the blank line in your one example, since
it would mean a loss of data, and (syntactically) incorrect merge.
Even if we added code to fix your one example, it wouldn't fix the
thousands of other scenarios, and the system wouldn't be any "safer".
 The only real solution is to be careful and disciplined when using
version control.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org