> > Committing logically different changes separately is a good idea,
> > but initially making those changes in a single working copy is not,
> > especially if the changes occur to an overlapping set of files.
> For two large logical sets, this is generally true. However, I find
> myself in the following two situations several times a day:
> - I have added printf() statements for debugging, and want to commit
> the fix. The fastest way to do this is to do a commit, pick out all
> the hunks that encompass the fix, and commit those. After that, a
> 'revert' cleans up the rest of the code. I cannot do a revert prior
> to committing, because it erases the fix itself.
One way to do it is to make a branch, commit the printfs
separately from the "real" changes, and merge just the latter
to the trunk.
(One can also just check in the printfs, using a "DEBUG"
macro, but that's not always a good solution.)
> - I am working on a bigger change, and all of the sudden find out
> some bug that needs fixing. Instead of doing a fresh checkout, re-
> compile the whole project (which can take hours), fix the bug,
> commit, erase the working copy, i can just work on my precompiled
> working copy, fix the bug, and commit the small fix.
For my most active projects I very often have multiple WCs.
One is typically a "pristine" trunk checkout.
To make a small fix, I sometimes temporarily use that one.
Even though that makes it unpristine :) it's a small fix so very brief...
BTW, don't you *want* people to make sure the project still builds,
passes its testsuite etc. before checking in a fix? :) But
half-jokes aside, here is how I often do what I think you are
Say I have a complicated project with "a", "b", "c", ... "z" modules.
And I've been making non-trivial changes to all of them.
Then I find some trivial unrelated thing I want to fix in module "m".
Here's what I do to make the change separately:
mv m m.save
svn up m
# edit "m" for trivial fix
svn ci m -m "trivial fix"
rm -rf m
mv m.save m
svn up m
I take advantage of svn's "detachable" working copy directories
all the time...
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Oct 19 21:47:06 2006