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

Why svn:// isn't a good idea

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-01 03:24:35 CEST

On Thu, Aug 01, 2002 at 02:19:16AM +0200, Féliciano Matias wrote:
> * add svn_local:// for future use by web browsers, nautilus, ...

And, there is where this whole argument loses touch with me.
If you want a web browser, nautilus, etc to interact with your
SVN repository, you should be using ra_dav not ra_local. So,
this use case doesn't hold much water with me.

Yes, the file:// scheme isn't clear at first to newbies, but the
concept of path info is not foreign to URLs. In HTTP scheme, the
server will traverse until it finds a match in its space and
store the remaining unused part as path_info (Apache stores this in

My problem with the svn:// prefix is that it implies there is a
scheme and protocol. There isn't. SVN does not define a protocol
for interaction and, IMHO, it never should. That's not the job of
the SCM. SVN should be relying on other protocols for interaction.
By defining a svn prefix, you are isolating yourself to a specific

Ideally, a sql server URI for SVN would look like this:


This example is based off of the JDBC urls. SVN would add the
username and password via libsvn_auth. The dir/foo component
are the files in the repos that you want.

What SVN requires is a way to consistently define a path info
component and leave the preceding part up to the implementation
of the ra layer. Then, the ra layer will decide how to transform
the remaining part stored in a canonicalized SVN-specific format
that will then be translated however the ra implementation sees fit.

So, I believe we should define a consistent path info strategy
and leave everything else up to the transport mechanism. I'm
fairly against defining new schemes that would essentially
override existing schemes.

Yes, that means that file:// URLs may not map exactly to what
your web browser would like. But, I think it makes more sense
to have a canonical path-info strategy across ra implementations.
And, if you really wanted to be pedantic, I could support the
usage of:


But, I think using path info everywhere makes it cleaner and
more precise. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 03:25:28 2002

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.