Re: [dictionary] commit for 2003-03-06

[David Carlton <carlton@math.stanford.edu>]

On Fri, 07 Mar 2003 09:58:43 -0500, Andrew Cagney <ac131313@redhat.com> said:

>> I'm going to try to remember to post my commits to
>> carlton_dictionary-branch.  They won't always be the prettiest
>> commits: I usually commit once at the end of each day that I've
>> done any work on the branch, assuming that I leave it in a working
>> state (which I almost always do!); this means that a commit may
>> contain something that I plan to continue the next day, and it also
>> may contain bits of unrelated tasks that I'm working on.  Also, the
>> ChangeLogs aren't great: they're written in a way that is easy to
>> generate, as opposed to a way that is easiest to review years in
>> the future.

> Even if it doesn't build, do you care?

Yes: one of the ground rules that I've set myself is to always keep
the branch in a working state, by which I mean that if you type 'make
carlton' (which builds it and runs a subset of the test suite), it
passes.  ('make namespace' should also work, too, which runs tests in
a different way.)  It keeps me honest, and it means that people can
use the branch without paying close attention.  I run the full test
suite every once in a while, too, but that's less important: usually,
my changes aren't of a sort that will only cause failures in random
tests.

And I don't find it any harder to work that way.  There are occasional
(but quite rare) times when I wonder if it would be easier to make a
large change directly at the cost of breaking things for a few days
instead of breaking it up into smaller steps where things always work.
But that has its hidden costs: if you screw up when making a large
change, it's hard to tell where you did it, whereas if you always
leave things in a working state, then it's much easier to find your
error.

This happened when I was converting blocks from the mechanism the
mainline uses to a more modular mechanism: I had to take the extra
time to build up some intermediate scaffolding to support both
mechanisms simultaneously, but the advantage was that, say, when I
switched from the old hashtables to the new hashtables and saw tests
starting to fail, I knew that the only place I had to look for
problems was in the new hashtable mechanism, making it easy to find
the bug.  The extra scaffolding really didn't take much extra time at
all; and now that I've done that sort of thing once, I'm sure that I
could do it even more quickly in the future.  Safe, baby steps were
also essential when cleaning up linespec.c: when I started that, I had
no clue how the code worked, so I couldn't have gotten anywhere if I
hadn't proceeded via safe baby steps (running the entire test suite
after every change to back me up).

David Carlton
carlton@math.stanford.edu