Ben Collins-Sussman <sussman@collab.net> wrote on 10/20/2004 04:28:38 PM:
> 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.
I would like to see this explained a bit more. Just thinking out loud...
- I svn add/delete some files in my WC. Does svn check the server to
see
if the dir is locked to someone else and fail? I presume no. When I
commit,
if it is locked to someone else, I presume the entire commit fails?
- I guess same scenario. Except dir has "svn:mustlock" property set. If
I run
svn add/delete it will fail unless I have a lock on the dir? I get a
lock on
the dir, and can now add/delete and commit.
- I would imagine prop changes would work the same.
How are dir locks released? This concerns me. Without knowing much about
how svn
works internally, it seems like it would be difficult to implicity know
when to
release the lock. I think requiring svn unlock is bad for usability.
I am not going to play out the scenarios, but it seems like there could be
some similar
complications with copy/move and dir locks. Without thinking it through
though, perhaps
not.
> 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.)
Exactly, some kind of UI that allows one to recursively obtain the locks
would
solve it. Question, would the command be "atomic" in the sense of say I
have 1000
files. I try to lock them all, and 4 of the 1000 files are already
locked. Does it
lock the other 996 or none?
> 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?
My main issue has always been what does dir lock mean? My main suggestion
for punting
was that the issue seems thorny and could probably be dealt with in the
future after
the main locking feature was implemented. File locking is obviously what
is most wanted.
All that being said, if the issues are not that thorny, then by all means
proceed. Also,
it stands to reason that even if dir locks are not implemented it doesn't
mean they should
not be designed now.
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 Wed Oct 20 22:48:33 2004