On Oct 13, 2004, at 10:31 AM, John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> There are two scenarios here:
>> 1. An admin wisely puts an 'svn:lock' property on an image file.
>> This means that the file is read-only most of the time, and users
>> *must* obtain a lock before they can start editing; this prevents
>> people from wasting time on unmergeable changes.
>
> Except that by relying on the filesystem r/w attribute, we cannot
> completely prevent users from flipping that bit without using a
> Subversion client to obtain a lock. Subversion does not provide an
> IDE and we don't have the luxury of hooks into the editor to mediate
> all access to version controlled files.
Right, this is the "hijack" scenario discussed in the UI spec. The
same scenario that VSS and Clearcase have to deal with from
time-to-time.
>
> The lock is still only truly enforced when trying to commit, so I
> think the client needs to behave appropriately when attempting to
> commit a file with svn:lock set without having previously obtained a
> lock. What I'd prefer to what's in locking-ui.txt:
>
> a) the file is not already locked, so a lock is created, the file
> committed, and the lock released (I'd also like to see it throw a
> warning here);
>
> b) alternatively, even if the file is not already locked, the server
> could require a lock to be obtained as an independent step before
> permitting the commit (I would suggest this be an administrative
> option);
>
> c) the file _is_ locked, so the commit fails with an appropriate error
> message - "You DOPE! You need to get a lock first!" ;)
I'm not sure we need to get so complex here, or create so many
configurable options.
Suppose somebody tries to commit a hijacked file that has the
'svn:must-lock' property attached. My instinct is that they get an
error saying "get a lock first!", regardless of whether someone has
already locked the file or not. This teaches the user to stop
hijacking.
If, after getting a lock, the file is out-of-date, then the client
tells the user to run 'update'. If the update would result in a
conflict (most likely, since an 'svn:must-lock' property probably means
the file is unmergeable), then the client does the "wussy conflict
resolution" thing: prints a warning and drops the repos file into a
backup file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 17:25:38 2004