[Michael Sinz]
> In this new way, one would have to try to do an update before
> starting to edit a file - but that would not be enough, since while
> editing someone could then lock the file (and add the needs-lock
> attribute)
A parallel situation occurs with ordinary WC merges - in fact it's
exactly the same situation. If a user wants to minimize the
possibility of merge conflicts that she will have to sort through by
hand, she does 'svn update' before starting a major new feature that
would be likely to generate such conflicts. This doesn't guarantee
anything - her coworker could still commit stuff to the repository
after she updates - but it reduces the chances of merge problems. The
only way to reduce such a chance to zero is to lock the files yourself,
but I daresay that is usually overkill.
Locks are a similar story - in addition to enforcing that the
repository does not change out from under the user who locks a file,
they are (or should be) an advisory mechanism (yes, I said "advisory")
telling other users that they should be careful editing locked files,
because of an increased chance of merge conflicts later, after the
files are unlocked.
You can't eliminate these kinds of race conditions with subversion's
architecture, all you can do is train users to minimize the chance of
problems by such habits as using 'svn update' frequently, as well as
good old-fashioned team communication. But really, why _shouldn't_ the
fact that a file is locked by a given user be communicated to other
users, when the opportunity presents itself ('svn update')? Surely you
don't think it is useless information just because it may become out of
date? That's no big deal, everyone knows that the entire working copy
can become out of date. The race condition is harmless anyway, the
worst that can happen is some wasted effort.
(Come to think of it, the normal use of locking is to lock a file, then
unlock it automatically at the next commit. So in that use, the lock
is no more stale than the rest of the working copy: both are up to date
"as of rNNNNN").)
Received on Mon May 1 07:23:07 2006