Re: [Issue 533] New - implement reserved checkouts

On Thursday 01 August 2002 08:03, issues@subversion.tigris.org wrote:
> + $ svn lock foo.c
> +
> + sets the `svn:locked' property on foo.c, with prop value of the user's
> + name (perhaps
> + email address too, whatever other information can be gathered from the
> + config files and elsewhere), and automatically commits. Thus, if
> + foo.c is out of date, you can't take out a lock on it, which seems right.

I really like this. I'm what one of the other comments would call an "early
adopter", and I generally believe that locking is Evil. But this would be
really attractive, for all the reasons you describe.

I don't think it goes against Subversion theory, since it's just a property
that can be removed. It's useful because it lets you easily see who the
locker is.

Hopefully this can make it past the "idea" stage; if not for me or for the
beauty of it, then do it for the poor helpless minions whose project managers
won't switch until they see VSS-style locking.

pdavis$ svn lock foo.c
foo.c locked by "pdavis <peter@pdavis.cx>"

joeschmoe$ svn ci foo.c
ERROR! foo.c has been locked by "pdavis <peter@pdavis.cx>".

<joeschmoe contacts pdavis, but pdavis is a jerk and won't release the lock
(even though he's not editing foo.c)>

joeschmoe$ svn unlock foo.c
ERROR! Only "pdavis <peter@pdavis.cx>" can unlock foo.c. Use --force to
override.

joeschmoe$ svn unlock --force foo.c
joeschmoe$ svn ci foo.c
Committed revision 314159.

Or maybe even have just "svn ci --force" to get around the locking, so that
you don't have to have a working copy if you are doing URL-based operations.
This could apply to directories too: it would prevent from changing, adding,
or deleting any file in the locked directory.

-- 
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org