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

Re: svn commit: rev 158 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client trunk/subversion/clients/cmdline

From: Mo DeJong <supermo_at_bayarea.net>
Date: 2001-09-28 23:46:33 CEST

On 25 Sep 2001 12:55:35 -0500
Ben Collins-Sussman <sussman@collab.net> wrote:

> sussman@tigris.org writes:
> > Author: sussman
> > Date: 2001-09-25 17:49 GMT
> > New Revision: 158
> >
> > The shiny new 'svn status'.
> >
> > Three independent flags: -n (--nonrecursive)
> > -u (--show-updates)
> > -v (--verbose)
> >

This is great. The status subcommand is now much more useful
than it was. Still, there is one thing that continues to
bother me about the way we are presenting status functionality
to the user. If I were to rattle off a quick summary of the
status and update commands, it might look like:


The status command displays information about version
controlled files. The file status can include modifications,
additions, deletions, renames, and merge conflicts. By
default, status information for files in the working copy is
displayed. The user can indicate that status information
for files in the repository should also be displayed by
passing the $FLAG option.


The update command will incorporate changes committed
to the repository into the user's working copy.

These two subcommands don't really have anything to do
with each other. That bothers me because the
-u/--(show-)update flag to the status subcommand
muddies the waters. It provides the functionality
(see changes in repo) in a way that exposes the
implementation (update --dry-run). It also uses
the -u option and I thought we were going to use
that with the diff command.

I really think we need to rename that --update flag.
What if we used --repository/--repo instead? I know
this may not seem like a critical change, but little
usability issues like this have a way of turning into
"new user" problems down the road. By then, we all
know it will be too late to change the code because
someone would have written a bunch of scripts that
depend on a certain command line option.

Perhaps we should just finish up the user manual before
making any more changes to the user interface.
It seems that things like which flags are accepted
by which subcommands are going to get even more
tricky as time passes and more options are added.
There are only 26 letters we can use for short
command options like -u and each subcommand can't
go off and do its own thing since the options
are parsed in main(). I would be more than willing
to work on this stuff next week if folks can agree
that is needs doing.

Mo DeJong

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006

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.