[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Resolution of 'svn diff' change?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-05-19 17:29:49 CEST

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.

So when I need to switch tasks mid-stream, I'll run

  $ svn diff > task1.patch
  $ svn revert . -R
  $ patch -p0 < task2.patch

And as a result, I almost never run 'svn diff' on a list of
targets... I either want to look at changes to a single file, or look
at the whole set of changes within '.'

Justin, or someone else, can you talk more about why the iterative
'svn diff' usage is important to you? I'm trying to stand in your
shoes.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 17:31:06 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.