You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Féliciano Matias <fe...@free.fr> on 2002/07/30 11:08:55 UTC
file:// -> svn://
Excuse my poor english.
I have already posted a mail here about this.
I don't like the use of file:// to reach a local repository.
Everybody know that "file://`pwd`/dir' is equivalent to 'dir'. This is
not true with subversion :
$ svn co file://`pwd`/repos somewhere # work
$ svn co repos somewhere # doesn't work
$ svnadmin dump repos > /dev/null # work
$ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
Another strange point :
$ svn co file:///var/svn/repos/proj_A/dir/ . # work
but the directory /var/svn/repos/proj_A/dir/ does not existe. this is in
violation with the convention of "file://". If i put
file:///var/svn/repos/proj_A/dir/ in a browser, this never work.
So :
- don't use "file://" when it does not mean "file://"
- create "svn://" for use by svn and perhaps for use with a browser
(with a svn extension). The form of "svn://" is :
svn://user:pass@host/path/file
user, pass, and host are only for extensions actually. Perhaps when
Subversion have this own server or when it use its own ACL system.
If this make sense, the alpha stage of Subversion is a good opportunity.
After the release 1.0, this should be too late.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why svn:// isn't a good idea
Posted by Féliciano Matias <fe...@free.fr>.
Le jeu 01/08/2002 à 03:24, Justin Erenkrantz a écrit :
> 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
> r->path_info).
>
> 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
> interaction.
svn:// has no protocol.
OK, it's clear to me. It's not an URL.
I was thinking to info:/ ghelp:/ man:/ etc... that we find in
nautilus/galeon/gnome-help.
those URL has no protocole.
nautilus can browse sgml documentation with this "URL" :
ghelp:/.../help.sgml
nautilus do automatique sgml->html translation (true with RH 7.2).
I am not precise since i has droped nautilus :o) .
gnome have a "url manager" where i can say :
protole : info => gnome-help-browser "%s"
protole : ftp => galeon "%s"
or
protole : ftp => gftp "%s"
All gnome programmes use this table (galeon does).
imagine, i push this entry into the "URL manager" :
protole : svn_local => lauch svn_gui "%s"
This simple system permit to create an html page with :
<a href="svn_local:/var/svn/repos"> my repository </a>
<a href="svn_local:/var/svn/repos/README">last changelog</a>
This is not really attractive since the good choise is to use an
http repository !
when i click to the "URL", or enter this "URL" (ok its not an url) in
galeon/nautilus/minicommander ... , "svn_gui svn_local:/var/svn/repos"
is automatically lauch.
Also, if galeon , with a plugin, could directly display a repository
(like it do with ghelp://..../help.sgml).
i should put this entry in the "url manager" :
protole : svn_local => lauch galeon "%s"
If we want a good integration of svn into modern desktop (GNOME/KDE, I
don't know if windows as such system) svn_local:/ is a good way.
Also for a new user, if he use svn_local:// he know that there is some
"magics". If he use file://, he doesn't expect this "magics".
For me (I have the old habit to lauch a program from a xterm), this
doesn't matter.
>
> Ideally, a sql server URI for SVN would look like this:
>
> postgres://postgres.example.com:port/svn-dbname/dir/foo
>
The only "URL" I see to reach a postgresql db is in gnucash.
gnucash use postgresql://user:pass@host/db_name .
I don't think there is any standard with postgres. So, for me it's
correct to use your exemple.
> This example is based off of the JDBC urls. SVN would add the
> username and password via libsvn_auth.
I am not "confidential" with Subversion and i don't understand the real
signification of libsvn_auth use. But for me, postgresql user
is specific to postgresql. That is, if some day subversion have it's
own ACL system (as the handbook claim), we should separate the postgresql
user and http user to the Subversion user.
exemple:
svn co --username=me --password=pass postgresql://user:pass@host/...
we need to treat user/pass postgresql like user/pass of a proxy.
That is a sort of key to reach de repository and not the Subversion
user.
I know that is not curently the case with an http:// repository.
Finally, if you can have postgres_user = subversion_user, it's really great.
Since we don't have to hide the user/pass of postgresql by using an
intermediate httpd server.
I have a little understanding of postgresql and it seems hard to
provide this in a safe way (we should use triggers in C).
> 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:
>
> file:///path/to/repos?path=dir/foo
> http://server.example.com/path/to/repos?path=dir/foo
> postgres://postgres.example.com:port/svn-dbname?path=dir/foo
>
If this is the right way. why not ?
> But, I think using path info everywhere makes it cleaner and
> more precise. -- justin
>
I write a sort proposition that split this two part more clearly in the
svn client.
This is surely incomplet, some time stupid ... but it provide some
attractive features for the end user.
I would like to have some feedback (at present i have 0 feedback and this
make me "nervous").
So ckeck it and reply to me with :
- Stupid
- Some points interesting
- we curently work on this
- interesting but need more work
- ...
I remenber that the use of svn: is only the "?path=dir/foo" part of a
the repository URL !
here is a copy/paste of the proposition :
Sorry for my poor english.
I think the problem, is that we want to put too many thinks in an URL.
Suppose that Subversion has evolved :
- the backend can now be postgresql
- svn have its own server
And keep in mind that we rarely need to use a "fully qualified"
repository URL (http://host/path_to_repos/path_to_file_dir) because we
have the .svn area that can store some informations.
So, for something that use "fully qualified" repository URL i prefer
something longer but clear (easy to understand) than something sorter
but ugly.
What information we need to feed into svn (and futur svn) ?
1- the location of the svn server, or how to reach the repository
(http://..../repos and some day svn_server://host/repos).
2- if i don't use a svn server, i need something to say where is the
repository storage (/var/svn/repos or
postgresql://user:pass@host/repos => repos should be the name of the
database).
3- the accound of the svn repository to use (if svn have it's own ACL
system). This stay always true even if we use a postgresql backend.
4- the element in the repository in which the command is apply
(trunk/README or branches/very_hard_bug/).
5- perhaps some misc parameters like the http proxy to use (at present
somewhere in ~/.subversion/)
Also, The temptation is great to "merge" 1 et 2 since this doesn't make
difference to a user point of view. But the administrator repository
need to know that is not the same thing ! For example, only repository
storage can be dump.
Currently, we put 1, 2 and 4 in the same url.
The problem is that 1 and 2 can be : file:// http:// postgresql://
svn_server://
Those "protocoles" can not feet the needs of subversion.
http://.../repos/.../dir_or_file with DAV extension seems OK.
file://.../repos/.../dir_or_file is not great.
postgresql://.../repos/.../dir_or_file make no sense.
svn_server://.../repos/.../dir_or_file should be OK.
So we need to "strip" 4 of 1 and 2.
Now 4 can be specific to Subversion (no limit !) and it is independant
to the location of the repository. It's also possible to use relative
path to a repository.
The part 4 can be :
-------------------
svn:/README : refer to the element /README in the repository.
svn:new_dir : refer to the element new_dir in relation to the working
copy or to the previous repository definition.
svn:README#12 : refer to revision 12 of README.
Note : This is not an URL ! => everything is possible !
Some examples :
---------------
Use of "fully qualified" repository.
Checkout a repository :
http:
$ svn co http://host/repos svn:path_dir .
db4 (native svn) :
$ svn co file:///var/svn/repos svn:path_dir .
# this is not permitted :
$ svn co file:///var/svn/repos/path_dir .
svn server:
$ svn co svn_server://host/repos svn:path_dir .
postgresql server:
$ svn co postgresql://host/repos svn:path_dir .
More example with "svn:"
------------------------
Here we play with "svn:" without the use of "fully qualified" repository
URL.
Create directories
$ svn mkdir -m "" http://host/repos svn:new_dir1 svn:new_dir2
svn:new_dir3 file:///.../repos svn:new_dir4
$ svn admin create /tmp/repos # file:///tmp/repos should be correct now
$ svn mkdir file:///tmp/repos svn:trunk svn:tags svn:branches
$ svn co file:///tmp/repos svn:trunk tmp
$ cd tmp
Do a multiple check out
$ svn co http://host/repos svn:dir1 svn:dir2 file://var/repos svn:dir
Copy operations
# create a new tag
$ svn copy -m "" svn:/trunk svn:/tags/0.14
# create a new branche
$ svn copy -m "" svn:/trunk svn:/branches/big_deal
Switch operations
# switch to this new branche
$ svn switch svn:/branches/big_deal
# switch related to the current working copy
$ svn switch svn:doc
# go back
$ svn switch svn:..
Merge operations
$ svn switch svn:/trunk
$ svn merge -r 90:120 svn:/branches/big_dial .
I think this can also make easier the maintenance of a vendor branche.
$ cd vendor/foo
$ svn copy -m "" svn:current svn:foo-1.0
$ svn copy -m "" svn:foo-1.0 svn:/repos/trunk/foo
Note that a lot of common operations does not need http://... or
file://... or postgresql://... .
Add some "magic" tricks to svn
------------------------------
$ svn co http://host/repos svn:/trunk .
# Now, use the "magic" feature of http:// repository that permit to
# "merge" the "svn:" into http://
$ svn co http://host/repos/trunk .
$ svn copy http://host/repos/trunk http://host/repos/tags/0.14
$ svn co file:///.../repos svn:/trunk .
# this is equivalent to
$ svn co svn_local:///.../repos svn:/trunk .
# Now, use the "magic" feature of svn_local:// repository that permit to
# "merge" the "svn:" into svn_local://
$ svn co svn_local:///.../repos/trunk .
$ svn co postgresql://host/repos/dir .
Error there is no database "repos/dir".
# since this doesn't make sense ...
# do this without "magic" feature
So, there is no big break with the current commande line option.
Note about --username and --password
------------------------------------
Sorry but i don't like this.
this options are use to specify the user in an http request only.
I prefer something like "http://username:password@host/..."
When Subversion have its own ACL system we can write :
$ svn co --username=me --password=mypass http://joe:joepass@host/...
$ svn co --username=me --password=mypass
postgresql://joe:joepoass@host/...
And with a svn_server we can write :
$ svn co svn_server://me:mypass@host/...
with svn_local:
$ svn co svn_local://me:mypass@/...
We need to permit multi use of --username and --password.
A complex example of multi check out
$ svn co --username=user1 --password=pass1 http://user:pass@host/repos
svn:dir1 svn:dir2 --username=user2 --password=pass2
postgresql://user:pass@host/repos svn:dir3 svn:dir4
Other use of --username
$ svn swith svn:/branche/big_deal
You don't have permission to check out ..../big_deal
$ svn swith --username=admin --password=adminpass svn:/branche/big_deal
this can also be use to change the current account
$ svn swith --username=write_permission --password=pass svn:.
About ssh use:
--------------
Any ideas ?
> ---------------------------------------------------------------------
> 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
Re: Why svn:// isn't a good idea
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 01, 2002 at 10:29:32AM -0500, Karl Fogel wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > file:///path/to/repos?path=dir/foo
> > > http://server.example.com/path/to/repos?path=dir/foo
> > > postgres://postgres.example.com:port/svn-dbname?path=dir/foo
> > >
> > > But, I think using path info everywhere makes it cleaner and
> > > more precise. -- justin
> >
> > ++1
> >
> > i agree with everything justin has said here, and it quite clearly
> > sums up why i don't think we need to switch away from file://
>
> +1 here too.
>
> I'd like to hear something from Greg Stein first, though. I have a
> feeling he may -1, at least temporarily in order to explain something
> we haven't thought of.
I'd prefer (+0) that we switched to a different URI scheme since we've kind
of bastardized the "file" scheme. But I won't veto sticking with file:.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why svn:// isn't a good idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > file:///path/to/repos?path=dir/foo
> > http://server.example.com/path/to/repos?path=dir/foo
> > postgres://postgres.example.com:port/svn-dbname?path=dir/foo
> >
> > But, I think using path info everywhere makes it cleaner and
> > more precise. -- justin
>
> ++1
>
> i agree with everything justin has said here, and it quite clearly
> sums up why i don't think we need to switch away from file://
+1 here too.
I'd like to hear something from Greg Stein first, though. I have a
feeling he may -1, at least temporarily in order to explain something
we haven't thought of.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why svn:// isn't a good idea
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jul 31, 2002 at 06:24:35PM -0700, Justin Erenkrantz wrote:
> 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
> r->path_info).
>
> 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
> interaction.
>
> Ideally, a sql server URI for SVN would look like this:
>
> postgres://postgres.example.com:port/svn-dbname/dir/foo
>
> 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:
>
> file:///path/to/repos?path=dir/foo
> http://server.example.com/path/to/repos?path=dir/foo
> postgres://postgres.example.com:port/svn-dbname?path=dir/foo
>
> But, I think using path info everywhere makes it cleaner and
> more precise. -- justin
++1
i agree with everything justin has said here, and it quite clearly
sums up why i don't think we need to switch away from file://
you're trying to solve a problem that doesn't need to be solved,
because it isn't really a problem.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Why svn:// isn't a good idea
Posted by Justin Erenkrantz <je...@apache.org>.
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
r->path_info).
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
interaction.
Ideally, a sql server URI for SVN would look like this:
postgres://postgres.example.com:port/svn-dbname/dir/foo
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:
file:///path/to/repos?path=dir/foo
http://server.example.com/path/to/repos?path=dir/foo
postgres://postgres.example.com:port/svn-dbname?path=dir/foo
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
Re: file:// -> svn://
Posted by Féliciano Matias <fe...@free.fr>.
Le mar 30/07/2002 à 13:08, Féliciano Matias a écrit :
> Excuse my poor english.
>
> I don't like the use of file:// to reach a local repository.
>
I go on irc #svn (don't really like this :o) ).
It seems that some users don't want to "drop" the file://
Someone don't want the svn_local:// because is too long.
Others think that is not a problem to violate the standardized file:// .
Lot of noise...
I prefer subversion_repository:// than file:// .
But i don't want to trouble anybody.
* let file:// in place.
* add svn_local:// for future use by web browsers, nautilus, ...
* put in the handbook that file:// in svn is not like file:// in a web browser.
And that's all.
when i see "svn ... file://..." i image "svn ... svn_local://..." and I'M HAPPY.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Helge Hess <he...@skyrix.com>.
Dave Cridland wrote:
> (3) "My" URL: file:///var/lib/svn/!svn/some/file
> - In my proposal, I suggest we create a directory on the host
> filesystem - /var/lib/svn/!svn/ - which contains current versions of the
> files. So this *is* now a "file" scheme, since
> /var/lib/svn/!svn/some/file now exists.
I like that ! You always keep the head revision in the repository so
that it can be accesses with "normal" file:// clients ?
This would be very useful, since it provides an easy facility to
retrieve the HEAD version of a repository. I always wondered how to
accomplish that (with ra_local) without polling the repository for changes.
regards
Helge Hess
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[RFC] svn:
Posted by Féliciano Matias <fe...@free.fr>.
Le mer 31/07/2002 à 19:02, Ben Collins-Sussman a écrit :
thanks for you reply.
>
> The latest proposal seems *way* too ornate to me. We're blowing this
> issue way out of proportion.
>
I don't like "file://.../!svn/.../", I only said that i have no problem
with it.
That is i don't complain if "file://.../!svn/.../" is chose.
> That said: we're planning to store the 'path-to-repository' and
> 'path-within-repository' pieces as separate objects in the entries
> file someday anyway... it's going to be required when the day comes
> that we start allowing working copies to come from different
> repositories.
>
Perhaps this can help to implement a proposition i put early.
It seems that nobody appreciate my "quick and dirty" english...
So i need to be more aggresive (this is why i put an excessive [RFC] in
the subject).
Perhaps this proposition should be in a new thread.
Here is a copy/paste of my (currently) quick and dirty proposition :
Sorry for my poor english.
I think the problem, is that we want to put too many thinks in an URL.
Suppose that Subversion has evolved :
- the backend can now be postgresql
- svn have its own server
And keep in mind that we rarely need to use a "fully qualified"
repository URL (http://host/path_to_repos/path_to_file_dir) because we
have the .svn area that can store some informations.
So, for something that use "fully qualified" repository URL i prefer
something longer but clear (easy to understand) than something sorter
but ugly.
What information we need to feed into svn (and futur svn) ?
1- the location of the svn server, or how to reach the repository
(http://..../repos and some day svn_server://host/repos).
2- if i don't use a svn server, i need something to say where is the
repository storage (/var/svn/repos or
postgresql://user:pass@host/repos => repos should be the name of the
database).
3- the accound of the svn repository to use (if svn have it's own ACL
system). This stay always true even if we use a postgresql backend.
4- the element in the repository in which the command is apply
(trunk/README or branches/very_hard_bug/).
5- perhaps some misc parameters like the http proxy to use (at present
somewhere in ~/.subversion/)
Also, The temptation is great to "merge" 1 et 2 since this doesn't make
difference to a user point of view. But the administrator repository
need to know that is not the same thing ! For example, only repository
storage can be dump.
Currently, we put 1, 2 and 4 in the same url.
The problem is that 1 and 2 can be : file:// http:// postgresql://
svn_server://
Those "protocoles" can not feet the needs of subversion.
http://.../repos/.../dir_or_file with DAV extension seems OK.
file://.../repos/.../dir_or_file is not great.
postgresql://.../repos/.../dir_or_file make no sense.
svn_server://.../repos/.../dir_or_file should be OK.
So we need to "strip" 4 of 1 and 2.
Now 4 can be specific to Subversion (no limit !) and it is independant
to the location of the repository. It's also possible to use relative
path to a repository.
The part 4 can be :
-------------------
svn:/README : refer to the element /README in the repository.
svn:new_dir : refer to the element new_dir in relation to the working
copy or to the previous repository definition.
svn:README#12 : refer to revision 12 of README.
Note : This is not an URL ! => everything is possible !
Some examples :
---------------
Use of "fully qualified" repository.
Checkout a repository :
http:
$ svn co http://host/repos svn:path_dir .
db4 (native svn) :
$ svn co file:///var/svn/repos svn:path_dir .
# this is not permitted :
$ svn co file:///var/svn/repos/path_dir .
svn server:
$ svn co svn_server://host/repos svn:path_dir .
postgresql server:
$ svn co postgresql://host/repos svn:path_dir .
More example with "svn:"
------------------------
Here we play with "svn:" without the use of "fully qualified" repository
URL.
Create directories
$ svn mkdir -m "" http://host/repos svn:new_dir1 svn:new_dir2
svn:new_dir3 file:///.../repos svn:new_dir4
$ svn admin create /tmp/repos # file:///tmp/repos should be correct now
$ svn mkdir file:///tmp/repos svn:trunk svn:tags svn:branches
$ svn co file:///tmp/repos svn:trunk tmp
$ cd tmp
Do a multiple check out
$ svn co http://host/repos svn:dir1 svn:dir2 file://var/repos svn:dir
Copy operations
# create a new tag
$ svn copy -m "" svn:/trunk svn:/tags/0.14
# create a new branche
$ svn copy -m "" svn:/trunk svn:/branches/big_deal
Switch operations
# switch to this new branche
$ svn switch svn:/branches/big_deal
# switch related to the current working copy
$ svn switch svn:doc
# go back
$ svn switch svn:..
Merge operations
$ svn switch svn:/trunk
$ svn merge -r 90:120 svn:/branches/big_dial .
I think this can also make easier the maintenance of a vendor branche.
$ cd vendor/foo
$ svn copy -m "" svn:current svn:foo-1.0
$ svn copy -m "" svn:foo-1.0 svn:/repos/trunk/foo
Note that a lot of common operations does not need http://... or
file://... or postgresql://... .
Add some "magic" tricks to svn
------------------------------
$ svn co http://host/repos svn:/trunk .
# Now, use the "magic" feature of http:// repository that permit to
# "merge" the "svn:" into http://
$ svn co http://host/repos/trunk .
$ svn copy http://host/repos/trunk http://host/repos/tags/0.14
$ svn co file:///.../repos svn:/trunk .
# this is equivalent to
$ svn co svn_local:///.../repos svn:/trunk .
# Now, use the "magic" feature of svn_local:// repository that permit to
# "merge" the "svn:" into svn_local://
$ svn co svn_local:///.../repos/trunk .
$ svn co postgresql://host/repos/dir .
Error there is no database "repos/dir".
# since this doesn't make sense ...
# do this without "magic" feature
So, there is no big break with the current commande line option.
Note about --username and --password
------------------------------------
Sorry but i don't like this.
this options are use to specify the user in an http request only.
I prefer something like "http://username:password@host/..."
When Subversion have its own ACL system we can write :
$ svn co --username=me --password=mypass http://joe:joepass@host/...
$ svn co --username=me --password=mypass
postgresql://joe:joepoass@host/...
And with a svn_server we can write :
$ svn co svn_server://me:mypass@host/...
with svn_local:
$ svn co svn_local://me:mypass@/...
We need to permit multi use of --username and --password.
A complex example of multi check out
$ svn co --username=user1 --password=pass1 http://user:pass@host/repos
svn:dir1 svn:dir2 --username=user2 --password=pass2
postgresql://user:pass@host/repos svn:dir3 svn:dir4
Other use of --username
$ svn swith svn:/branche/big_deal
You don't have permission to check out ..../big_deal
$ svn swith --username=admin --password=adminpass svn:/branche/big_deal
this can also be use to change the current account
$ svn swith --username=write_permission --password=pass svn:.
About ssh use:
--------------
Any ideas ?
> So let's just choose a new name for 'file://' and be done with it.
> :-)
>
>
> ---------------------------------------------------------------------
> 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
Re: file:// -> svn:// RRRRRRRRRR
Posted by Féliciano Matias <fe...@free.fr>.
Le jeu 01/08/2002 à 03:11, Greg Stein a écrit :
> On Wed, Jul 31, 2002 at 11:35:24PM +0200, Féliciano Matias wrote:
> >...
> > I put the same proposition twice in this thread (one with title "[RFC]
> > svn:"). The purpose is mainly to find a command line option that support
> > future features of svn and stay quite compatible with the current svn
> > (add some improvement).
> > If you read, sorry, if someone read this proposotion he/she can find a
> > lot of "type saving".
> >
> > an example to create a tag :
> > $ svn copy -m "" svn:/trunk svn:/tags/0.14
>
> That 'svn:' does not precisely locate the repository. It could be different
> from one machine to another. We want to have URLs. Shortcuts like 'svn:'
> probably won't work.
>
We need to read the full story.
here is a copy/paste:
Sorry for my poor english.
I think the problem, is that we want to put too many thinks in an URL.
Suppose that Subversion has evolved :
- the backend can now be postgresql
- svn have its own server
And keep in mind that we rarely need to use a "fully qualified"
repository URL (http://host/path_to_repos/path_to_file_dir) because we
have the .svn area that can store some informations.
So, for something that use "fully qualified" repository URL i prefer
something longer but clear (easy to understand) than something sorter
but ugly.
What information we need to feed into svn (and futur svn) ?
1- the location of the svn server, or how to reach the repository
(http://..../repos and some day svn_server://host/repos).
2- if i don't use a svn server, i need something to say where is the
repository storage (/var/svn/repos or
postgresql://user:pass@host/repos => repos should be the name of the
database).
3- the accound of the svn repository to use (if svn have it's own ACL
system). This stay always true even if we use a postgresql backend.
4- the element in the repository in which the command is apply
(trunk/README or branches/very_hard_bug/).
5- perhaps some misc parameters like the http proxy to use (at present
somewhere in ~/.subversion/)
Also, The temptation is great to "merge" 1 et 2 since this doesn't make
difference to a user point of view. But the administrator repository
need to know that is not the same thing ! For example, only repository
storage can be dump.
Currently, we put 1, 2 and 4 in the same url.
The problem is that 1 and 2 can be : file:// http:// postgresql://
svn_server://
Those "protocoles" can not feet the needs of subversion.
http://.../repos/.../dir_or_file with DAV extension seems OK.
file://.../repos/.../dir_or_file is not great.
postgresql://.../repos/.../dir_or_file make no sense.
svn_server://.../repos/.../dir_or_file should be OK.
So we need to "strip" 4 of 1 and 2.
Now 4 can be specific to Subversion (no limit !) and it is independant
to the location of the repository. It's also possible to use relative
path to a repository.
The part 4 can be :
-------------------
svn:/README : refer to the element /README in the repository.
svn:new_dir : refer to the element new_dir in relation to the working
copy or to the previous repository definition.
svn:README#12 : refer to revision 12 of README.
Note : This is not an URL ! => everything is possible !
Some examples :
---------------
Use of "fully qualified" repository.
Checkout a repository :
http:
$ svn co http://host/repos svn:path_dir .
db4 (native svn) :
$ svn co file:///var/svn/repos svn:path_dir .
# this is not permitted :
$ svn co file:///var/svn/repos/path_dir .
svn server:
$ svn co svn_server://host/repos svn:path_dir .
postgresql server:
$ svn co postgresql://host/repos svn:path_dir .
More example with "svn:"
------------------------
Here we play with "svn:" without the use of "fully qualified" repository
URL.
Create directories
$ svn mkdir -m "" http://host/repos svn:new_dir1 svn:new_dir2
svn:new_dir3 file:///.../repos svn:new_dir4
$ svn admin create /tmp/repos # file:///tmp/repos should be correct now
$ svn mkdir file:///tmp/repos svn:trunk svn:tags svn:branches
$ svn co file:///tmp/repos svn:trunk tmp
$ cd tmp
Do a multiple check out
$ svn co http://host/repos svn:dir1 svn:dir2 file://var/repos svn:dir
Copy operations
# create a new tag
$ svn copy -m "" svn:/trunk svn:/tags/0.14
# create a new branche
$ svn copy -m "" svn:/trunk svn:/branches/big_deal
Switch operations
# switch to this new branche
$ svn switch svn:/branches/big_deal
# switch related to the current working copy
$ svn switch svn:doc
# go back
$ svn switch svn:..
Merge operations
$ svn switch svn:/trunk
$ svn merge -r 90:120 svn:/branches/big_dial .
I think this can also make easier the maintenance of a vendor branche.
$ cd vendor/foo
$ svn copy -m "" svn:current svn:foo-1.0
$ svn copy -m "" svn:foo-1.0 svn:/repos/trunk/foo
Note that a lot of common operations does not need http://... or
file://... or postgresql://... .
Add some "magic" tricks to svn
------------------------------
$ svn co http://host/repos svn:/trunk .
# Now, use the "magic" feature of http:// repository that permit to
# "merge" the "svn:" into http://
$ svn co http://host/repos/trunk .
$ svn copy http://host/repos/trunk http://host/repos/tags/0.14
$ svn co file:///.../repos svn:/trunk .
# this is equivalent to
$ svn co svn_local:///.../repos svn:/trunk .
# Now, use the "magic" feature of svn_local:// repository that permit to
# "merge" the "svn:" into svn_local://
$ svn co svn_local:///.../repos/trunk .
# for compatibility purpose, the fallowing command is equivalent
$ svn co file:///.../repos/trunk .
$ svn co postgresql://host/repos/dir .
Error there is no database "repos/dir".
# since this doesn't make sense ...
# do this without "magic" feature
So, there is no big break with the current commande line option.
Note about --username and --password
------------------------------------
Sorry but i don't like this.
this options are use to specify the user in an http request only.
I prefer something like "http://username:password@host/..."
When Subversion have its own ACL system we can write :
$ svn co --username=me --password=mypass http://joe:joepass@host/...
$ svn co --username=me --password=mypass
postgresql://joe:joepoass@host/...
And with a svn_server we can write :
$ svn co svn_server://me:mypass@host/...
with svn_local:
$ svn co svn_local://me:mypass@/...
We need to permit multi use of --username and --password.
A complex example of multi check out
$ svn co --username=user1 --password=pass1 http://user:pass@host/repos
svn:dir1 svn:dir2 --username=user2 --password=pass2
postgresql://user:pass@host/repos svn:dir3 svn:dir4
Other use of --username
$ svn swith svn:/branche/big_deal
You don't have permission to check out ..../big_deal
$ svn swith --username=admin --password=adminpass svn:/branche/big_deal
this can also be use to change the current account
$ svn swith --username=write_permission --password=pass svn:.
About ssh use:
--------------
Any ideas ?
> Adding, say, the "svnlocal:" scheme would be compatible, and we could easily
> deprecate (but accept) the file: scheme for a while. A few "WARNING"
> messages in front of people when they use file: will be sufficient to train
> them away from it :-)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> 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
Re: file:// -> svn:// RRRRRRRRRR
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 31, 2002 at 11:35:24PM +0200, Féliciano Matias wrote:
>...
> I put the same proposition twice in this thread (one with title "[RFC]
> svn:"). The purpose is mainly to find a command line option that support
> future features of svn and stay quite compatible with the current svn
> (add some improvement).
> If you read, sorry, if someone read this proposotion he/she can find a
> lot of "type saving".
>
> an example to create a tag :
> $ svn copy -m "" svn:/trunk svn:/tags/0.14
That 'svn:' does not precisely locate the repository. It could be different
from one machine to another. We want to have URLs. Shortcuts like 'svn:'
probably won't work.
Adding, say, the "svnlocal:" scheme would be compatible, and we could easily
deprecate (but accept) the file: scheme for a while. A few "WARNING"
messages in front of people when they use file: will be sufficient to train
them away from it :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: file:// -> svn:// RRRRRRRRRR
Posted by Féliciano Matias <fe...@free.fr>.
Le mer 31/07/2002 à 22:25, Sander Striker a écrit :
>
> I liked it just like it was, before all the 'confusion' complaints
> began trickling in.
>
Sorry, i am the "start point" of complaints.
But i'am not the first to be confuse with file:// .
There are some discusions/decisions to improve the legibility of svn and
i have some suggestions.
> An overloaded file:// wasn't bothering me one bit.
> Introducing a scheme that requires more typing isn't something I am
> looking forward to. Maybe the simple solutions are:
>
"a scheme that requires more typing isn't something I am looking forward
to."
You make me crazy !
So let's go to do some economize on typing.
Am i the invisible man ?
I put the same proposition twice in this thread (one with title "[RFC]
svn:"). The purpose is mainly to find a command line option that support
future features of svn and stay quite compatible with the current svn
(add some improvement).
If you read, sorry, if someone read this proposotion he/she can find a
lot of "type saving".
an example to create a tag :
$ svn copy -m "" svn:/trunk svn:/tags/0.14
instead of :
$ svn copy -m "" http://svn.collab.net/repos/svn/trunk
http://svn.collab.net/repos/svn/tags/0.14
Perharp "type saving" is important only when doing the monthly "svn
checkout^H^H^H^H^H^H^Ho" ?
One request :
Please take 5 minutes to read my proposition.
If this is already done, please, take 30 seconds to reply :
- I never read such heap of stupidity. Go away little boy.
And i'm go away (quickly and silently).
> Register the svn: namespace
> [which we should do anyway]
>
> or
>
> make the commandline take:
>
> file://path/to/repos /path/in/repos
>
> The second option is yucky too, since it doesn't fit our needs at all.
>
>
> Sander
>
>
>
> ---------------------------------------------------------------------
> 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
RE: file:// -> svn://
Posted by Kieran <ki...@esperi.demon.co.uk>.
On Wed, 31 Jul 2002, Sander Striker wrote:
> Register the svn: namespace
> [which we should do anyway]
+0
This will require an rfc, detailing the full semantics of the url
according to rfc2717. And that may still change in the future.
I see potential flame wars ahead, particularly since it's
agreed that there's a bunch of stuff we'd like, but are schedules
for "post 1.0".
One advantage of a schema like:
svn:file:... for the current ra_local stuff
svn:http:...
svn:https:...
svn:pipe:... for ssh tunneled stuff, if it ever turns up
svn:db:... for using postgres
is that we could document "svn:file:" now, to RFC standards,
pretty much, and have virgin namespace territory for anyone
wanting to add features or storage layers later. (Eg, for
the mounted filesystem people have been mentioning lately, we
could have svn:native:, and if the development there screws
up on a Friday night, people can still svn up, then run
./configure --without-alpha-stuff)
The cvs :ext: and :pserver: problem is due to obscurity more than
anything else, IMO. The scheme above at least gives hints about
what's going on, and gives hints to people debugging. It might
actually be an asset.
I don't actually feel strongly for this point (see above), but
I do think this argument needs to be made.
Regards
Kieran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: file:// -> svn://
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 31 July 2002 22:06
> "Sander Striker" <st...@apache.org> writes:
>
> > Drop the file:// support completely and just use http://. Or, simply
> > call ra_local a hack that allows you to access a repository on your
> > local filesystem.
>
> Don't make me kill you. :-)
*grin* I know killing ra_local is not an option, although it sounds
attractive...
> It's bad enough that it's such a pain to set up the Subversion
> server... (and yes, it will *always* be hurdle, no matter how great or
> smart future Apache RPMs become.) But there's no way we're going to
> force people into Apache as their only option. Think of the poor
> simple guy with nothing but a shell account who wants to version his
> stuff privately. If you kill ra_local, then Subversion will
> *definitely* be worse than cvs.
I liked it just like it was, before all the 'confusion' complaints
began trickling in.
An overloaded file:// wasn't bothering me one bit.
Introducing a scheme that requires more typing isn't something I am
looking forward to. Maybe the simple solutions are:
Register the svn: namespace
[which we should do anyway]
or
make the commandline take:
file://path/to/repos /path/in/repos
The second option is yucky too, since it doesn't fit our needs at all.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> Drop the file:// support completely and just use http://. Or, simply
> call ra_local a hack that allows you to access a repository on your
> local filesystem.
Don't make me kill you. :-)
It's bad enough that it's such a pain to set up the Subversion
server... (and yes, it will *always* be hurdle, no matter how great or
smart future Apache RPMs become.) But there's no way we're going to
force people into Apache as their only option. Think of the poor
simple guy with nothing but a shell account who wants to version his
stuff privately. If you kill ra_local, then Subversion will
*definitely* be worse than cvs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: file:// -> svn://
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 31 July 2002 19:02
> The latest proposal seems *way* too ornate to me. We're blowing this
> issue way out of proportion.
>
> We're all in agreement that svn's current use of file:// effectively
> breaks the "standard" meaning of this schema. So let's just change
> the name of the schema to indicate that it's a subversion-specific
> thing, plain and simple.
>
> Once we've done that, we have *no* obligation to make subversion
> understand the traditional file:// schema. It just doesn't matter.
> Mirroring the Berkeley DB database in regular filesystem space is a
> gigantic, complex proposal that will give us no significant benefit,
> and a lot of headache. :-)
>
> Look at svn_ra_local__split_URL(). It tries to open a DB repository
> on each path component, moving from child, up through each parent.
> That's how it discovers the 'root' of the repository. There's no
> noticeable performance hit here, and no pressing need to optimize this
> away.
>
> That said: we're planning to store the 'path-to-repository' and
> 'path-within-repository' pieces as separate objects in the entries
> file someday anyway... it's going to be required when the day comes
> that we start allowing working copies to come from different
> repositories.
>
> So let's just choose a new name for 'file://' and be done with it.
> :-)
My $0.02 after reading all of this discussion (awful long thread!):
Drop the file:// support completely and just use http://. Or, simply
call ra_local a hack that allows you to access a repository on your
local filesystem.
I am -1 to go to a scheme like:
svn:file://
svn:http://
etc.
I don't like it one bit. It's like reintroducing the obscurities on
the commandline which cvs had:
:pserver:
:ext:
etc.
Bah.
Sander 'who should probably step back from this thread' Striker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Ben Collins-Sussman <su...@collab.net>.
The latest proposal seems *way* too ornate to me. We're blowing this
issue way out of proportion.
We're all in agreement that svn's current use of file:// effectively
breaks the "standard" meaning of this schema. So let's just change
the name of the schema to indicate that it's a subversion-specific
thing, plain and simple.
Once we've done that, we have *no* obligation to make subversion
understand the traditional file:// schema. It just doesn't matter.
Mirroring the Berkeley DB database in regular filesystem space is a
gigantic, complex proposal that will give us no significant benefit,
and a lot of headache. :-)
Look at svn_ra_local__split_URL(). It tries to open a DB repository
on each path component, moving from child, up through each parent.
That's how it discovers the 'root' of the repository. There's no
noticeable performance hit here, and no pressing need to optimize this
away.
That said: we're planning to store the 'path-to-repository' and
'path-within-repository' pieces as separate objects in the entries
file someday anyway... it's going to be required when the day comes
that we start allowing working copies to come from different
repositories.
So let's just choose a new name for 'file://' and be done with it.
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Féliciano Matias <fe...@free.fr>.
Le mer 31/07/2002 à 15:50, Dave Cridland a écrit :
> On Wed, 2002-07-31 at 14:20, Féliciano Matias wrote:
> > Le mer 31/07/2002 à 14:20, Dave Cridland a écrit :
>
> [Snip]
>
> I think you've (almost) completely missed the point,
Humm, Yes....
> so I obviously put
> it badly.
>
> An example:
>
> Repository accessed locally, present in /var/lib/svn/
> Node within the repository, called /some/file
>
> (1) Current URL: file:///var/lib/svn/some/file
> - As you state, this is not a "file" scheme, really, since
> /var/lib/svn/some/file does not exist.
>
> (2) "Your" URL: svnlocal:///var/lib/svn/some/file
> - This is an entirely new scheme, and thus avoids the "file" issue.
>
> (3) "My" URL: file:///var/lib/svn/!svn/some/file
> - In my proposal, I suggest we create a directory on the host
> filesystem - /var/lib/svn/!svn/ - which contains current versions of the
> files. So this *is* now a "file" scheme, since
> /var/lib/svn/!svn/some/file now exists.
OK...
i understand that you wanted :
"svn co file://var/lib/svn/!svn/..." is be equivalent to
"svn co svnlcal://var/lib/svn/..." .
futur svn use "file://.../!svn/.../" OR (NOT AND) "svnlocal://.../" .
No problems...
file:// is correcte.
the action is specific to svn.
>
> My comments about backward compatibility were about whether to still try
> and parse (1) URLs.
>
> Does this make more sense?
Sure.
>
> [Rest snipped]
>
> 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
Re: file:// -> svn://
Posted by Dave Cridland <da...@cridland.net>.
On Wed, 2002-07-31 at 14:20, Féliciano Matias wrote:
> Le mer 31/07/2002 à 14:20, Dave Cridland a écrit :
[Snip]
> > 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 :) .
I think you've (almost) completely missed the point, so I obviously put
it badly.
An example:
Repository accessed locally, present in /var/lib/svn/
Node within the repository, called /some/file
(1) Current URL: file:///var/lib/svn/some/file
- As you state, this is not a "file" scheme, really, since
/var/lib/svn/some/file does not exist.
(2) "Your" URL: svnlocal:///var/lib/svn/some/file
- This is an entirely new scheme, and thus avoids the "file" issue.
(3) "My" URL: file:///var/lib/svn/!svn/some/file
- In my proposal, I suggest we create a directory on the host
filesystem - /var/lib/svn/!svn/ - which contains current versions of the
files. So this *is* now a "file" scheme, since
/var/lib/svn/!svn/some/file now exists.
My comments about backward compatibility were about whether to still try
and parse (1) URLs.
Does this make more sense?
[Rest snipped]
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Dave Cridland <da...@cridland.net>.
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. :-)
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jul 31, 2002 at 03:20:44PM +0200, Féliciano Matias wrote:
> 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://... .
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.
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.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Féliciano Matias <fe...@free.fr>.
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
Re: file:// -> svn://
Posted by Dave Cridland <da...@cridland.net>.
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
Re: file:// -> svn://
Posted by Féliciano Matias <fe...@free.fr>.
Le mar 30/07/2002 à 13:27, Branko Čibej a écrit :
> Féliciano Matias wrote:
>
> >Excuse my poor english.
> >
> >I have already posted a mail here about this.
> >
> >I don't like the use of file:// to reach a local repository.
> >
> >Everybody know that "file://`pwd`/dir' is equivalent to 'dir'.
> >
>
> That's simply wrong. It is not equivalent. It happens to work that way
> on Unix, because absolute paths there start with a /; on Windows, for
> example, your recipe yields an invalid URL.
>
The Windows touch.
"file://c:/temp" work perfectly on Internet Explorer. IE understand
file:// . COMMAND.COM is like bash : it does not understand file://.
> > This is
> >not true with subversion :
> > $ svn co file://`pwd`/repos somewhere # work
> > $ svn co repos somewhere # doesn't work
> >
>
> The reason "svn co" requires an URL is preciesly so that it can choose
> between different reporitory access modules. file:// will go through
> ra_local, http[s]:// will go through ra_dav.
>
> > $ svnadmin dump repos > /dev/null # work
> > $ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
> >
>
> Exactly, because svnadmin requires a local path, not an URL. That's
> because it only works locally -- you can't administrate a remote
> repository with svnadmin.
>
> >Another strange point :
> > $ svn co file:///var/svn/repos/proj_A/dir/ . # work
> >but the directory /var/svn/repos/proj_A/dir/ does not existe.
> >
>
> What? I can't believe you can check out from a nonexistent repository.
> What does "ls -lR /var/svn/repos/proj_A/dir/" give you?
>
> If there really is nothing there, and you really get a working copy,
> then that's a bug.
>
$ ls -l /var/svn/repos/
drwxr-xr-x 2 apache apache 4096 jui 14 21:12 conf
drwxr-xr-x 2 apache apache 4096 jui 14 21:13 dav
drwxr-xr-x 2 apache apache 4096 jui 29 11:20 db
-rw-r----- 1 apache apache 8192 jui 22 08:24 __db.001
-rw-r----- 1 apache apache 270336 jui 22 08:24 __db.002
-rw-r----- 1 apache apache 98304 jui 22 08:24 __db.003
-rw-r----- 1 apache apache 360448 jui 22 08:24 __db.004
-rw-r----- 1 apache apache 16384 jui 22 08:24 __db.005
drwxr-xr-x 2 apache apache 4096 jui 28 05:21 hooks
drwxr-xr-x 2 apache apache 4096 jui 14 21:12 locks
-rw-r--r-- 1 apache apache 376 jui 14 21:12 README
$ ls /var/svn/repos/proj_A/dir/
ls: /var/svn/repos/proj_A/dir/: No such file or directory
> >this is in violation with the convention of "file://".
> >
>
> What convention would that be?
svn understand : file:///var/svn/repos/proj_A/dir/
mozilla not.
Mozilla understand : file:///tmp
svn not.
Mozilla or svn buggy ?
>
> > If i put
> >file:///var/svn/repos/proj_A/dir/ in a browser, this never work.
> >
> >So :
> >- don't use "file://" when it does not mean "file://"
> >
>
> +1 on that, we only use file:// when it means file://.
>
> >- create "svn://" for use by svn and perhaps for use with a browser
> > (with a svn extension). The form of "svn://" is :
> > svn://user:pass@host/path/file
> >
> >user, pass, and host are only for extensions actually. Perhaps when
> >Subversion have this own server or when it use its own ACL system.
> >
>
> That would be useful if Subversion had its own network protocol. It
> doesn't though; it uses HTTP, for which an URL schema already exists.
>
> >If this make sense, the alpha stage of Subversion is a good opportunity.
> >After the release 1.0, this should be too late.
> >
>
> I don't think it makes sense.
>
- 1 :o)
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
>
> ---------------------------------------------------------------------
> 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
Re: file:// -> svn://
Posted by Branko Čibej <br...@xbc.nu>.
Féliciano Matias wrote:
>Excuse my poor english.
>
>I have already posted a mail here about this.
>
>I don't like the use of file:// to reach a local repository.
>
>Everybody know that "file://`pwd`/dir' is equivalent to 'dir'.
>
That's simply wrong. It is not equivalent. It happens to work that way
on Unix, because absolute paths there start with a /; on Windows, for
example, your recipe yields an invalid URL.
> This is
>not true with subversion :
> $ svn co file://`pwd`/repos somewhere # work
> $ svn co repos somewhere # doesn't work
>
The reason "svn co" requires an URL is preciesly so that it can choose
between different reporitory access modules. file:// will go through
ra_local, http[s]:// will go through ra_dav.
> $ svnadmin dump repos > /dev/null # work
> $ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
>
Exactly, because svnadmin requires a local path, not an URL. That's
because it only works locally -- you can't administrate a remote
repository with svnadmin.
>Another strange point :
> $ svn co file:///var/svn/repos/proj_A/dir/ . # work
>but the directory /var/svn/repos/proj_A/dir/ does not existe.
>
What? I can't believe you can check out from a nonexistent repository.
What does "ls -lR /var/svn/repos/proj_A/dir/" give you?
If there really is nothing there, and you really get a working copy,
then that's a bug.
>this is in violation with the convention of "file://".
>
What convention would that be?
> If i put
>file:///var/svn/repos/proj_A/dir/ in a browser, this never work.
>
>So :
>- don't use "file://" when it does not mean "file://"
>
+1 on that, we only use file:// when it means file://.
>- create "svn://" for use by svn and perhaps for use with a browser
> (with a svn extension). The form of "svn://" is :
> svn://user:pass@host/path/file
>
>user, pass, and host are only for extensions actually. Perhaps when
>Subversion have this own server or when it use its own ACL system.
>
That would be useful if Subversion had its own network protocol. It
doesn't though; it uses HTTP, for which an URL schema already exists.
>If this make sense, the alpha stage of Subversion is a good opportunity.
>After the release 1.0, this should be too late.
>
I don't think it makes sense.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file:// -> svn://
Posted by Féliciano Matias <fe...@free.fr>.
Le mar 30/07/2002 à 13:37, Ben Collins-Sussman a écrit :
> Féliciano Matias <fe...@free.fr> writes:
>
> > Everybody know that "file://`pwd`/dir' is equivalent to 'dir'. This is
> > not true with subversion :
> > $ svn co file://`pwd`/repos somewhere # work
> > $ svn co repos somewhere # doesn't work
> > $ svnadmin dump repos > /dev/null # work
> > $ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
>
> It may not be clear from the handbook, but there are fundamental
> design points here.
>
The handbook has been updated and it's quite clear now :
'(Note that the `svnadmin' and `svnlook' programs operate _directly_ on
'a repository, by linking to `libsvn_fs.so'. So these tools expect
'ordinary, local paths to the repositories. This is in contrast with
'the `svn' client program, which always accesses a repository via some
'URL, whether it be via <http://> or <file:///> schemas.)
> 'svnadmin' and 'svnlook' have no concept of networking. They are
> designed to operate directly on repositories. Plain and simple.
>
My exemple with svnadmin is not very good.
svn claim to understand file:// and use file://.
In svn, file:///var/svn/repos/proj_A/README means :
file proj_A/README of the local repository in /var/svn/repos.
In a browser file:///var/svn/repos/proj_A/README means :
file /var/svn/repos/proj_A/README.
Use of file:// by svn is only to reach a repository Subversion. So why
to use the so common file://.
All URL file:// that can be use by svn can't be used by a browser
(except the repository root and not in the same way that svn).
All URL file:// that can be use by a browse can't be use by svn.
two URL (file://...) and two interpretation.
This is what i don't like.
> 'svn' is designed to use any number of network layers; therefore it
> is defined to always contact a repository via URL. Each network layer
> takes responsibility for for some URL schema. ra_dav handles http://
> and https:// schemas. If somebody wrote ra_ftp, it would handle the
> ftp:// schema. ra_local handles the file:// schema.
>
> A repository URL consists of two parts: the first part takes you to
> the repository itself, the second part is a path *within* the
> repository. For example,
>
> http://svn.collab.net/repos/svn/trunk/README
>
> is ultimately decomposed into
>
> http://svn.collab.net/repos/svn
>
> and
>
> /trunk/README.
>
I don't have any problem with the http:// subversion use. All programs
that claim to understand http:// can use URL http:// that i use with
svn. A remote repository use http and an extension of http (mod_dav).
But Subversion use file:// for something différent to file:// use by all
other programs.
>
> This same technique is used to decompose file:// urls.
>
> ---------------------------------------------------------------------
> 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
Re: file:// -> svn://
Posted by Ben Collins-Sussman <su...@collab.net>.
Féliciano Matias <fe...@free.fr> writes:
> Everybody know that "file://`pwd`/dir' is equivalent to 'dir'. This is
> not true with subversion :
> $ svn co file://`pwd`/repos somewhere # work
> $ svn co repos somewhere # doesn't work
> $ svnadmin dump repos > /dev/null # work
> $ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
It may not be clear from the handbook, but there are fundamental
design points here.
'svnadmin' and 'svnlook' have no concept of networking. They are
designed to operate directly on repositories. Plain and simple.
'svn' is designed to use any number of network layers; therefore it
is defined to always contact a repository via URL. Each network layer
takes responsibility for for some URL schema. ra_dav handles http://
and https:// schemas. If somebody wrote ra_ftp, it would handle the
ftp:// schema. ra_local handles the file:// schema.
A repository URL consists of two parts: the first part takes you to
the repository itself, the second part is a path *within* the
repository. For example,
http://svn.collab.net/repos/svn/trunk/README
is ultimately decomposed into
http://svn.collab.net/repos/svn
and
/trunk/README.
This same technique is used to decompose file:// urls.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org