Re: Resolution of 'svn diff' change?

On Mon, May 19, 2003 at 10:29:49AM -0500, Ben Collins-Sussman wrote:
> cmpilato@collab.net writes:
> > 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?

I do, because I often flit from task to task as ideas come to me. They
rarely overlap much in terms of code (so I make sure I don't get into a
situation where I can't track problems), but I commonly have code files,
documentation, and packaging files all open simultaneously. It's quite
easy to keep those separate, and frequently I only worry about it when
I'm preparing to commit (so at that point I'd separate the changed files
into distinct changesets). If anything goes wrong, I can always save the
patch off somewhere and revert, but I *do* use the iterative case to
verify which bit is which. One of the major reasons I use revision
control in the first place for even single-person projects is that it
stops me losing track of where I am due to my often undisciplined and
hummingbird-like working habits.

(Certainly, if two changesets start overlapping in terms of either files
or code flow, I save and revert one of them. I'm not quite that manic.
But it's entirely possible and frequent for me to have two changesets in
the same directory which don't overlap significantly, particularly in a
codebase I know well so that I know what will and won't affect something
else.)

Also, my home directory is a Subversion working copy, running at several
hundred commits at the moment. As above, having my home directory in
revision control stops me losing track of what's going on over multiple
systems and as I switch from task to task before disciplinedly finishing
and synchronizing everything. The rationale for revision control in each
case is very similar for me. So, at the moment, I have (cut-down
sample):

 M .
M .bash_profile
M .bashrc
M .environment
M .gqview/accels
M .gqview/gqviewrc
A .offlineimaprc
? .putty
M .reportbugrc
M .sawfish/menus.jl
M .spamassassin/user_prefs
M .vimrc

There's absolutely no problem keeping all of this open at once;
.bash_profile and .vimrc can hardly ever interact with each other at
all. I definitely want to test configuration changes before I commit
them to use on other systems, but it would take weeks to do anything if
I insisted on doing this separately for every change; and I've got very
used indeed to the iterative case because I often want to see the
changes to e.g. just all the shell configuration files at once. For
example, testing .spamassassin/user_prefs takes some time because I have
to wait for mail to come in, so it tends to stay open a lot. I'd wager
that anyone who keeps a home directory in CVS does the same kind of
thing.

I guess that, while I do often have a number of concurrent changesets
going at once in development projects, my home directory is the
iterative case's killer app for me.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org