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

Re: Older versions through http-repository browsing

From: solo turn <soloturn_at_gmail.com>
Date: 2005-08-22 14:56:59 CEST

hi,

why is it not possible to extend webdav or deltav standard to also
have a means of retrieving a version/revision of a resource like:
http://svn.collab.net/repos/svn/trunk/README?rev=1000
which would allow normal apache access control on the url?

is there any disadvantage in this approach i am not able to see?

-solo

On 3/4/05, Greg Stein <gstein@lyra.org> wrote:
> On Fri, Mar 04, 2005 at 10:20:08AM -0600, Ben Collins-Sussman wrote:
> >...
> > Matthias: you keep saying that the ability to look at an arbitrary
> > repository object in a browser is some sort of "killer" or "critical"
> > feature of Subversion. Let me eradicate that idea from your mind:
> > this is *not* a core feature of Subversion. It's an accidental
> > artifact of the fact that one of our servers just happens to use HTTP,
> > and that HTTP GET just _happens_ to grab the latest version of the
> > file. It's not a designed feature, nor is it a planned one. We don't
> > go around bragging about it or listing it in any whitepapers. Remember
> > that half of all svn installations don't even use apache as their
> > server!
>
> What are you talking about, Ben? It *is* a designed and planned feature of
> Subversion. Five years ago, I said that we ought to use HTTP *precisely*
> so that we can have this feature. You and Karl blustered about wanting a
> custom, binary protocol but didn't mind if I wrote up the DAV stuff. Once
> you (Ben) mounted an SVN repository on your Windows box, you were sold.
>
> So: the "latest version" reachable at a URI is very much a part of the
> design. Maybe not a core conceptual part of Subversion as a version
> control system, but very much a central aspect of (one of) its network
> communication models.
>
>
> All that said, the question here is about the private space. We have
> always called it private in case we needed to monkey it around in the
> future for better WebDAV compatibility. The "!svn" part is customizable by
> the server administrator on the off-chance somebody actually needs to a
> file or directory named "!svn" into their repository (or they just feel
> like being contrary).
>
> But, as we discussed in IM, there is a middle ground here. While we still
> don't want to expose "!svn/bc/NNNN/" in any way (in case we need to change
> it later), we *can* expose "!svn/rev/NNNN/" and just define that tree as a
> revision tree for *servers* to use.
>
> Note that I say servers. Clients cannot assume that path construction. Any
> given server might change the "!svn" portion.
>
> But for rewrite tools, CGIs, etc, it is quite possible to build a tool
> around ".../rev/NNNN/". Since the CGI or other tool is installed by the
> server admin, who also controls the special URI prefix, then they can all
> be coordinated.
>
> The changes to mod_dav_svn should be minimal. In repos.c, there is a
> special_subdirs[] array. Copy/paste the { "bc", ... } section and rewrite
> it to "rev". That should be it. If we ever need to change the "bc" stuff,
> then it will get more complicated, but until then, the two are precisely
> the same.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 22 14:58:00 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.