"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.
Mark
_____________________________________________________________________________
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