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

Re: Emphasizing commonly-used commands in 'svn help' output.

From: <kfogel_at_collab.net>
Date: 2005-07-12 07:04:56 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> On Mon, 2005-07-11 at 12:26 -0500, kfogel@collab.net wrote:
> > "Yeah, but adding options to existing commands is confusing, look
> > at how often people mess up 'svn switch --relocate'!"
>
> The right answer to the svn switch debacle is to further unify switch
> and relocate, not to further separate them.
>
> If you truly object to the plan in
> http://subversion.tigris.org/issues/show_bug.cgi?id=2104 then make a
> cogent argument against it and we'll close the issue. If you don't,
> then please, for the love of all that is good and true, stop dredging up
> this example.

s/object to/had completely forgotten about even though commented on/

This issue apparently hasn't been as prominent in my cognosphere as in
yours. I had completely forgotten about it, thanks for the reminder.

> > By default, 'svn help' would only show the commonly-used commands that
> > a new user would be most likely to want to see in help output.
>
> A terrible idea, to me. We can't predict what commands a new user will
> be interested in. Some of them may be used to locking every file; some
> of them may need partial checkouts; some of them may be mostly examining
> a project's history; others may be doing lots of branching and merging;
> some may be interested in our five property commands and some may not.

I had thought that most users cluster around the same subset of
commands, but I guess you're right, usage patterns can differ widely.

(How do you feel about columnar or otherwise grouped output?)

> All you're really proposing to do is make it less obvious how to get a
> full list of commands.
>
> This idea came up on the arch lists frequently, as an alleged solution
> to tla's 100+-strong command set. It's not a solution. The only
> solution is to resist the urge to add subcommands for specialized
> operations. The serious solutions have been complete reworkings of the
> command set to have fewer commands (baz and now apparently revc).

Please don't confuse "solution" with "alleviation". I'm not expecting
a full solution; I'm looking to make a mild problem milder, if the
cost isn't too high.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 12 07:54:28 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.