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
Received on Mon Sep 10 14:24:28 2007