[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: Matthias Wächter <Matthias.Waechter_at_tttech.com>
Date: 2005-03-04 16:39:02 CET


Ben Collins-Sussman <sussman@collab.net> wrote on 04.03.2005 15:22:04:

> > http://server/repos/trunk/file?r=105
> ... a syntax similar to this already exists, and always has. But it's
> a secret.
> The point is that the WebDAV/DeltaV specification forbids the syntax
> from being public. DeltaV clients are supposed to send a series of
> PROPFIND requests that result in the "discovery" of the URL. And once
> the client has the URL, it treats it as an opaque object; it's not
> allowed to understand the syntax, and it's *definitely* not allowed to
> assume that the syntax will stay the same. The server might have N
> different syntaxes, or might change its syntax at any time.
> So: mod_dav_svn keeps the syntax private. An ordinary web browser
> doesn't speak DeltaV, and therefore cannot "discover" the syntax.

That's ok with me in general, but what purpose has the famous
browser-based repository browsing feature if it does not allow arbitrary
single-file exports? I mean, wow, what a feature, I can point anyone to a
file, but neither me nor the other party can assure that what _he_ sees in
his browser is the same _I_ saw in the browser or what was checked in at

> Meanwhile, there are plenty of CGI programs out there explicitly made
> for browsing a repository, such as ViewCVS or WebSVN. Their syntaxes
> are public.

You mean something like this?


Hmmm ... don't like it at all. Maybe I'm missing something here, but the
URI syntax is only usable to make links work inside the app, nothing more.

I mean, one of the best things in subversion is that having the path to
_view_ a file in the browser means: You automatically have the path to use
at the svn CLI or TSVN or any other SVN client to actually _work_ on the
file! But currently, except for the revision.

> "Sell"? Yeah, those authors are raking in the money. :-)

An eye catcher to enforce replies :-)

> The fact that the syntax is private implementation detail of DeltaV is
> just part of the larger picture: we don't want mod_dav_svn to develop
> feature-creep and slowly morph into a big repository-browsing
> application. That's why its displays of directories are so minimal;

Will the principle of Subversion, to use global integer revision numbers
instead of local dotted ones (like in CVS) ever change? And even if, till
then a consistent nomenclature for browsing revisions close to the
repository name used for checkouts would be more a WHOP! WHOP! than a whip

WebDAV/DeltaV forbid to make the algorithm and naming behind PRIPFIND
requests public and that's the cause for this feature to be not present?
Some kind of unfair to those wanting to use the technique efficiently...

I don't like to have Subversion be a feature-creep repository-browsing
application as well. Maybe a plugin mechanism could help here? Any path
not containing question marks is processed by standard Subversion, and if
parameters are given, plugins could come into play that can help here.
Maybe then WebSVN or such could live transparently behind a Subversion

Again: Transparency between directly web-browsed files and checking out is
the key issue IMO.

> that's why it doesn't show properties, or log messages, or anything
> else. It's a DeltaV server, and nothing more. If you know DeltaV, you
> can "discover" all the information you want.

Well, it's not just a metter of "can" and "know". It's just a matter of
reporting a single URI via mail or documentation or whatever _directly_
pointing to the repository and not to a PHP application with a cryptic,
unnecessarily verbose, unrelated and maybe changing syntax.

- Matthias

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 16:40:36 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.