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

I agree that supplying "file:///var/lib/svn/some/file" to the likes of
Lynx ought to be capable of viewing that file, or not be used at all.

Current discussion appears to revolve around:

a) Changing the "file" scheme to "svnlocal".
b) Possibly adding more schemes later to support more access methods
(Examples so far mentioned appear to be ssh and postgresql).
c) Whether or not we need to change "http" as well.
d) General discussion on how confusing svnadmin is, in not taking URLs.

In order:

(a) Changing "file" to something else:

-1 : After much thought, I think there are better options.

I'd like to propose *not* changing our use of "file", but instead making
the URL actually work.

I've no idea how, currently, Subversion figures out which part of the
URL is the repository, and which the file within it. It seems to me that
it's likely to involve multiple checks, and effectively "searching" for
it. For http, this is handled by configuration within Apache, of course.

How about, as an option, we add a "magic" path component to the "file"
URL, of, say, "!svn", such that given a repository located locally as
"/var/lib/svn/", and a file within it called "/trunk/fish", we construct
the URL as:

file:///var/lib/svn/!svn/trunk/fish

(I've picked "!svn" fairly randomly, and it certainly needs changing,
since '!' is a shell metacharacter...)

Now, this should marginally speed up repository access anyway.

But now, in order to support a "dumb" client's use of the URL, we can
add a directory in the repository:

/var/lib/svn/!svn/

And keep a current set of files in place there. It does increase disk
usage, of course, but at worst it'll double it.

I think this answers the basic problem, and, I think, answers it better
than changing the scheme.

Obviously this requires either some backwards compatibility - this would
prevent, in this case, "!svn" from being a path component within the
repository - or we hold our breath and change it anyway, on the basis
that current users should be reading the list.

I prefer backwards compatibility as a short-term measure, with the
clients emitting a warning about outdated URLs.

(b) Adding further URL schemes for other (future) access methods:

I fail to see what the point of accessing the repository directly into
postgres would be. If you want client-server, then we have a perfectly
good - indeed, excellent - system for remote access.

Providing multiple client-server access methods simply increases
complexity. Obviously we may want to store the repository in a
postgresql database, but I'd personally prefer to see it accessed solely
through DAV.

But that's a personal opinion, of course. I think that discussion on
future naming conventions for remote repository access can safely be
delayed until we have some alternatives.

(c) Changing "http" to something else:

Lynx accepts the URL, and predictable and sane things happen. I see no
need whatsoever to change the URL scheme.

(d) svnadmin command line:

I suspect that svnadmin should see if its path argument begins with
"http:/" or "file:/" and reject or interpret it accordingly. (Ordinary
path arguments should, of course, still work.)

Obviously, there's a chance that people may want to put a repository in
a path that looks like a URL, but "./" prepended works on all systems
(?) and is a perfectly adequate work-around.

Thoughts, anyone? Flames would be better than being ignored. :-)

Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 31 14:17:36 2002