On Dec 15, 2004, at 5:17 AM, 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, this is what I called "hijacking". I wrote a whole essay about
that possibility, and how svn could possibly deal with it -- but
ultimately the consensus was that trying to imitate SourceSafe or
Clearcase (interactive merging questions) was the domain of something
like TortoiseSVN, not the svn commandline client.
In practice, I'm guessing this won't happen very often. svn newbies
might accidentally run 'rm' instead of 'svn rm', but I'm guessing that
if they have any svn training at all, they'll be more likely to
remember to run 'svn lock' than run 'chmod'.
>
>> I think this whole section needs to be changed; as I said, I think
>> I'm with you. The presence of the property shouldn't *require* a
>> lock to make changes. The property should just affect working copy
>> permissions, that's it.
>
> 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.
>
I'm not sure I follow. If the repository thinks that userA has locked
a file, and then userB does something like 'svn rm parent-dir-URL',
they're going to get an error -- they don't own the lock on one of
parent-dir's children. They'll get the same result if they run 'svn rm
fileURL'. Is this a bad behavior?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 14:36:06 2004