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

Issue #2991 resolved, but questions remain.

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-06 09:13:51 CET

Issue #2991 is fixed now (see r27590 and r27613, merged to trunk in
r27614). However, a few things remain unresolved:

   1) Questionable HTTP header extension:

      In order to transmit capabilities over HTTP, I've had to add a
      new header (actually, it's repeated, once for each capability)
      to each request. I'm not sure how else to do it; overloading
      "User-Agent:" seemed like a bad idea. There's a long comment in
      subversion/libsvn_ra_neon/util.c:svn_ra_neon__request_dispatch()
      with details, but basically, the new header is called:

         "X-SVN-Capabilities:"

      Stop right there -- I know what you're thinking! :-) Yes, this
      is not RFC 822 and that header name is going to have to change.
      I'm not sure what to change it to, though. Does anyone have
      experience with the relevant parts of RFC 2774? It's a little
      hard to tell from that document exactly how extension headers
      are done; RFCs seem pretty adamant about never showing examples.

   2) Bidirectional capabilities or not?

      Right now, we're transmitting every capability bidirectionally.
      That's "log-revprops", "mergeinfo", and "depth". But the only
      one the server actually *needs* to hear from the client is
      "mergeinfo", which the client doesn't need to hear from the
      server. The other two are the other way around: client wants to
      hear them from server, but server doesn't need them from client.

      Should we transmit every capability both ways, or should we make
      capabilities directional: only transmit a capability to a
      consumer that we know is likely to be interested in it?

      I lean toward the former, because it's more forward-compatible.
      If in the future one side suddenly starts needing to know a
      partner's capability, the capability at least stands a chance of
      already being available, so we can spare people a minor version
      upgrade.

   3) RA-dependent inconsistency in capability reporting.

      This is a minor nit, sort of related to (2). Both ra_local and
      ra_dav (neon and serf) pass the same set of capabilities to
      'start-commit', namely "log-revprops,depth,mergeinfo" (the order
      might change, but the set is the same). However, ra_svn sends:

      "edit-pipeline,svndiff1,absent-entries,depth,mergeinfo,log-revprops"

      You can imagine why: it's largely an accident of implementation
      and the fact that ra_svn was already transmitting capabilities
      before the other RA layers got into the game.

      Should we filter out the strange ones, or just pass them along
      faithfully? The new documentation in start-commit.tmpl is
      pretty clear on what's guaranteed and what's not, so there
      shouldn't be a correctness issue here. But there may be a
      confusion issue. Thoughts?

Thanks,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 09:14:03 2007

This is an archived mail posted to the Subversion Dev mailing list.