[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking: RFC: svn:needs-lock behaviors (Updated)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-02-03 14:56:32 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.