simple use case advice

[Eric Siegerman]

On Thu, 2010-09-30 at 16:45 -0700, Chris Hecker wrote:
> I was really wondering if there was a cool dvcs way to do the
code-level 
> binary search for the bug, where I move pieces of the N+1 changelist 
> over one at a time.  I'm going to try that first.

If N+1 is a simple, but large, revision, then there's none that
I'm aware of.  But if it's the merge of a multi-revision branch,
you can use the "bisect" plugin to track down which of the revs
on that branch introduced the bug.  But I suspect you already
knew that... 

> But, I'm interesting in any other advice people have, since I'm still 
> trying to wrap my head around developing with this branch thing.

This is why it's good to work on feature branches in the first
place.  Make finer-grained commits on the feature branch, rather
than one stonking big commit directly on trunk.  Besides being
easier to follow later, this gives you a series of discrete
changes to run a bisection on, should you need to.

A feature branch is (typically) private to one developer, so
breaking it won't impact anyone else's work (as long as the
breakage is fixed before the feature lands in trunk).  Thus you
can -- and should! -- relax, for commits to feature branches,
whatever quality constraints you have on commits to trunk.  Clean
build, tests passing, etc.; none need apply to feature-branch
commits.

That said, if adding a method parameter touches 3000 lines in 100
source files, well, there's no real way to subdivide that (short
of a larger refactoring, which might be advisable in its own
right but is beyond the scope of this discussion).


Another trick I've found useful -- and this applies equally to
CVCSs -- is to segregate reformatting into its own commit.  If
I'm reindenting a source file, or reordering methods within it,
or (shudder!) stripping <CTRL-R>s, there should be no substantive
change whatsoever, even though almost every line of the file
might be textually changed.  The same goes if I'm adding a bunch
of comments interspersed throughout the code.  So I'll commit
such a change separately, and explicitly say "no substantive
change" in the commit message.  That tells me, should I later
have track down a bug, to ignore this large, hard-do-diff
revision, unless and until bisection (whether manual or
automated) proves that it's the one where the error was
introduced.

  - Eric