[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-02-03 02:51:27 CET

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.

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

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?

If the repository cannot detect the conflict I suppose it could
require all locks under 'foo/' to be supplied when using any one of
them. At least then the problem would be detected at commit time and
and the committer would need to break any locks not held.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 3 02:52:53 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.