Peter Samuelson wrote:
> [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.
With ordinary "merges" that is expected behavior. With a locked file,
that is not expected behavior. In fact, a major reason for locking
support is to deal with files that do not merge well, for example, jpeg
files. (One could say Word documents too, albeit they are slightly
more mergeable albeit they require domain specific merging tools.)
> 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.
Locks are actually not quite the same. Yes, one can work around them
but due to the central arbitration of locks there is no way two people
can hold a lock at the same time (assuming no know goes an breaks the
lock or otherwise works against the locking system)
The needs-lock attribute is a way for the client to mark a file as R-O
locally and thus tell you that you must obtain the lock before you can
make changes. The action of obtaining the lock is atomic and prevents
multiple people from owning it. But the signal/requirement that you
need a lock is given in a non-atomic fashion. Thus, that signal/flag
needs to be there for "some time" before the first lock is obtained.
The reason is that you need all users to know of this fact before you
can assume that all users will follow the locking protocol.
(In a perfect world one would say that the flag must be set the moment
the file is added to the repository)
> 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.
Yes, it is "harmless" if the wasted effort is easily redone. However,
wasted effort is not harmless and can be significant on certain types of
files.
> (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").)
Yes, that is the normal operation, but remember that the lock is being
gotten because "something major is about to happen that can not be merged
easily" - usually this also means that the file is fundamentally non-mergeable
but that is not a requirement.
A locking mechanism on a system that fundamentally assumes concurrent modification
and merging requires some way of knowing that you must obtain the lock. It is
not enough to say that one should always be up-to-date (which one normally
would be before an edit) since what is being proposed here is that when a lock
is gotten to somehow set the needs-lock property in an atomic way to help
protect the other users. This is not really possible since the other users may
already be in the edit phase of their process and do not have a lock since the
file was not a needs-lock file.
As such, making this type of behavior (auto-needs-lock) just adds a "feature"
that will not protect the fundamental issue since only 1/2 (at best) of the
problem is solved while looking like it solved a problem.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 1 12:12:28 2006