On Sat, Apr 4, 2015 at 4:48 PM, Ben Reser <ben_at_reser.org> wrote:
>...
> Lock Token: The client does not have to provide a mapping of the paths to
> the
> tokens that must match what the server has. Rather it must simply provide
> all
> the tokens attached to the active locks. So the server has to find all the
> active tokens under a given path and then match them against what the
> client
> has provided. DAV supports recursive locks so the same token can be
> applied to
> multiple paths. The client can provide that token attached to any path
> (not
> even one that it is attached to). As long as they provide the token then
> they're ok.
>
> In the process of fixing mod_dav's issues over the last few years I've
> written
> a test suite for mod_dav_fs (one of these days I'm going to clean it up so
> I
> can commit it someplace). When I first wrote it I thought this locking
> behavior was a bug. Careful reading of the DAV spec says this is exactly
> how
> the protocol is supposed to operate.
>
> I believe, but I wasn't involved in the original DAV standardization
> discussions so I can't say for sure, that there are probably good reasons
> for
> this. Locks move with paths as they move as so a lock token provided by a
> client might be based on a different location than the current lock
> applies to.
> Also DAV supports recursive locks and the actual locked location might be
> above anything the client is aware of.
>
And if you modify A/B, then sometimes you must provide lock tokens for both
A and B.
>...
> This isn't about lock validation. I already added a flag to mod_dav's
> request
> validation to say not to validate locks on the COPY source. Doing the lock
> validation on the COPY source was flat out wrong in generic DAV as well as
> SVN's usage of DAV. The problem is that mod_dav's code to validate ETag's
> in
> If statements is (unfortunately) intertwined with the locks. Since
> mod_dav's
> interface to validate locks walks the tree to discover the locks this means
> that validating the ETag's also walks the tree (which is itself probably
> suboptimal but that's another issue for another day).
>
It's kind of hard to get around that tree walk :-/
But I'll warn you now: that if-header processing logic, that handles the
etags and locks ... the code in there is my THIRD attack at the problem. It
was incredibly difficult to get it done correctly. Other people ran into
the same difficulty of implementing that stuff; I still recall another
implementor trying to get it right, and the answer his manager provided
was, "do whatever mod_dav does".
I'd be happy to review any patches. Just let me know.
>...
> What mod_dav_svn is not advertised is as a generic DeltaV server (which is
> an
> additional layer on top of DAV). Our protocol changes with http v2 were to
> diverge from the official DeltaV specification. We never promised anyone
> that
> we'd continue to adhere strictly to DeltaV.
>
> To the best of my knowledge there is almost no interoperable DeltaV
> software
> out there. I haven't actually tried but I don't think Cadavear can really
> be
> used as a SVN client and I'm certain you can't use SVN against the only
> other
> DeltaV server (Oberon) that exists.
>
None. We hoped there would be, and that we could make the necessary
client/server changes to interoperate with that software ... but none ever
developed. DeltaV was designed with ClearCase and Perforce models in mind,
and possibly a couple others. It had zero support for SVN/CVS style
client-side working copies. I got that added into the spec, back in 2000,
and that's what we used for our first protocol.
But with the lack of other DeltaV software, there was no need to stick to
extra machinations, and CMike got all that ripped out with v2.
> Despite all of that, we actually do have to continue to support the
> original
> protocol implementation (that as far as I'm aware of is precisely DeltaV)
> because we have SVN clients in the wild that only talk that protocol.
>
Right. SVN 1.0 clients should be able to work against a 1.9 server (and
vice-versa).
Cheers,
-g
Received on 2015-04-05 01:07:36 CEST