On Fri, 4 Mar 2005, Matthias Wächter wrote:
> 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
> all.
>
What you see is always the HEAD revision. That's often useful and for
files, it is what DAV requires.
You could claim that the directory view is feature-freeze, but it is quite
useful and it doesn't add much complexity. But we have to stop somewhere.
> > 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?
>
>
> http://server/WebSVN/filedetails.php?repname=repos&path=%2Ftrunk%2Ffile&rev=105&sc=1
>
Check out the viewcvs syntax, which at least I find more natural.
Something like
http://svn.collab.net/viewcvs/svn/trunk/contrib?rev=1490
> > 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;
>
> 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'm not sure efficiency was the main design criteria for WebDAV...
> 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
> repository?
>
I don't see the point running them inside mod_dav_svn. What's the problem
with running them separately?
> 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.
As seen above, it doesn't have to be cryptic. Regarding changing, the
application could leave such guarantees. As a WebDAV server, subversion
currently doesn't give you such a guarantee for the internal URLs.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 17:03:41 2005