On Feb 2, 2005, at 7:51 PM, Philip Martin wrote:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
>> On Feb 2, 2005, at 5:49 PM, Philip Martin wrote:
>>
>>> Greg Hudson <ghudson@MIT.EDU> writes:
>>>
>>>> To the best of my knowledge, you should be able to lock schedule-add
>>>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>>>
>>> The documentation in notes/ doesn't mention such locks, although it
>>> doesn't exclude them either, is there a plan to implement this sort
>>> of
>>> lock without node?
>>
>> The repository already allows locks on nonexistent paths. (DAV
>> clients sometimes do this as a way of 'reserving' a path.)
>>
>> I'm not entirely sure that svn_ra_lock() allows it -- we should double
>> check the three RA layers.
>>
>>> There are all sorts of corner cases: if I have a
>>> schedule add directory 'foo' and I lock the path 'foo/bar' does that
>>> stop someone else commiting a new 'foo'?
>>
>> From the repository's point of view, yes. It should enforce the
>> lock.
>
Hm, thinking about it, I'm not so sure we should allow svn clients to
lock nonexistent paths. Perhaps this feature should be like
lock-expiration: it exists in the fs API for generic DAV clients to
use, but not in the ra or client APIs.
> What about:
>
> - Directory 'foo/' is schedule add so not in the repository.
> - I lock 'foo/bar', it's not in the repository either.
>
> Can I also lock 'foo/zig'? As a user I would expect to be able to do
> that.
Well, if we decide to allow svn clients to lock nonexistent paths, then
sure, it would work.
>
> Can some other user lock 'foo/zig' from their working copy? If that
> is allowed then one of us is going to have a conflict. It might not
> be another user, it might be me attempting to lock 'foo/zig' but from
> a different working copy. How does the repository determine whether
> locking 'foo/bar' and 'foo/zig' is a conflict?
This isn't about conflicts, or even about whether repository paths
exist. It's about whether locks already exist or not. If a user tries
to lock a repository path and there's already a lock present, an error
is thrown. The only way to resolve the situation is to forcibly
destroy the pre-existing lock.
This leads to two general questions:
* do we allow 'svn lock' to operate on a URL?
* do we allow 'svn lock' to operate on a non-existent URL or
non-existent wcpath?
In both cases, there's no place to store the token that comes back.
Which means the lock can *only* be used for reserving a path. The
token would be lost, and the lock could never be used for commits. The
lock would ultimately end up being removed, rather than used.
I know cmpilato thinks it's useful to reserve a path, even if the lock
is only going to be destroyed (or stolen) later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 3 14:59:15 2005