another idea for directory locking.

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
    children.

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
     can find.

        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
        single one.

   * 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 22:29:13 2004