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

Re: DAV locking question

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2005-01-12 23:50:36 CET

On Jan 12, 2005, at 4:16 PM, Julian Reschke wrote:
>
> Anyway: the DAV:owner field is defined to be something to be supplied
> with the LOCK request which has *only* significance for the client who
> supplied the lock. There's no need for any other client to understand
> it, thus serializing the XML into an opaque string should be
> completely reasonable...
>

It's not reasonable for Subversion.

Granted, neon and apache work together seamlessly here. If the lock is
created by ra_dav, then the <D:owner> contents come back perfectly
unchanged later on. That's not the problem.

But Subversion has multiple servers, not just one. So while mod_dav
may think that it can privately store whatever it wants, that
assumption is wrong. It's *not* the only user of the svn repository.
svnserve, svnadmin, and svnlook are all able to examine and retrieve
locks. mod_dav's private implementation details shouldn't be poking
through. When glancing over the repository's locks, I shouldn't be
able to tell whether a lock was created by direct access (ra_local),
svnserve (ra_svn), or mod_dav_svn (ra_dav). And now all mod_dav locks
will have extra tag junk stored in the repository.

And the terrible thing is: we can't do anything about this ugliness...
because if we did, we'd break compatibility with broken (but popular)
DAV clients like MS Office.

I'm not sure what to do but throw up my hands and write it off as a
nasty wart.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 23:54:20 2005

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.