Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>>> I think we should _not_ require a lock in order to commit, either
>>> from WC or server side.
>>
>> Agreed. But in the case of WC, the only way the file can change from
>> read-only to read-write by locking it first, so files that have this
>> property generally *will* be locked already when committed.
>
> So anyone can circimvent this by simply chmod'ing the file?
Yes. That can be useful for someone who is familiar with the consequences. If
someone does it through ignorance, they will discover at commit time that their
file is out of date, and will then have to learn what they have done wrong.
> I'd just like to point out that, given the way Subversion identifies
> files, if locking affected the ability to delete a file, it would be a
> lock on the parent directory, not the file itself. Just like you can
> delete a non-writable file on Unix as long as its parent is writable.
Well then, how come the locking functional spec says that a lock on a file
prevents that file from being deleted by others? Is that spec wrong? (I feel
perhaps it is wrong, actually.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 13:47:41 2004