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.
Received on 2008-10-01 14:56:57 CEST