> -----Original Message-----
> From: sussman_at_gmail.com [mailto:sussman_at_gmail.com] On Behalf Of Ben
> Collins-Sussman
> Sent: woensdag 1 oktober 2008 14:09
> To: Bert Huijben
> Cc: dev_at_subversion.tigris.org
> Subject: Re: svn commit: r33366 - trunk/notes
>
> On Wed, Oct 1, 2008 at 2:26 AM, Bert Huijben <b.huijben_at_competence.biz>
> wrote:
> >> -----Original Message-----
> >> From: Branko Èibej <brane_at_xbc.nu> [mailto:=?ISO-8859-
> >> 2?Q?Branko_=C8ibej_<brane_at_xbc.nu>?=]
> >> Sent: woensdag 1 oktober 2008 2:46
> >> To: Greg Stein
> >> Cc: Ben Collins-Sussman; dev_at_subversion.tigris.org
> >> Subject: Re: svn commit: r33366 - trunk/notes
> >>
> >> Greg Stein wrote:
> >> > In general, I'm not crazy-opposed. You're entirely right: the
> vision
> >> > of WebDAV (or "WebDA") came to fruition. DeltaV did not, so
> >> attempting
> >> > to adhere strongly to DeltaV really makes little pragmatic sense.
> >> >
> >> > Within the scope of the (new) design, I *do* think it would be
> >> > interesting to make it DAV-capable. i.e. is the URL namespace both
> >> > DAV-aware *and* svn-aware? Given that DAV does not use POST, then
> I
> >> > maintain you could probably mesh the two pretty easily. The "new"
> >> > client would do some interesting GETs and POSTs, and a DAV client
> >> (not
> >> > svn! a downlevel client) would throw in a couple PROPFINDs, and if
> we
> >> > reach a bit, then some autoversioning around PUT and DELETE.
> >> >
> >> > IOW, what I might suggest is a mesh of your simplified protocol,
> with
> >> > the related DAV support for Windows, Mac, Linux, and other
> software
> >> > DAV-users. An admin could install mod_svn and get speed *and* DAV
> >> > capability.
> >> >
> >>
> >> I agree that a SVN DAV plugin for dumb clients is a good thing ...
> >> well,
> >> a major selling point in the non-techie parts of the corporate
> >> environment, heh. But cramming both into a single httpd module seems
> >> like serious overkill and suspiciously close to what we have now.
> >> Unmaintainable nightmare, don't y'know. Keep 'em separate and
> simple.
> >
> > Keeping the implementations apart would be a big plus, but it would
> be a real nice to have if we could keep existing repository Urls
> compatible with both new and old clients; automatically upgrading to
> the new protocol if possible.
>
> I don't see how this is technically possible. There's no way to have
> two different apache modules "own" a single URI at the same time. So
> the only way that a URI could respond to both protocols would be to
> (somehow) hack the entire new protocol into the existing mod_dav_svn
> module.... and that would be a nightmare.
>
> > I see using a single Url to refer to a repository and a file (and
> with a peg revision as an immutable reference to a file-version) as one
> of the major advantages of using Subversion.
>
> The *public* syntax used by an svn client isn't going to change. In
> other words, "svn list http://host/repos/path@23" will still do the
> same thing, regardless of whether we're using old or new protocols.
> What's invisible to the user (or to Visual Studio) is how the svn
> client library converts "http://host/repos/path@23" into an *internal*
> HTTP request. In the old protocol, the public URL is converted into a
> whole bunch of PROPFIND requests, followed by a 'GET
> /repos/!svn/bc/23/path'. In the new protocol, the public URL would be
> converted into a single 'GET /repos?cmd=get-file&path=/path&rev=23'
> (or something similar.)
>
> The point is, you could just switch your apache server from
> mod_dav_svn to mod_svn, and as long as you upgrade your svn clients,
> the same old working-copy URLs should keep working. We're only
> changing the internal protocol, not the URLs that users use
> day-to-day.
I'm not talking about the internal urls. My users never see the !svn or ?cmd urls, unless there is a network problem and neon shows the raw error.
I'm just talking about the public Urls.
My repositories are currently on https://subversion.<company>.com/svn/netdev/<projectgroup>/<project>/trunk/
And I would like to keep using that exact public Url with both /new/ and /old/ subversion clients; upgrading to the enhanced protocol when possible.
(The requests libsvn* sends and how they are formatted don't matter to our users, but the public repository Urls shown in UIs do)
If I would manage a commercial subversion hosting company I would prefer a single Url that 'just works'. Instead of:
* http://.../svn/<repos> for pre 1.X
* http://.../fastsvn/<repos> for 1.X+
Or if I would take googlecode as an example also:
* https://.../svn/<repos> for read+write pre 1.X
and
* https://.../fastsvn/<repos> for read+write 1.X+
I think providing both mod_dav_svn and mod_svn over the same public url encourages users to upgrade their servers to support mod_svn, while requiring all users to upgrade their clients before the migration will hold the server upgrade until the adminstrators are sure all users have updated.
Which might take a couple of years for big hosters like sourceforge.
I don't think returning the new fastsvn service connection point Url from the initial DAV request like we do with the '!svn' now, will cause real problems. And it would allow us to keep the existing public urls working for both implementations.
Another example:
When would we switch http://svn.collab.net/repos/svn/ over to mod_svn?
I personally would like that url to keep working with all 1.X subversion clients, old and new. Providing the best experience for everybody.
Formally we wouldn't break our API if we make existing urls inaccessible to old clients, but I think many users will see this in a different way.
And I don't think it should be really hard to keep things working in this scenario.
Disabling old clients should be a user decision, not ours.
Bert
---------------------------------------------------------------------
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 14:53:32 CEST