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_at_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_at_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_at_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_at_host/...
And with a svn_server we can write :
$ svn co svn_server://me:mypass_at_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_at_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
Received on Thu Aug 1 05:51:21 2002