RE: Atomicity of locks and needs-lock

> > There's no conceivable reason why a person should edit a
> file that's
> > locked by someone else.
>
> Uh, because I plan to wait for the file to be unlocked and
> then perform an update to merge in my change?

If someone locked the file, they must be thinking that your changes,
whatever they are, won't be mergeable.

Most times in subversion, you just update, edit, and commit a file.
Most merges are easy. But sometimes you know there's a high risk of
creating more work, by doing a merge instead of avoiding the merge.

That's what locks are for. To prevent someone else from working on the
same file at the same time, and consequently prevent the need for a
difficult or impossible merge.

No user has reason to lock a file, unless they believe that you
shouldn't work on it right now.

So I stand by my original statement. There is no reason why a person
should edit a file that's locked by someone else. But if you feel
strongly at any given time -- you're aware of the lock and need to edit
the file anyway, that's why you have the ability to manually override,
clear the read-only bit, steal lock, etc etc.

If a file's locked by someone else, the mechanisms to stop you from
working on it are just strong enough to suggest you don't. They are not
strong enough to prevent you, if you really need to edit the file.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 29 23:33:20 2006