Peter Samuelson wrote:
> [Michael Sinz]
>> In fact, a major reason for locking support is to deal with files
>> that do not merge well, for example, jpeg files.
>
> [...]
>
>> 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.
>
> Both of these statements seem to imply that nobody should ever lock a
> file unless svn:needs-lock is already set. (As you say elsewhere,
> svn:needs-lock can be set well in advance.) But the rest of your
> message indicates that you don't really think that: we agree that there
> may be times you do want to lock a file which does not already have the
> needs-lock property.
Actually, I think I must have not been clear enough - I claim that it is
not possible to prevent loss of work/effort/time with respect to locks
unless the needs-lock property is set "well in advance" of the lock being
requested. Anything else will always have a reasonable race condition.
Note that "well in advance" is defined in terms of update cycles by the
users. If they do an "svn update" on a hourly basis, "well in advance"
would be 1+ hours. That is, you would want the needs-lock to have made it
out to the rest of the repository users before a lock is obtained.
(Of course this is not always possible but the goal would be that.)
[...]
>> 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.
>
> So what do you propose to do instead? I think telling users about
> locks that affect their working copies is a _good_ thing, not a _bad_
> thing. The race condition does not affect the integrity of the system,
> since the server actually enforces the locking. Sending the
> information to the client is purely advisory. Do you really think the
> status quo is better, where users have no idea they have been wasting
> their time until they try to commit?
I think you missed the point - the status quo defines that one really should
have needs-lock set well before one does a lock such that others know that
a lock is needed in order to do an edit. Any "solution" that does not
directly fix this problem will only make it worse since people would then
assume that things are going to work out right.
--
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 Tue May 2 12:00:06 2006