cmpilato@collab.net writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
> > cmpilato@collab.net writes:
> >
> > > "Sander Striker" <striker@apache.org> writes:
> > >
> > > > > where (2a) is the only truly sensible decision in my mind.
> > > >
> > > > Oof...
> > >
> > > Yeah. "Only truly sensible" given the base assumption that the
> > > iterative case is truly necessary. I've not fallen to that assumption
> > > yet. :-)
> >
> > Yeah, I'm failing to understand why people need 'svn diff' to default
> > to the iterative case. Justin and Colin have said that the iterative
> > use-case is a part of their "basic svn work-cycle", and Justin said he
> > "often has multiple changesets" in his working copy.
> >
> > (Yikes, this mail is staring to read like a Zagat Restaurant review!)
> >
> > This is not a dig against anybody's work habits... but do you really
> > maintain mulitple changesets in a working-copy? How do you deal with
> > that? I've been there, and it's always such a mess. When I encounter
> > a bug, I never know if it's because of one changeset or another --
> > there are too many changed variables to isolate the problem.
>
> Oh...hmm. You know, I keep multiple changesets in my WC all the
> time. As of a few minutes ago, there was:
>
> 1. new diff syntax
> 2. issue #1015
> 3. the svndumpfilter copy-n-pasto bug
>
> The fact is that unless one changeset overlaps files with another, or
> endangers the testing of another, I have no problems keeping up with a
> few different sets. And now that I think about it, I use the
> iterative diff sometimes (not always -- if my brain is smart enough to
> remember which paths to diff, it's smart enough to remember which
> paths to ignore when I do 'svn diff' from the top of my tree).
>
> --
>
> I'm all for providing all the functionality we can, as long as we
> don't make the UI so cloudy as to be worthless. I really think that
> we can please everyone with 'svn diff' iteratively doing BASE:WORK,
> and 'svn compare (cmp)' doing the more complex work. And I can have
> it all coded up in a couple of hours -- the "new diff syntax" is done,
> sitting as local mods in my working copy ... changeset #1 :-)
So in a private conversation, Ben drilled me on why I would want a new
subcommand over just a --compare flag to diff.
1. 'svn diff' run in the working copy is by and large the lion's
share of uses for this subcommand. It was the original
implementation, on which was later added support for URL-ish and
--revision-ish things.
2. I'd always rather have two clear, concise usage messages for
individual subcommands than one subcommand whose usage message is
so complicated by special-case options and flags that it's
impossible to understand. 'svn diff' is *already* too
complicated to understand, and we're talking about added a flag
that changes the core of the way the arguments are intepreted?
Gimme a friggin' break.
Ben seemed convinced, but asked for those two usage messages. Here
they are:
$ svn help compare
compare (cmp): display the differences between two paths.
usage: 1. compare [-r N[:M]] [TARGET]
2. compare TARGET1[@N] TARGET2[@M]
Display the differences between two targets (one of which may be implied)
in a format suitable for use with most 'patch' programs.
1. In the first syntax, TARGET is either a working copy path
or URL. If no TARGET is specified, a value of '.' is assumed.
Use the -r option to specify revision ranges -- if TARGET is a
URL, this defaults to HEAD:PREV; if TARGET is a working copy
path, the default is to display local modifications.
2. If the alternate syntax is used, TARGET1 and TARGET2
(perhaps at specified revisions N and M, respectively) will
be compared against each other.
$ svn help diff
diff (di): display local working copy modifications
usage: diff [WC-PATH ...]
Display uncommitted modifications made to working copy targets in a
format suitable for use with most 'patch' programs.
My next instructions were to sell the community on the two-subcommand
proposition. :-) (Gee, thanks, Ben)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 18:41:52 2003