Joe Orton <jorton_at_redhat.com> writes:
> The mod_dav_svn code to store the capabilities list in
> r->connection->pool isn't going to work as desired, there is no
> guarantee that will persist for long enough. Set "KeepAlive off" in
> httpd.conf to reproduce the failure case with mod_dav_svn.
Yup. I can reproduce this too now, exactly as you say: with KeepAlive
on, the mergeinfo capability is reported to start-commit; with KeepAlive
off, it is not.
The relevant bit of mod_dav_svn/repos.c:get_resource() is this:
apr_hash_set(repos->client_capabilities,
SVN_RA_CAPABILITY_MERGEINFO,
APR_HASH_KEY_STRING, capability_yes);
The 'repos' structure is created earlier in that function:
/* create the repository structure and stash it away */
repos = apr_pcalloc(r->pool, sizeof(*repos));
repos->pool = r->pool;
comb->priv.repos = repos;
So without KeepAlive (http://httpd.apache.org/docs/1.3/keepalive.html),
the various requests/responses that go into a commit are done over
separate connections, and there is no way for capabilities reported in
an earlier connection to be known to a later connection.
(I'm just summarizing for the benefit of those not following the thread
or the code as closely as we are.)
C. Michael Pilato asks:
> What options do we have for resolving this? It would seem (to me, who
> hasn't been following this thread much) that we need one of two
> things:
>
> - a way to persist the client capabilities through the lifetime of the
> high-level Subversion operation (the commit). But that's sorta
> contrary to the whole way our stateless protocol works, isn't it?
>
> - the client to transmit capabilities in the same request which makes
> use of them (which is ... MKACTIVITY?). But is that a fair demand?
The first option is close to a non-starter. The only reasonable thing
to hang the capabilities on would be a Subversion txn -- so we'd have to
start the txn earlier. But the whole point of start-commit is to run
before a txn is even created :-).
The second option is viable, I think: have the client transmit its
capabilities with *every* request. It's too late for 1.5.0 and 1.5.1,
but we could probably justify this for 1.5.2, and certainly for 1.6.0.
I'll work up a patch (unless someone sees some reason why that plan is
doomed, in which case please speak up now).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-07 20:33:32 CEST