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

Re: [RFC] 'basic/additional command set' - adding svn subcommands without destroying our learning curve

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-03 18:59:17 CET

Greg Hudson wrote:
> On Thu, 2005-11-03 at 15:19 +0000, Julian Foad wrote:
>
>>I feel it would be very helpful for our basic "svn help" output to categorise
>>the commands and give information about them, as has been proposed before. (I
>>don't find an alphabetical listing to be of much help.)
>
> I resubmit http://svn.haxx.se/dev/archive-2005-07/0474.shtml as a
> counterargument.

There you said:
> But more importantly, any categorization will make it harder to look up
> a command by candidate name. If I can't remember whether it's "svn
> resolve" or "svn resolved", I can find that out in about two seconds
> with the current "svn help" output. With categorized output, I have to
> read over all the categories first and guess which category the
> developers thought resolve/resolved fit into.

I don't buy that. For one thing, I don't see that as being a particularly
common usage. I see "svn help" being used mainly to discover half-remembered
abilities like "What was that command that lets me discard the results of this
conflicted merge?" For another, I don't envisage there being so many
categories or commands that you can't skim through them in about two seconds.
For another, you can easily pipe the categorised output through "sort" to get
back your alphabetical list (with the various category headers bunched together
at the top or bottom of the output).

You may want to make sortability a design criterion for that reason. That
would just restrict our choice of text layout; that's fine by me.

> I don't think version control commands naturally
> categorize.

Of course they do, to some extent. OK, not cleanly; there may be some overlap
and ambiguity, but that's the case in all complex systems. That doesn't mean
we can't do something useful.

> I can live with basic/additional since the best alternative is to make
> the additional command not exist at all.

Well, why do you think we can categorise them into "basic" and "additional" but
not anything better? I haven't yet seen or thought of any reasonable basis on
which to make that distinction. It's fairly obvious for some commands, but not
for many.

> (I don't want to see us adding
> "purge" and "sync" and "trackdown" and svnversion and so on to the basic
> command set until ours looks like arch's.)

For those who are not aware, I believe this refers to the huge command set that
Arch has.

> If there are slightly
> specialized utility commands which are harder to find, that's arguably a
> better solution than having those specialized utilities scripted by each
> user or dumped into contrib.

I agree that's better.

I think it's time people came up with some concrete proposals for dividing up
the commands, including the definition of the categories and the list of
commands in each.

Note that we could have categories that overlap; that wouldn't necessarily be
ugly or confusing if presented appropriately.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 19:00:12 2005

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.