WebDAV proxy feature "negotiation" -- there's *got* to be a better way.

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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development