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

Re: Directory locking: current goals

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-15 16:56:27 CEST

"Brian W. Fitzpatrick" <fitz@collab.net> wrote on 10/15/2004 10:41:31 AM:

> It seems that the consensus is that recursive directory locking is too
> complex and riddled with edge-cases for us to include it in the current
> round of locking design. So what do we want to do with regard to
> locking directories? As I see it, we have two choices:
> - Depth 0 lock: lock only the directory properties. I don't know how
> useful this might be.
> - Depth 1 lock: lock the directory properties and the contents of the
> directory. That is, no other user is able to add or delete files from
> the directory, nor to modify any of the files in the directory.
> I'm leaning toward the depth 1 lock right now, but I'd like to hear
> from the rest of the list on this

I think that a Depth 1 lock opens the product up to looking deficient.
Someone might reasonably think they ought to be able to lock "trunk" as a
way of preventing any commits to trunk while they do something.

Depth 0 makes some sense, as again, it might seem weird to have a locking
feature, but then have parts of the repository that you cannot lock. There
are twi things I do not like about Depth 0 locking.

1) it seems like there is no natural action that would unlock the
directory, as there is with an svn commit unlocking a file. Perhaps a
commit of prop changes to a directory could unlock it?

2) I think you still have the same perception problem that the lock ought
to mean more than it does -- recursive locking.

I am inclined to think that perhaps there ought not to be any directory
locking in the initial release. The "low-end" tools like VSS and PVCS
cannot lock directories. I imagine this is primarily because they do not
really version directories at all anyway. The only "high-end" tool we
seem to talk about is ClearCase, of which I have no direct experience. It
has been said you need to have a lock on a directory in CC in order to add
or delete files in the directory. This seems ridiculously limiting to me,
and strikes me as just a deficiency in their model for versioning
directories. One that Subversion does not have.

I tend to think the primary rationale for locking directories is for
recursive locking, and I am not convinced that is really needed either. So
I would tend to say we ought to reject an svn lock operation on a
directory until such time that we want to implement a recursive locking
feature. While I think it could be perceived as a legitimate request to
want Depth 0 locking, I think that being able to lock a directory at all,
is just going to give the impression that something "bigger" is happening
and it probably is not worth it at this time.


Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 16:56:53 2004

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.