[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r33366 - trunk/notes

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 1 Oct 2008 11:54:22 -0400

On Wed, Oct 1, 2008 at 11:44 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Wed, Oct 1, 2008 at 10:08 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>
>> Two apache modules could easy handle the same public url. You just to
>> register handler hook before mod_dav_svn and then return DECLINED if
>> url is not accepted. For example if it doesn't have cmd=something in
>> args. And return OK in other cases. mod_svn_view module uses this
>> approach for implementing Subversion web interface on the same URLs as
>> Subversion.
>
> Aha! I completely forgot about this option. Thanks Ivan!
>
> This strategy gives us the best of both worlds. It allows us to write
> a 'clean' mod_svn module with no baggage, minimal code, totally
> streamlined and aligned with svn_ra.h. But it also allows mod_dav_svn
> to coexist and speak the older protocol at the same public URL.
>
> If an admin wants to upgrade to the faster protocol, he just installs
> mod_svn next to mod_dav_svn, then asks his users to upgrade their
> clients when they're ready.
>
> Am I missing anything here?

I am fine with this. Having the single URL space is most important.
That said, let me play devil's advocate:

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.

2) It seems to me that using the existing module gives us complete
freedom to add this feature incrementally. Tackle the places where we
get the biggest gains first and add more over time. Do we really need
to write new code to handle lock/unlock and other less used commands
right away? Can't the code be partitioned in such a way that when a
request comes into our module the URL is analyzed and routed to either
the old or new code based on whether the new code can handle it?
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?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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 17:54:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.