Joe Orton <joe@manyfish.co.uk> writes:
> > I know that in case 1, some people would really like to see the
> > revision fields go; but I feel strongly about *not* changing
> > the way status lines look based on switches.
>
> That's another argument in favour of doing this as "update --dry-run"
> rather than as some switch to status. The functionality you want is
> "what will happen if I run svn update"; doing this as a switch to modify
> the behaviour of update makes much more sense to me than overloading
> status. The "do one thing and do it well" principle?
Yes, but Joe -- your argument is asymmetrical.
I mean, why can't I declare that what you really want is a subcommand
like "svn commit --dry-run", and define status to do nothing but show
out-of-dateness?
status has always had two functions: to show "dry runs" of what would
happen in a commit, and what would happen in an update. I don't have
a good sense as to why either one of these functions should be demoted
to a switch on some other subcommand. I mean, yes, the "predict
commit" function is used more often -- but isn't it enough of a
compromise to therefore make it the *default* status behavior, rather
than making it the *only* status behavior?
---------------------------------------------------------------------
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:41 2006