[RFC] svn:

[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