[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Exclusive Locking: 2nd draft

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-22 03:04:51 CEST

C. Michael Pilato wrote:

>>As a companion thought, it would be nice to be able to add a property to a
>>file that marks it as needing to be explicitly locked in order to be
>>committed. That would mean that whenever you update the file, it would be
>>marked read-only, even if no one has yet locked it.
>This is a feature I wanted, too.
>I seem to recall others wanting the opposite -- read-only everything
>unless you have the lock. But I think that's silly, and would make
>Subversion into just another SourceSafe.
Or just another ClearCase, or just another RCS, or just another [name
your faviourite system that uses exclusive locks by default]. It's very
impolite to let a user spend hours on editing a file, only to find --
upon commit -- that the file is locked and that she can't even save her
Word document because it's suddenly become read-only.

IMHO there will be two kinds of files in Subversion: those that by
default are subject to copy-modify-merge, and those that by follow
checkout-modify-checkin (i.e., use exclusive locks). A repository
administrator should decide which files must be locked before
modification -- reasonable options would be all, none, or binary files
only (I think the last would be a good default for Subversion in
general). Then those files that require exclusive locking would be made
read-only on checkout, and automagcally set to writable when the user
locks them.

The interesting consequence is that when you lock a directory with
depth=infinite, this should not be treated the same as setting a lock on
each file in the tree, as you don't want a directory lock in the WC to
result in chmod'ing a zillion files. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 22 03:06:39 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.