Robert Pluim <rpluim@bigfoot.com> writes:
> > I have a hunch, though, that that's going to be difficult -- which,
> > to me, is evidence that an option is better than a new subcommand.
> > Furthermore, i'd make the comparative case the default, and use
> > '--iterative' for the iterative case, since "svn diff --comparative"
> > is IMO redundant.
> >
>
> +1 on that. The comparative option should be the default (and I'm
> tempted to say it should be the only option, but I'm anal enough to
> have one working copy per change, so I don't have the need that other
> people have expressed for the iterative version).
Well, once again, we have two camps.
A bunch of people claim that examining local diffs iteratively is
their primary use-case of 'svn diff', and a different bunch of people
say the primary use-case is for comparing two named objects. I'm not
sure how to resolve this.
Ghudson did make a good point about 'svn diff' not necessarily losing
the -r flag.
Either way, I can't *possibly* imagine adding a 5th use case to 'svn
diff'. It's already ridiculously confusing. All you people
advocating that we add more switches -- you don't think this is true?
This is why I was supporting cmpilato's proposal to create a new
subcommand. Brian Denny objected to naming it 'compare'... but forget
about the name for moment. Suppose we call the new subcommand
'zort'. What I'm pushing for is the KISS principle. Suppose you need
to explain differencing to a complete svn newbie. I like this
explanation:
"If you want to see your local changes, run 'svn diff'. If you
want to compare any two things, run 'svn zort'."
At the moment, there *is* no reasonable way to explain 'svn diff':
"If you want to see your local changes, run 'svn diff' with no
arguments. If you want to compare any two things, then start
adding -r switches (with either one or two revisions), or @
switches attached to urls, [or possibly an --incremental option.]"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 23:50:51 2003