From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24240 invoked by alias); 7 Mar 2003 17:08:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24233 invoked from network); 7 Mar 2003 17:08:45 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 7 Mar 2003 17:08:45 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h27H8cV20374; Fri, 7 Mar 2003 09:08:38 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [dictionary] commit for 2003-03-06 References: <3E68B3A3.10805@redhat.com> From: David Carlton Date: Fri, 07 Mar 2003 17:08:00 -0000 In-Reply-To: <3E68B3A3.10805@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00167.txt.bz2 On Fri, 07 Mar 2003 09:58:43 -0500, Andrew Cagney 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