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.
> Sound familiar? :-)
Frustratingly so.
> 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.
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 12 03:21:10 2005