On Wed, Oct 1, 2008 at 10:54 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 1) It is likely we will get to a point that we do not add new features
> to mod_dav_svn since the new client will be speaking the new protocol.
> Therefore, we will have a somewhat confusion situation where users
> will "upgrade" their server and see it not supporting new features.
> Basically, because they missed the part where they have to change
> their configuration. Updating the existing module makes this much
> simpler for users.
Man, you are one step ahead of me, I was *just* about to write about this. :-)
One of the condundrums of implementing a separate mod_svn module is
deciding how we market it to users. Would mod_svn be the new
'officially supported' module where all new server-side features
(going forward) get implemented? If so, then admin would be
*required* to install mod_svn to get any new features, and mod_dav_svn
would just become an unchanging thing that can be (optionally)
installed to provide backward compatibility with older clients. On
the other hand, we could instead advertise mod_svn as the "optional"
thing, existing only to provide a speed boost when installed on top of
mod_dav_svn. Then we'd have to make new server-side features
available in both modules.
Personally, I prefer the former over the latter. But, as you say,
there may be a bit of confusion when admins upgrade. I don't think it
would be *big* amount of confusion, though. Asking admins to "load an
extra module" doesn't seem any more disruptive then asking them to run
'svnadmin upgrade' on their repositories.
>
> 2) It seems to me that using the existing module gives us complete
> freedom to add this feature incrementally.
I think the freedom is basically the same either way -- mod_svn can
grow incrementally whether it's an independent module (using DECLINE
to pass requests to mod_dav_svn), or whether it's embedded inside
mod_dav_svn (and we pass requests around internally).
> Wouldn't that give us just as much separation of code complexity? Or
> as I said before, does the mere fact that we are a DAV module
> interject complexity into the new code?
Yes, having mod_dav act as an uber-gateway does have some weird
effects, and may affect the implementation of the new protocol. It's
a monkey I'd like off our back, if possible. The other advantage to
having mod_svn as an indpendent module is that it allows for better
testing. In theory, our whole client-server should be able to pass
when it's the only module present; and when tests fail, it's *much*
easier to debug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 18:46:24 CEST