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