Le mar 30/07/2002 à 20:44, Peter Davis a écrit :
> On Tuesday 30 July 2002 08:07, Karl Fogel wrote:
> > How about
> >
> > svnlocal://path/into/repository/.../
>
> OK, a lot of people seem to like this scheme. I do too; I realize it will be
> difficult to convert all the existing people who are used to using 'file://',
> but I was confused too at first. As I pointed out when I read the first
> edition of the handbook, it was very confusing to not know where the path to
> the repository ends and the "magical" path begins. Having a custom scheme
> would at least imply that it is in fact magical. +0.5 on changing.
>
> At first I would have liked something like 'svn:///path', but then William
> Uther pointed out 'svnpipe:///'. Well how 'bout something like:
>
> svn:local:///path
>
> (or even 'svn:local:/path', since it's svn's very own scheme and shouldn't
> have to require three '///'s)
>
> svn:pipe://host/blah
>
> and, while 'http://host/svn/blah' should definitely still work since I don't
> have a problem with that, note that SVN *does* use its own extensions to DAV,
> and DAV extensions on http anyway, so supporting
>
> svn:http://host/blah
>
> (s|c)ould work as well.
>
> These are all legal URI syntax, AFAICT. Don't be scared of them just because
> of the extra ':'; for example, JDBC uses something like 'jdbc:odbc:blah'
> right now. Anyway, it makes more sense to me to qualify them all as 'svn:'
> URIs, with the additional qualifier of which type of 'svn:' URI.
>
> Eventually there could be many sub-qualifiers (pipe for starters), and having
> 'svnlocal', 'svnpipe', 'svnfoo', and so on gets messy. *We* know they are
> all svn URIs because they start with 'svn', but as far as any machine or
> newbie can tell they are all completely unrelated.
>
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 ?
> --
> Peter Davis
>
> ---------------------------------------------------------------------
> 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 08:01:55 2002