[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: Féliciano Matias <feliciano.matias_at_free.fr>
Date: 2002-07-31 15:20:44 CEST

Le mer 31/07/2002 à 14:20, Dave Cridland a écrit :
> 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.

Sorry for my poor english.

I have no problem with backwards compatibility. But i don't like
backwards compatibility for a long time, especially in alpha stage.

Honestly you give a good andwers to a sort of bad question.

1 - svn is curently not widely use (normal).
2 - svn should be widely use in one or two years (new users).

We need to give an answers to audience 2 and not to 1 (sorry :o) ).

It seems than audience 2 (feetback of new users) have some confusing
with the use of file:// by svn and prefer something like
svn_local://... .

So in two years we have 90% of svn_local:// usage and only 10% of
file:// usage (perhaps i'm wrong !) .

Should we maintain such "ugly" things like "file://.../!svn/..." only
for 10% of users ?
Should we push something that split the subversion communauty ?
Should we encourage "flame wars" ? (like this reply)

Perhaps this is the open-source touch :) .

> (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.

I put a proposition somewhere in this thread.

> 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

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