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

Re: Issue #3255: client capabilities in start-commit

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 07 Aug 2008 14:33:16 -0400

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_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).


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

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.