Re: Atomicity of locks and needs-lock

Edward Harvey wrote:
>>> Actually, you can lock files even if they don't have needs-lock.
>> Yeah ok, you can.
>> Only it's extremely dumb to do that, that's what I meant.
>
> Apparently, that is debatable.
> Either way, doesn't matter to the case I want to focus on:
>
> If a user locks a file, and the file doesn't have needs-lock, all other
> users' clients should treat that file in some ways similar as if it had
> the needs-lock property.
>
> In particular, the file should become read-only, and in the gui, change
> the icon to gray.

Here is where things get difficult - how do you expect this to happen?

The GUI and Subversion (command line) don't contact the server every time you
might list the contents of a directory or open a window. A server contact
is made at checkout, update, commit, lock, and unlock time.

So, users A and B did an update sometime (lets say in the morning - but
it does not matter)

At one point user A wants to lock a file that does not have needs-lock
and does so. And maybe even adds the needs-lock property. This would
not change the working copy of user B unless user B did an update after
user A did the lock.

So, until the time user B does an update, that user has no way of knowing
that the file may even be locked let alone that it is locked. Thus, that
user may just edit the file thinking that is the correct behavior (and
it would have been had someone not locked it)

Now, it could also happen that at some point user B does do the update.
This would then get the needs-lock property on the file. However, if it
also stored the state of the lock or who had it, that would cause other
problems. It could be that a second/minute/etc after user B did the update,
user A unlocked the file. User B would then think the lock is held until
the next update from the repository. This may be long time from now.
(Assuming that we put such a feature into the repository update mechanism)

The "needs-lock" flag/marker specifically is there to move the synchronization
to the server. It marks a file as "do not edit until you get the lock"
and getting the lock is an atomic operation.

It is needs-lock that makes locking work for a non-continual connection to
the server with full updates of data every time anyone makes a change.
This is critical for the scalability of the system.

> I am asking here, if there is any reason against local storing the
> remote lock information. In the same way that we locally store the
> local lock info, and the way we locally store the "needs-lock" property.
>
> ...
>
> If there aren't any further objections, I'd like to know how to get this
> process started. Is there an approval process? If it makes sense to
> start working on it, I'm no great programmer so I'd rather if some
> experienced developer has interest. But if needs be, I'll give it a
> try. I would certainly need to be directed toward some documentation.

-- 
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