[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: argh

From: Féliciano Matias <feliciano.matias_at_free.fr>
Date: 2002-07-26 23:43:21 CEST

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

  $svn co http://host/repos/module module

  $ svn co http://host1/repos1/module1 http://host2/repos2/module2
  $ 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 :

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.