On Feb 2, 2005, at 7:51 PM, Philip Martin wrote:
> Ben Collins-Sussman <email@example.com> 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
>>> 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
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
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
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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 3 14:59:15 2005