Re: Atomicity of locks and needs-lock

[Michael Sinz]
> 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.

It is also not possible to prevent loss of work/effort/time with
respect to having an out-of-date working copy. There is an inherent
race condition with 'svn update' - it does not guarantee that the user
has an up-to-date working copy! Yet somehow users survive. I claim
that if you choose to provide them with more information about locks,
they will continue to survive.

Contrary to your earlier assertion, it is _exactly_ the same situation.
In both cases, the resulting merge conflict happens client-side. In
both cases, the server correctly enforces its rules, and its content
remains consistent. In both cases, the only ill effect of the "race
condition" is a user wasting or duplicating some work.

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

So, that's a pretty awkward way to work - set a property, _then_
commit, _then_ lock the file, _then_ start working on your new feature,
_then_ remove the property, _then_ commit your changes. Is that really
your recommendation to anyone who wishes to make a
hard-to-merge-against change to a file? And I know revision numbers
are cheap, but burning one just to say "look, I am about to lock a
file" seems ... frivolous.

I don't understand why you think that is better than telling a client,
when it updates its working copy, that certain files are currently
locked. I don't see what end it serves to keep users more in the dark
than necessary.

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

But that's just it - things do work out right! The server still
enforces locks, even if a client's information is out of date. Just as
subversion prevents you from committing a change if the file in your WC
wasn't up-to-date.

And users know very well that their working copy information is only as
fresh as the latest 'svn update'. That is not a secret or a surprise.
There is not, and never has been, any guarantee that you can commit
what is in your WC. (Unless you previously locked the files yourself,
of course, and even then, someone else could steal your lock.)