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