--On Friday, January 3, 2003 5:54 PM -0600 Karl Fogel
<kfogel@newton.ch.collab.net> wrote:
> objected to, is the proposal that we deliberately misimplement a
> part of the DAV standard.
No, I said that we should implement as much as possible to comply
with the DAV protocol not the full-blown persistent lock API that was
discussed at the Hackathon. In retrospect, no-op wasn't quite the
right word, but it is in some sense. Let me try to further explain.
Perhaps those who were at the Hackathon discussion of this might have
a better idea where I'm coming from, or not.
The strategy that I've considered is doing a shared hash table/list
of LOCKed resources across all httpd's. That gets us complete
compliance with the DAV spec. DAV specifically allows locks to
disappear at any time for any reason - a server restart can toss
locks - there is no requirement on persistence. Therefore, a shared
memory hash table (or something like that) isn't a mis-implementation
of the DAV spec.
My point with the 'no-op lock' phrase was that it never hits the SVN
backend - this is *not* the strategy that we discussed at the
Hackathon. Yet, they *are* no-op's from everyone but mod_dav's
limited point of view. mod_dav can handle the enforcement of the
locks per DAV protocol rules. But, the repository isn't aware of the
locks itself.
Ideally, we'd like to push the locking back into the repository so
that we're not so reliant upon httpd/ra_dav and we get true
persistance. However, this is certainly a schema change and lots of
code that none of us want to write. And, our plan calls for almost
all of the libsvn_fs API to be altered to support locking. I'm
proposing a partial solution to this problem: don't tell the
repository what's going on. Make locks a no-op as far as the backend
is concerned.
Granted, this interim solution wouldn't bode well for a repository
that has activity via ra_svn *and* ra_dav, but I don't consider that
a big deal. I'm not sure that ra_svn's protocol could even handle
locking, and I'm still not sure that ra_local should honor locking.
> Maybe the MacOS X client shouldn't be locking when it doesn't need
> to? But I don't know what their justification was, or how open they
> would be to persuasion. Have you asked them?
A fair number of other legitimate DAV clients do this. It isn't just
about the MacOS X client, but it's the one I care about. I'm trying
to solve a problem, not ignore it. =-) -- justin
---------------------------------------------------------------------
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:37:12 2003