Le ven 26/07/2002 à 12:45, Philip Martin a écrit :
> Justin Erenkrantz <jerenkrantz@apache.org> writes:
>
> > > Yes, I agree that checkout should accept multiple URLs, but dropping
> > > the -d is a step forward.
> >
> > My request was to make it optional - I don't see why it has to be
> > dropped entirely. And, this report just reinforces my thought
> > that people are going to expect the CVS syntax regardless of
> > what we say. -- justin
>
> Can't we just make it "do the right thing"? How about this
>
> - case 1: one URL
> $ svn co http://host/repos/module
> checkout into ./module/
>
> - case 2: one URL and explicit path
> $ svn co http://host/repos/module path
> checkout into ./path/
>
> - case 3: multiple URLs
> $ svn co http://host1/repos1/module1 http://host2/repos2/module2
> checkout into ./module1/ and ./module2/
>
> - case 4: multiple URLs and explicit path
> $ svn co http://host1/repos1/module1 http://host2/repos2/module2 path
> checkout into ./path/module1/ and ./path/module2/
>
Excuse my poor english.
I'm not a CVS user and i'm only use ClearCase.
Sorry but i don't like your proposition.
The only problème is that someones prefer :
$svn co http://host/repos/module
than
$svn co http://host/repos/module module
and
$ svn co http://host1/repos1/module1 http://host2/repos2/module2
than
$ svn co http://host1/repos1/module1 module1
$ svn co http://host1/repos1/module2 module2
this are "only" short cups.
A Chekout opération is not frequent (once per week?). And those short
cuts can't justify the add of this "complexity".
Also, my understand of "svn co" is that the last argument is the
destination. Now the last argument can be a source or a destination
depending on the form of the last argument.
Now :
$ svn co http://host1/repos1/module1 file://`pwd`/module1
does not mean :
$ svn co http://host1/repos1/module1 module1
I preffer something more pure more simple.
Also i'm not completly happy with the current "svn co".
Exemple :
$ svn co .../repos
is not equivalent
$ svn co .../repos .
Because we have a sort of variable défault parameter.
Everybody know that "file://`pwd`/dir' is equivalent to 'dir'. This is
not true with svn :
$ svn co file://`pwd`/repos somewhere # work
$ svn co repos somewhere # doesn't work
$ svnadmin dump file://`pwd`/repos > /dev/null # doesn't word
What's append when 'svnadmin dump' can work in a remote host ?
Another strange point :
$ svn co file://var/svn/repos/proj_A/dir/ .
and 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.
My ideal svn
------------
- don't use "file:" when it does not mean "file:"
- create "svn:" for use by svn and perhaps to use with a browser (with a
svn extension). The form of "svn:" is :
svn:/user:pass@host/path/file
user:pass : to use with the future ACL system of the repository.
host : to use with a real svn server (useless since we use httpd).
user, pass, and host or only for extension actually.
svn co
------
- the default destination is '.'
A typical use with "svn:"
$ svn co svn://`pwd`/dir
for cvs users create a new flag (--create-directory)
$ svn co svn://.../dir dir
is equivalente to
$ svn co --create-directory svn://.../dir
The --create-directory is usefull with multi source.
$ svn co svn://.../dir_A dir_A
$ svn co http://.../dir_B dir_B
is equivalente to
$ svn co --create-directory svn://.../dir_A http://.../dir_B
A short cut of --create-directory can be -d
So, we have three form of svn co
$ svn co source
$ svn co source destination
$ svn co -d [source] ... [source]
I prefer the '-d' than the interpretation of the last argument.
> --
> Philip Martin
>
> ---------------------------------------------------------------------
> 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 Fri Jul 26 23:45:56 2002