Hm, lots of discusison on directory locking. Fitz and cmpilato and I
had a chat this morning, and want to relay some ideas.
What sort of options do we have?
1. Punt. Don't have any directory locking.
2. Support 'depth 0' directory locking only. That is, the ability to
lock a directory's props and membership. This means not being able
to add or delete immediate children, but still being able to edit
3. Support both 'depth 0' and 'depth infinity' locking, somehow.
Regarding option #1: Mark Phippard has recommended this, if only
because people will assume that the mere presence of a 'locking' will
make people assume that we have recursive locks. I know that ghudson
certainly finds this to be the path of least hassle, since he's mainly
concerned with solving exactly one problem: being able to serialize
access to unmergeable files.
The counterargument, though, is that users are going to want to lock
whole trees no matter what. If they're doing mass rearrangements, or
just want to lock a huge number of files, they're going to be quite
annoyed at the idea of having to run 'svn lock' 300 times, once on
each file in a tree. So I'm not ready to punt just yet. (At a
minimum, we could define 'svn lock -R dir' to mean, "run 'svn lock' on
every file you can find".... just to satisfy UI demands.)
Up till now, we've all thrown our hands in the air at the idea of
supporting recursive locks on directories. ghudson and philip have
demonstrated just how woefully inadequate our WC infrastructure is
when it comes to the idea of inherited locks.
But: who says recursive locks need to be done via inheritance?
cmpilato has an interesting set of ideas:
* Add support for file locking.
These are represented as lock-tokens in the WC. The UI for
this has been discussed to death already.
* Add support for depth-0 locks on directories.
Also represented as a lock-token in the WC. We're still in the
process of discussing the UI for this, but all-in-all, it seems
workable. It's only a tiny bit more complex than a file-lock.
* Make 'svn lock -R dir' automatically take out a depth-0 lock on
every subdir it can find, and a normal file-lock on every file it
We get a reasonable emulation of 'recursive locking' this way,
without having to deal with nasty inheritance. A working copy
just ends up with a whole bunch of lock-tokens, rather than a
* When talking to a DAV client, honor both depth-0 and
depth-infinity directory locking requests.
Again, we emulate a depth-infinity lock by performing a depth-0
lock on everything beneath.
What do others think of this approach?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Oct 20 22:29:13 2004