Ben Collins-Sussman <firstname.lastname@example.org> writes:
> email@example.com writes:
> > "Sander Striker" <firstname.lastname@example.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 :-)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 19 18:15:24 2003