[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-10-01 20:44:20 CEST

On 01 Oct 2001 10:11:23 -0500
kfogel@collab.net wrote:

> Mo DeJong <supermo@bayarea.net> writes:
> > 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).
>
> How is it exposing the implementation? Or do you just mean by virtue
> of being called "-u" / "--show-updates"? Its output is certainly
> nothing like `update's output.

The output has nothing to do with it. I don't think the user is going to
get confused as to which subcommand they ran when looking at the
output. The problem I have with the --update flag to the status command
is that is mixes the update concept into the status command. A user is
going to have to learn and remember why status --update is different
than update and remember it from that point on. The flag should indicate
that the svn client will contact the repository and display status information
for "interesting" files. It should not be named after the implementation,
namely running update --dry-run behind the scenes.

This might not seem that critical, but I would be willing to bet that end users
would much a much easier time learning subversion if the functionality
provided by subcommands does not overlap. For example, a new user would
not expect to create patches using the commit command or apply them using
update. If you ask me, CVS is hard to learn because it mixes totally different
concepts into the same commands.

cheers
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:43 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.