Because mod_dav.h is a public API, it's not clear how I would proceed. Especially since we'd want to backport this for a 2.0.x release without breaking binary compatibility.
I'd like to know if this process is kosher:
1. rev the mod_dav provider API in httpd's /trunk 2. create new "vtable2" structures in mod_dav.h 3. garner votes and backport to 2.0.x 4. release 2.0.53, and make svn 1.2 require it.
Yes, this is fine: you'd rev dav_provider to be dav_provider2 and change dav_hooks_* as necessary. I'm not sure that we'd need to bump all of the hooks - only those that need specific changes.
Note that we'd need to move dav_lookup_provider/dav_register_provider to ap_lookup_provider in mod_dav.c as dav_*_provider doesn't allow the versions to be set or queried.
I'm guessing that in both /trunk and httpd-2.0.53, mod_dav would advertise itself as accepting *either* version 1 or version 2 providers. mod_dav_fs would still work as a version 1 provider, mod_dav_svn would be a version 2 provider.
It doesn't advertise a provider - it just queries for which providers at a particular version are associated with the string. There'll have to be some code in mod_dav to essentially act as 'unions' or something to make the changes unobtrusive as possible to the rest of the code that hasn't changed.
Depending upon your changes, we can bump up mod_dav_fs to a version 2 provider - if it makes sense for mod_dav_fs. But, I'll be hesitant to see that backported to 2.0.x though.
(By the way, yes, the backport is necessary. It's not an option for svn 1.2 to use httpd 2.2; because apr 0.9 and apr 1.0 are binary-incompatible, it would break subversion's *own* compatibility rules to use apr 1.0 any time before svn 2.0.)
I would focus on getting the changes into trunk first and working to your satisfaction. But, the backport will only happen if we get three +1s - yes, that should happen, but I can't guarantee it. (I'm 1 out of 3.) And, then, we'd have to start a release cycle of 2.0.x. -- justin
