Justin Erenkrantz wrote:
> I'd like to propose that mod_dav_svn implement DAV LOCKs that are
> essentially no-ops. We've talked at length about doing full-out
> locking, and I don't want to take anything away from that. But, I
> realize that implementing locking isn't on anyone's priority list
> (let alone mine).
I have a bit of a similar solution in my mind, but hopefully more
agreeable. But I'll say a few words about the basics first.
I consider the lack of interoperability with many clients because of
the LOCK issue a really big problem for auto-versioning. It
certainly is a complete show-stopper for me.
I would very willingly accept a no-op alternative for it,
acknowledging the problems that may come with it.
But I do understand the counter-arguments on it and it's possible
effects in the future.
So, this whole matter is completely around the LOCK and UNLOCK methods
- all other methods can keep on behaving like they did before (not
taking account the Grand Plan of Locking ofcourse).
What if we have some sort of a proxy before mod_dav_svn, which handles
the LOCK and UNLOCK methods - mod_dav_svn needs never to even know
about it's existence. I'm not sure how this would be implemented
though - would it need to be a completely separate server with it's
own hacks, forwarding all other methods to the real server - or could
it somehow live inside the same server and same Apache.
This would obviously give us the benefit that doing such a kludge
handling there would not taint the code of mod_dav_svn at all and
could even be maintained separately. I think this would be enough to
convince people that this is indeed a hack, and should only be enabled
if entirely sure that it is needed.
Another possible benefit would be that it could work with other DAV
implementations as well - other implementations that do not support
LOCKing.
But, what's more - the proxy could implement LOCKing internally and
store the LOCK states within itself. Then it wouldn't be a no-op lock
anymore but a true lock. Ofcourse the lock would only be safe if all
accesses happen through the proxy - and normal subversion clients
would surpass even that.
I believe that LOCKing that works among auto-versioning clients is a
worthwhile feature, though. The only place where one would have to be
careful is when a normal subversion client is committing to the same
files - which could even be disallowed through hook scripts.
So, someone else probably has a better idea how much more effort this
approach would be - and how feasible it would be in the long run.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 4 02:44:59 2003