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

Re: file:// -> svn://

From: Dave Cridland <dave_at_cridland.net>
Date: 2002-07-31 16:11:46 CEST

On Wed, 2002-07-31 at 14:43, Garrett Rooney wrote:
> if we're going to change to something (and i still don't think we
> really should), i'd be in favor of going with svn_local:// and
> avoiding any weird hacks to the way the file:// url currently works.

It's my opinion that the "file" scheme currently *has* weird hacks to
the way it works, in as much as any other program that can handle a
"file" scheme fails to work as expected.

My proposal involves making the "file" scheme fully interoperable with
existing clients, and (as a slight extra benefit) making it more obvious
where the repository actually is.

Consider a (very) perverse case:

Repository in /var/lib/svn/
Second repository in /var/lib/svn/db/
Directory node in first repository named /db/

My proposal would work, neither the current use of "file" nor the
proposed "svn_local"/"svnlocal" schemes would.

The "http" scheme works with this, of course, since Apache is told where
the repository starts.

> as for changing svnadmin, it's documented that it takes a path, it
> doesn't work via an RA layer, so it should not take a URL, and i'm -1
> on changing it to do so.

I'm certainly not advocating *only* supporting URLs, merely adding some
code which attempts to spot misuse and generate suitable errors.

It can produce the errors after an attempt to create a repository in
./file:/var/lib/svn/ fails, for instance.

No loss of usability, no change to the interface nor the manuals, but an
increase in user-friendliness, which will, admittedly, disappoint the
die-hard UNIX users amongst us. :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 31 16:09:42 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.