On 4/4/15 1:47 PM, Johan Corveleyn wrote:
> I only know SVN, not much of httpd and certainly not much of DAV. So
> I'm reading all this from behind "SVN glasses". In what cases would
> SVN send lock tokens (in the form of If headers) when executing a
> (server-side) copy?
If by server-side copy you mean `svn cp $URL1 $URL2` I don't believe that will
ever happen.
However a trivial operation like the following would result in a very slow copy
even with the patch I posted (assuming that foo is a large tree that has at
least one file locked in it that the client holds a lock token for):
svn rm foo
svn cp bar foo
svn ci
> (I'm wondering: when executing a wc-repos copy ('svn copy $WC $URL')
> this issue is also relevant, isn't it? Because such a copy is
> internally executed as a copy on the server combined with
> modifications from the WC, right? Maybe that's the case where the
> client could be sending lock tokens together with the copy?)
Don't believe we'd send any lock tokens in that case but I could be wrong.
> Side-question: if the COPY request contains 1 If header with 1 token,
> can't DAV locate where that lock token applies in the tree (so as not
> to have to crawl it)? This may be a dumb question, I don't really
> understand much of all of this :-).
The If header has two different behaviors depending on if you're sending an
ETag or a Lock Token.
ETag: The specific path provided (either implicitly as the request URI by not
tagging the condition with a path or explicitly by tagging the condition with a
specific path) must match the ETag provided. Thus you can very much do what
you're suggesting of just iterating the ETags provided and verify they match.
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.
> This sounds a bit like: from dav we have to do this expensive stuff,
> but if you know you're dav_svn, you don't really have to do all of
> this, and can decide to take shortcuts, or implement the same
> semantics in another way. But you're suggesting modifying the dav
> logic in a hard-coded way to do this. Can't this better be done via
> some configuration, or a callback?
>
> 1) Configuration: directive
> DAVDontCheckLocksOnCopyBecauseIHaveItCovered :-) to be used in
> combination with DAV svn. Or maybe mod_dav_svn can set this
> configuration itself immediately in the right scope?
>
> 2) Callback: boolean dav_want_lock_validation_on_copy() or something
> like that ...
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).
My long term plan is for the request validation is to behave as follows:
Walk the If headers and validate any ETags and then remove them from the list
of If headers. Ultimately leaving only lock tokens in the list of If headers
to handle.
If lock validation is required then handle that as we do today. Which will
ultimately be skipped on the COPY source.
This means that mod_dav's protocol support is intact without any additional
cost to SVN. No flags or options are required. It just works. Because SVN
never sends ETags.
mod_dav used to ignore ETags on the COPY source, but someone submitted a patch
to the httpd project, which got applied to fix this. Meaning it's important to
someone for them to spend the time to fix it. They were using mod_dav_fs. So
I'm not inclined to break their improvement.
> Also, as hinted by someone else: how strict do we in mod_dav_svn have
> to follow the dav spec (to act like a law-abiding dav implementation)?
> Didn't we already take steps away from that by implementing our http
> v2 protocol?
mod_dav_svn needs to stay a fully valid DAV server. This is actually an
advertised feature of Subversion. It's probably not a very commonly used
feature but it is one that we advertise. There are many generic DAV clients
out there (OS X can mount a DAV server as a file system, various Microsoft
products can talk directly to them, etc...)
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.
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.
So no I don't think we can just ignore the protocol.
