Carlo Hogeveen wrote:
> When updating or merging SVN either merges differences or generates a
> conflict. The way I hear people talking about SVN an update or merge
> without a conflict implies success to them, when obviously something
> as generic as SVN cannot possibly be that smart. SVN just
> updates/merges line-based, and a "successful" update/merge can still
> cause an erroneous result, as I demonstrate in the example below. I
> am new to SVN, and wonder why I don't see this mentioned anywhere.
>
> Obviously this is not a bug in the SVN application. It is just how SVN
> currently works, and as long as we also check our automatic updates
> and merges there is no harm. IMHO it is a "bug" in the documentation.
> An explicit mention there, and possibly in the FAQ, could avoid the
> unawareness that I notice.
>
> I am contemplating making all files binary in SVN to avoid automatic
> updates and merges. An option in SVN to turn off automatic updates and
> merges would seem a nice safety feature.
This is a known weakness of the merge method of version control. As the
book says, "The version control system often assists with the merging,
but ultimately a human being is responsible for making it happen
correctly."
(http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.ba
sic.vsn-models.copy-merge) CVS suffers from the same issue.
The standard manner of dealing with this? Whenever you do an update,
check to make sure your changes still work correctly before
committing--even if the update command doesn't report a conflict. Thus,
instead of "svn update; svn commit", you need to "svn update; <test>;
svn commit".
Of course, preventing concurrent development in the same files
(presumably by setting svn:needs-lock, rather than "making all files
binary") is an option, if you don't want to train your users to test
after updating. A bad option, in my opinion, but it's still an option.
And this is all ignoring the fact that changes in two separate files can
still result in the sort of problem you describe--user A changes file 1,
changing how a certain function works; user B changes file 2, altering
how the calling function expects the other function to work; the two
changes together either stack, or cancel out, neither of which is
correct. How would you propose preventing this? Keeping all source in
one file, which only one developer can work on at a time? Clearly,
that'd be unsustainable, but it's the only way for the version control
system--whatever it is--to prevent one user's changes negating or
stacking against another's. Far, far better would be communication
among developers. If user A knows that user B is working on a specific
problem, user A should work on something else. This is just plain
common sense.
Finally, I'm not really clear on what you mean by "automatic updates and
merges". Updates should not be done automatically, for the precise
reasons listed here--someone should always be tasked with verifying the
results of the update. For instance, what if the repository server
crashes halfway through the update, or someone trips over a network
cable? Bad things can happen, even in the most robust system.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 18 14:54:35 2005