Fellow devs, I begin my week feeling constrained by the little bits of extra work involved in keeping our WebDAV proxy support sane every time we add a feature that changes the protocol for write requests over DAV. The extra work isn't hard work: just add yet another httpd.conf option so admins running slaves with the latest Subversion release can disable some obscure feature they don't understand but which the have been old isn't available on their master server which is running some previous release.
Today we have SVNAdvertiseV2Protocol and SVNAdvertiseEphemeralTXNProps.
I'll need to add SVNAdvertiseExtPropNamespaces now if I plan to merge the
'http-dynamic-prop-namespaces' branch back. And it just occured to me while
typing this email that I probably need to add another to prevent a slave
server from advertising support for the "create-txn-with-revprops" POST
handler added in 1.8, too.
This is getting out of hand.
What solutions do we have?
- Something automated? Can a slave server contact a master server with
a custom feature negotiation request and cache the results?
- Make the configuration fit the audience? What if instead of a (growing)
list of httpd.conf directives which mean nothing to the typical
administrator, we simply have one: SVNMasterVersion ${VERSION_NUMBER}?
We know which features showed up in which releases, and should be able
to do the right thing.
- At least combine the various httpd.conf directives into one. Something
like: SVNMasterOptions [+|-]FEATURE1, [[+|-]FEATURE2 ...] I'm thinking
of a syntax similar to the stock Apache "Options" directive.
- Something else?
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
