Hello,
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.
What you are referring to is a work-flow issue, ie Harry and Sally should have
decided between them who would update the program.
I know this is explained in the CVS documentation, I don't know about the SVN
docs, I have read only parts of it.
Basically, it boils down to the fact that version management is different from
workflow management, trying to manage the latter with the former will not work.
> 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
I don't know what SVN does exactly in Sally's case, but Sally should have
looked before she leaped; first look whether files you are about to commit
haven't changed, and if they have, look what has changed.
Again this is workflow (I think, at least).
> 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.
These clashes happen infrequently, in practice there is (often unwritten)
agreement who does which kind of changes (or who changes which files). Also,
when user A modifies files 'belonging' to B, in general A will ask or tell B
about it.
Turning off updates seems like a very drastic measure. In addition, you do not
eliminate the problem you just shift the problem, unless you believe that
Sally will in the binary file case not bluntly overwrite Harry's version
without looking, like she did now.
At least, Harry's changes are now still available, instead of being lost for
ever (in this particular case, having exactly Sally's version would be better,
but maybe Harry decided to raise your salary, and committed that in the same
revision?).
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 18 15:14:36 2005