[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 04:52:42 CET

Branko wrote:
> Nuutti Kotivuori wrote:
>> 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.
>
> I don't think that would save any time at all, or reduce the
> complexity. The only result is that you'd have to implement the
> whole thing again in libsvn_fs and mod_dav_svn -- it wouldn't save
> you from making the client lock-aware.

Agreed, it's probably not a trivial thing to do.

> Because, like it or not, it must be: if it isn't, then you'll have
> some clients that honour locks, and some that don't -- and IMO
> that's even worse than lying about LOCKs.

But here I don't agree. Use cases differ for people. I'll take an
example.

I'm a wizard on a mud. Recently, we've opened WebDAV access to wizard
home directories to help people edit their files through a proxy. That
raises the count of ways to access your own home directory to four -
inside the mud, FTP, shell, WebDAV.

Obviously if you do a LOCK from WebDAV, it will only affect the WebDAV
access on the file - none of the other access methods care one bit
about the WebDAV locks. But this is fine, since the only things
accessed are home directories and hence access is only by one
person. Just a small reminder somewhere that "Do not edit the same
file from two different access methods at the same time, if you want
to be careful."

Now, if someone would tell that this is so wrong and that we either
have to disable locking from the WebDAV server altogether (which would
break compatibility with a number of clients) or teach the mud and FTP
to respect WebDAV locks - I'd tell them to go away and mind their own
business.

I consider the case with auto-versioning and Subversion analogous. If
I have a private repository that I have mounted somewhere over simple
WebDAV - I can make damn sure I don't have any documents open when I
make commits from a real Subversion client. And like Sussman said,
it's even safer, since everything is versioned. Just as long as it is
a switch that I can flip on, where appropriate.

Now I'm not saying it's worth spending any braincycles on a half-blown
implementation like that, or that it would be a good solution for the
problem - but I do think that the merely the possibility to circumvent
the locks isn't grounds for abandoning the issue.

-- 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 04:53:36 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.