You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Price <mp...@atl.lmco.com> on 2002/07/25 22:38:19 UTC

argh

A mistake cvs users will only make once, but a pretty annoying one.  I
just did something like this while trying to check out two different
directories from my real repository without even thinking.

  $ /tmp/tmp> svnadmin create /tmp/tmp/repo
  $ /tmp/tmp> svn co file:///tmp/tmp/repo wc
  Checked out revision 0.
  $ /tmp/tmp> dir
  total 16
  drwxr-x---    7 mprice   mprice        484 Jul 25 18:28 repo/
  drwxr-x---    3 mprice   mprice        178 Jul 25 18:28 wc/
  $ /tmp/tmp> cd wc
  $ /tmp/tmp/wc> mkdir a b
  $ /tmp/tmp/wc> svn add *
  A         a
  A         b
  $ /tmp/tmp/wc> svn commit -m "just testing"
  Adding         a
  Adding         b

  Committed revision 1.
  $ /tmp/tmp/wc> cd ..
  $ /tmp/tmp> rm -fr wc
  $ /tmp/tmp> svn co file:///tmp/tmp/repo/a file:///tmp/tmp/repo/b
  Checked out revision 1.
  $ /tmp/tmp> dir
  total 16
  drwxr-x---    3 mprice   mprice        177 Jul 25 18:29 file:/
  drwxr-x---    7 mprice   mprice        484 Jul 25 18:28 repo/
  $ /tmp/tmp> du --max-depth 5 file\:/
  120     file:/tmp/tmp/repo/b/.svn
  128     file:/tmp/tmp/repo/b
  136     file:/tmp/tmp/repo
  144     file:/tmp/tmp
  152     file:/tmp
  160     file:


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Féliciano Matias <fe...@free.fr>.
Le ven 26/07/2002 à 12:45, Philip Martin a écrit :
> Justin Erenkrantz <je...@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

Re: argh

Posted by Michael Wood <mw...@its.uct.ac.za>.
On Fri, Jul 26, 2002 at 02:33:27PM -0500, Karl Fogel wrote:
> Michael Wood <mw...@its.uct.ac.za> writes:
[snip]
> > The only problem I see with that is that it would mean that "-d"
> > would not be available for any other use.
> 
> Exactly.  Single-letter lowercase options are like diamonds; and we
> should be like De Beers.  At least in this respect.

Youmay be interested to know that De Beers incinerates large quantities
of diamonds because it's cheaper than storing them...

-- 
Michael Wood <mw...@its.uct.ac.za>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Michael Wood <mw...@its.uct.ac.za> writes:
> What I think justin is saying is, why not allow this:
> 
> $ svn co http://host/repos/module
> $ svn co http://host/repos/module [-d] path
> $ svn co http://host1/repos1/module1 http://host2/repos2/module2
> $ svn co http://host1/repos1/module1 http://host2/repos2/module2 [-d] path

I think the number of people who want to create local files whose
names *look* like URLs can be counted on the fingers of one thumb.

+1 on the solution everyone else has been +1'ing.

> The only problem I see with that is that it would mean that "-d" would
> not be available for any other use.

Exactly.  Single-letter lowercase options are like diamonds; and we
should be like De Beers.  At least in this respect.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Michael Wood <mw...@its.uct.ac.za>.
On Fri, Jul 26, 2002 at 11:45:57AM +0100, Philip Martin wrote:
> Justin Erenkrantz <je...@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
> 
[snip]
>   $ svn co http://host/repos/module

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

>   $ svn co http://host1/repos1/module1 http://host2/repos2/module2

>   $ svn co http://host1/repos1/module1 http://host2/repos2/module2 path

What I think justin is saying is, why not allow this:

$ svn co http://host/repos/module
$ svn co http://host/repos/module [-d] path
$ svn co http://host1/repos1/module1 http://host2/repos2/module2
$ svn co http://host1/repos1/module1 http://host2/repos2/module2 [-d] path

The only problem I see with that is that it would mean that "-d" would
not be available for any other use.

-- 
Michael Wood <mw...@its.uct.ac.za>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: argh

Posted by Mats Nilsson <ma...@xware.se>.
Under this scheme, how would these cases be handled

svn co http://host/repos/trunk/doc http://host/repos/branches/bugfix1/doc
work-on-docs
or
svn co http://host1/repos/trunk http://host2/repos/trunk stuff

or other conceivable mishaps.

There is nothing particular to gain by allowing multiple check-out targets.
They are not necessarily related to the same revision, so they could just as
easily be separated into different commands.

Mats


> Justin Erenkrantz <je...@apache.org> writes:
>
> Can't we just make it "do the right thing"?  How about this
[...]
> - 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/
>
> --
> Philip Martin





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:

> > - 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/
> 
> +1 for this approach.
 
This is exactly what kfogel meant.  We can still handle every use
case;  no need for -d.

+1, do it man!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: argh

Posted by Sander Striker <st...@apache.org>.
> From: Philip Martin [mailto:pm@localhost.striker.xs4all.nl]On Behalf Of
> Philip Martin

> Justin Erenkrantz <je...@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/

+1 for this approach.

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@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/

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Jul 25, 2002 at 11:57:11PM +0100, Philip Martin wrote:
> As a non-CVS user I maintain that the previous syntax was confusing :-)
> 
> $ svn merge    -rN:M URL PATH
> $ svn switch   -rN   URL PATH
> $ svn copy     -rN   URL PATH
> $ svn checkout -rN   URL -d PATH    # wtf!
> 
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@apache.org> writes:

> I still maintain that the new co syntax is confused.  -- justin

As a non-CVS user I maintain that the previous syntax was confusing :-)

$ svn merge    -rN:M URL PATH
$ svn switch   -rN   URL PATH
$ svn copy     -rN   URL PATH
$ svn checkout -rN   URL -d PATH    # wtf!

Yes, I agree that checkout should accept multiple URLs, but dropping
the -d is a step forward.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Jul 25, 2002 at 06:38:19PM -0400, Michael Price wrote:
>   $ /tmp/tmp> svn co file:///tmp/tmp/repo/a file:///tmp/tmp/repo/b
>   Checked out revision 1.

Heh.  This is sort of related to my concerns about how co now works.
My (conceptual) take is that this would check out *two*
repositories - not place the contents of repo/a into the directory
file:///tmp/tmp/repo/b.  I didn't even think of testing this case.

The assertion raised earlier was that you could detect when a
URI is passed as the second parameter, but that isn't really
possible as what may seem like a URL is really what the user wants.

I still maintain that the new co syntax is confused.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Kieran <ki...@esperi.demon.co.uk> writes:
> This makes Justin's unhappiness about -d going away seem more justified.

I think rather it means that there's an error check that should be in
the code, but isn't yet.

> SOmeone in that thread said that it was obvious what's a url and
> what isn't.  I'd say that subversion needs to catch this case, if only
> because it's likely to happen early in a user's experience, and
> colour their view of the project.

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: argh

Posted by Kieran <ki...@esperi.demon.co.uk>.
On Thu, 25 Jul 2002, Michael Price wrote:

> A mistake cvs users will only make once, but a pretty annoying one.  I
> just did something like this while trying to check out two different
> directories from my real repository without even thinking.
>
>   $ /tmp/tmp> svnadmin create /tmp/tmp/repo
>   $ /tmp/tmp> svn co file:///tmp/tmp/repo wc
>   Checked out revision 0.
>   $ /tmp/tmp> dir
>   total 16
>   drwxr-x---    7 mprice   mprice        484 Jul 25 18:28 repo/
>   drwxr-x---    3 mprice   mprice        178 Jul 25 18:28 wc/
>   $ /tmp/tmp> cd wc
>   $ /tmp/tmp/wc> mkdir a b
>   $ /tmp/tmp/wc> svn add *
>   A         a
>   A         b
>   $ /tmp/tmp/wc> svn commit -m "just testing"
>   Adding         a
>   Adding         b
>
>   Committed revision 1.
>   $ /tmp/tmp/wc> cd ..
>   $ /tmp/tmp> rm -fr wc
>   $ /tmp/tmp> svn co file:///tmp/tmp/repo/a file:///tmp/tmp/repo/b
>   Checked out revision 1.
>   $ /tmp/tmp> dir
>   total 16
>   drwxr-x---    3 mprice   mprice        177 Jul 25 18:29 file:/
>   drwxr-x---    7 mprice   mprice        484 Jul 25 18:28 repo/
>   $ /tmp/tmp> du --max-depth 5 file\:/
>   120     file:/tmp/tmp/repo/b/.svn
>   128     file:/tmp/tmp/repo/b
>   136     file:/tmp/tmp/repo
>   144     file:/tmp/tmp
>   152     file:/tmp
>   160     file:
>
This makes Justin's unhappiness about -d going away seem more justified.

SOmeone in that thread said that it was obvious what's a url and
what isn't.  I'd say that subversion needs to catch this case, if only
because it's likely to happen early in a user's experience, and
colour their view of the project.

Regards

Kieran



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org