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