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 :-)
---------------------------------------------------------------------
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:15:24 2003