Quoting "Jay Freeman (saurik)" <saurik@saurik.com>:
> How would something like this interact with possible, future support for
> WebDAV's LOCK and UNLOCK methods? It seems silly to go to the effort of
> building some complex seperate system (involving seperate applications and
> seperate scripts, talking to a seperate database, that might end up with
> slightly different portability than the actual svn client, and then on top
> of that shoving the responsibility for coding the lock support into every
> GUI that wants to support it) for keeping track of locks and then find out
> that the way it was done didn't end up helping to implement LOCK and
> UNLOCK.
I must say I agree.
I think it's a total waste of time to hack up some sort of locking, only to
throw it away when we do it for real. Any locking scheme would have to be
understood by the filesystem -- a locked item should not be added to a commit
txn -- and that support would be the major part of the effort, and must be done
correctly the first time.
Also, -1 on the idea of a svn:locked property: Locking a file must not result in
a version bump, that would IMHO violate the DAV spec, and we want our locking
implementation to be compatible with DAV.
The first prerequisite for locks is the same as for ACLs -- non-historic
properties. Of course, the semantics required for locks are simpler than for
ACLs, as locks don't require property inheritance or DAV access to principals.
But most of the infrastructure would be the same.
Here's what needs to be done:
1) Design non-historic properties, keeping in mind a two-stage implementatino
(first only the semantics required for locking, then for full ACL support).
2) Design and implement locking support in the filesystem, RA layer and client
libraries.
3) Design and implement "svn lock/unlock".
Adding support for DAV auto-versioning to mod_dav_svn can run in parallel, at
least for the non-locking case.
Looking at this list, it's immediately obvious to methat it can't be done before
1.0. There are simply not enough knowledgable people around with time on their
hands to do this.
I would be willing to work on this (I would very mich like to have both locking
and auto-versioning), but then I wouldn't be able to work on Beta issues, which
I believe are more important.
You know, I'd much rather work on new features than bug fixes, and so I suspect
would most people. :-) But then we'd never get 1.0 out the door. :-( So, much as
I would love to see reserved checkouts in Subversion 1.0, I recognize that the
schedule won't allow it. I'll even go as far as to predict that any patch to add
locking before 1.0 has a strong chance of getting a veto from me, because a)
it's likely to touch a lot of code and would therefore be too risky at this
stage, and b) there simply isn't time for a thorough discussion of the design
before 1.0.
Please don't get me wrong: I'm not saying we shouldn't discuss it, or that we
shouldn't create a branch for playing around with prototypes. Volunteers' time
is our own, and all that. But none of this should distract us from our main
purpose at this point, which is concentrating on 1.0.
O.K., taking my project manager's hat off now.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 13:24:53 2002