[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Adding a no-op LOCK to mod_dav_svn

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2003-01-04 02:44:10 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.