client README stuff

[Bruce Korb <bk...@cruzio.com>]

  Parsing Command-Line Arguments
  ==============================

  The CVS custom of switching on a subcommand seems to work out pretty
  well, so we'll do the same thing.  But many people have mentioned that
  having separate global versus command-local option namespaces is

< confusing.  So Subversion has one option namespace, and all options
< come after the subcommand.
---
> confusing.  So each subversion subcommand will have one option name
> space and all options come after the subcommand.

   svn  [<subcommand>]  [<option> ...]  [<argument> ...]

Notes: the subcommand is marked as optional because there are a few
cases where Subversion can do something meaningful without the

< command, for example, "svn --help".
---
> command.  Specifically, `svn --help' is supported, along with the
> short option equivalents of `svn -h', `svn -?' and `svn -H'.

  [[Do we really want all these aliases supported directly?
  One of these, fine.  The others could just be declared invalid
  and cause an abbreviated help message. - b]]

===============


  -v --version VER     Like "cvs -r" Subversion does not have revisions,
                       we have versions. Multiple version #s are
                       separated by a `,'

This spec conflicts with the usual and customary usage of the
`--version' option.  I am _strongly_ in favor of minimizing such
differences and do not see a compelling reason for a variation here.
How about `--file-version' or `--repository-version' or
`--object-version'?  *ANY*thing except `--version', please.

===============

Re: client README stuff

[Matthew Braithwaite <ma...@braithwaite.net>]

On 31 Oct 2000 08:52:00 -0600, Karl Fogel <kf...@galois.collab.net> said:
> 
> Okay; your arguments seem pretty good to me.  I'd like to hear what a
> few other people think before we change it.

W.r.t. the naming issue (not sure that's what you meant), ``revision''
has the authority of Cederqvist, whence I learned my CVS:

  Versions, revisions and releases
  
  A file can have several versions, as described above. Likewise, a
  software product can have several versions. A software product is
  often given a version number such as `4.1.1'.
  
  Versions in the first sense are called revisions in this document, and
  versions in the second sense are called releases. To avoid confusion,
  the word version is almost never used in this document.

Of course I am always reminded by that word of what one of my
professors thought was one of the few jokes in St. Thomas Aquinas's
_Summa Theologica_:

  ... the argument is either from authority or from reason.  If it is
  from authority, it seems unbefitting its dignity, for the proof from
  authority is the weakest form of proof according to Boethius.
  (Part 1, Question 1, 8th Article, Objection 2)

Re: client README stuff

[Jim Blandy <ji...@savonarola.red-bean.com>]

Karl Fogel <kf...@galois.collab.net> writes:

> Okay; your arguments seem pretty good to me.  I'd like to hear what a
> few other people think before we change it.
> 
> -K
> 
> Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> > Karl Fogel wrote:
> > 
> > > There's nothing horribly wrong with "revision" and -r, as long as we
> > > change all the code and other documentation to match.
> > > 
> > > We need to consistently call them either "revisions" or "versions".
> > > The latter is slightly easier to say, and even when discussing
> > > CVS-controlled files, people often slip into saying "version" instead
> > > of "revision" anyway.  That's (I suspect?) why we just started using
> > > the word "version" in our original drafts (Jim, was there any other
> > > reason?).

No, nothing more substantial.  Version is simpler to say.  I guess
"revision" hit me as more of a circumlocution.  But see below...


> > > What do other people think about this issue?
> > 
> > I'd say we should try to avoid ambiguities. Watch ...
> > 
> >     svn -v (--version? --verbose (or is that -V)? --object-version?)
> > 
> > And now ...
> > 
> >     svn -r (--revision, yeah.)

Hmm... the former *is* a mess.  I can never remember how to tell GCC
to show me the subprograms it's running.


> > I also think we should retain at least /some/ similarity with CVS' 
> > interface. We want people to switch from CVS to SVN, so we should make 
> > it easy for them.

Perhaps so, but we're screwing around with the whole concept of
versions enough anyway.  I don't think the transition will be
brainless for anyone.


> > Besides, "revision" is more correct than "version", although people keep 
> > mixing the terms. Like "liberty" and "freedom", eh?. :-)

My dictionary says:

    version: a form or variant of a type or original <an experimental ~ of
    the plane>

    revision: 1b: a result of revising 2: a revised version

So revision(2) is really the closest to what we have in mind.

It's fine with me.

Re: client README stuff

[Karl Fogel <kf...@galois.collab.net>]

Okay; your arguments seem pretty good to me.  I'd like to hear what a
few other people think before we change it.

-K

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> Karl Fogel wrote:
> 
> > There's nothing horribly wrong with "revision" and -r, as long as we
> > change all the code and other documentation to match.
> > 
> > We need to consistently call them either "revisions" or "versions".
> > The latter is slightly easier to say, and even when discussing
> > CVS-controlled files, people often slip into saying "version" instead
> > of "revision" anyway.  That's (I suspect?) why we just started using
> > the word "version" in our original drafts (Jim, was there any other
> > reason?).
> > 
> > What do other people think about this issue?
> 
> I'd say we should try to avoid ambiguities. Watch ...
> 
>     svn -v (--version? --verbose (or is that -V)? --object-version?)
> 
> And now ...
> 
>     svn -r (--revision, yeah.)
> 
> I also think we should retain at least /some/ similarity with CVS' 
> interface. We want people to switch from CVS to SVN, so we should make 
> it easy for them.
> 
> Besides, "revision" is more correct than "version", although people keep 
> mixing the terms. Like "liberty" and "freedom", eh?. :-)
> 
> -- 
> Brane �ibej
>     home:   <br...@xbc.nu>           http://www.xbc.nu/brane/
>      ACM:   <br...@acm.org>          http://www.acm.org/

Re: client README stuff

[Branko Čibej <br...@xbc.nu>]

Karl Fogel wrote:

> There's nothing horribly wrong with "revision" and -r, as long as we
> change all the code and other documentation to match.
> 
> We need to consistently call them either "revisions" or "versions".
> The latter is slightly easier to say, and even when discussing
> CVS-controlled files, people often slip into saying "version" instead
> of "revision" anyway.  That's (I suspect?) why we just started using
> the word "version" in our original drafts (Jim, was there any other
> reason?).
> 
> What do other people think about this issue?

I'd say we should try to avoid ambiguities. Watch ...

    svn -v (--version? --verbose (or is that -V)? --object-version?)

And now ...

    svn -r (--revision, yeah.)

I also think we should retain at least /some/ similarity with CVS' 
interface. We want people to switch from CVS to SVN, so we should make 
it easy for them.

Besides, "revision" is more correct than "version", although people keep 
mixing the terms. Like "liberty" and "freedom", eh?. :-)

-- 
Brane �ibej
    home:   <br...@xbc.nu>           http://www.xbc.nu/brane/
     ACM:   <br...@acm.org>          http://www.acm.org/

Re: client README stuff

[Karl Fogel <kf...@galois.collab.net>]

There's nothing horribly wrong with "revision" and -r, as long as we
change all the code and other documentation to match.

We need to consistently call them either "revisions" or "versions".
The latter is slightly easier to say, and even when discussing
CVS-controlled files, people often slip into saying "version" instead
of "revision" anyway.  That's (I suspect?) why we just started using
the word "version" in our original drafts (Jim, was there any other
reason?).

What do other people think about this issue?

-K 

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> Bruce Korb wrote:
> 
> > < confusing.  So Subversion has one option namespace, and all options
> > < come after the subcommand.
> > ---
> > 
> >> confusing.  So each subversion subcommand will have one option name
> > 
>                         ^ Should be capital S?
> 
> >> 
> >> space and all options come after the subcommand.
> > 
> [snip]
> 
> > This spec conflicts with the usual and customary usage of the
> > `--version' option.  I am _strongly_ in favor of minimizing such
> > differences and do not see a compelling reason for a variation here.
> > How about `--file-version' or `--repository-version' or
> > `--object-version'?  *ANY*thing except `--version', please.
> 
> I'd go with --object-version, although what's wrong with --revision is 
> beyond me ...
> 
> -- 
> Brane �ibej
>     home:   <br...@xbc.nu>           http://www.xbc.nu/brane/
>      ACM:   <br...@acm.org>          http://www.acm.org/

Re: client README stuff

[Branko Čibej <br...@xbc.nu>]

Bruce Korb wrote:

> < confusing.  So Subversion has one option namespace, and all options
> < come after the subcommand.
> ---
> 
>> confusing.  So each subversion subcommand will have one option name
> 
                        ^ Should be capital S?

>> 
>> space and all options come after the subcommand.
> 
[snip]

> This spec conflicts with the usual and customary usage of the
> `--version' option.  I am _strongly_ in favor of minimizing such
> differences and do not see a compelling reason for a variation here.
> How about `--file-version' or `--repository-version' or
> `--object-version'?  *ANY*thing except `--version', please.

I'd go with --object-version, although what's wrong with --revision is 
beyond me ...

-- 
Brane �ibej
    home:   <br...@xbc.nu>           http://www.xbc.nu/brane/
     ACM:   <br...@acm.org>          http://www.acm.org/