RE: svn commit: r33366 - trunk/notes

> -----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 would prefer not to create two repository URLs for the same project. One for pre 1.X clients+slow access and one for 1.X+ clients for faster access.

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.

Moving to a new url scheme breaks this use case, as I would have to support both urls indefinitely:

Here at TCG we annotate all debugging symbols (.pdb files) with this information on all source files to be able to retrieve the exact source files on debugging (this could be years after building the binary). My Visual Studio debugger automatically downloads the source files from Subversion if it can't find the exact file version locally..

I can't switch the old location to the new protocol in a big bang to support older Subversion releases. And if I introduce a new url for the repository I have to maintain this url forever.

If all requests are routed over the repository root Url it shouldn't be too hard to handle the new style requests on the same public reposity Url as the old style requests.

Just allowing an apache rewrite rule to handle the conversion might be an option, but wht can't we just use a part of the Url namespace that isn't used by mod_dav_svn, for the new mod_svn?

        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 09:26:43 CEST