>
> 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.
I don't even know which camp i'm in, as far as what my 'primary use
case' is.
> 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?
As far as I'm concerned, "svn diff --iterative" would work exactly the
same way as the proposed "svn zort" (assuming 'svn zort' was to cover
the iterative, not comparative case).
So either proposal has exactly the same complexity, except that you have
longer help for 'svn diff' instead of two different helps (which, I
admit, is a disadvantage of using the option, though IMO a minor one).
The only other difference is whether the user types "svn zort ..." or types
"svn diff --iterative ...".
> 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'."
My main beef is with the name, but if we have trouble with the names, it
often indicates an underlying conceptual flaw. The above explanation
suffers from the same flaw as the names: how is "seeing my local changes"
not just a special case of "comparing any two things"? The answer, IMO,
is that it *is* just a special case. Whenever you want to "see your local
changes", even in the iterative case, you're saying "here's a *set* of
files in my WC which I want to compare to the corresponding *set* in the
repository."
So, if you ignore syntactic issues, the functionality of the proposed
iterative subcommand is a subset of that of the proposed comparative
subcommand. The ONLY reason for separating them is that we can't figure
out a clean command-line syntax for specifying an arbitrary *set* of
files.
I have a semantic bias. To me it is unclean and confusing to have
one subcommand be semantically a special case of another; I object to
letting syntactic issues override that concern.
I'll still "+0" the proposal if we can come up with clearer names.
But so far, I can't think of good ones.
> At the moment, there *is* no reasonable way to explain 'svn diff':
>
How about:
Use "svn diff" to compare any two things. The various options may be
used to specify what files/revisions you want to compare. The rest is
just details.
?-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 20 00:40:50 2003