Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 24568 invoked by uid 500); 22 Mar 2001 18:08:15 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 22485 invoked from network); 22 Mar 2001 18:05:59 -0000 Content-return: allowed Date: Thu, 22 Mar 2001 10:05:33 -0800 From: David Martinez Subject: RE: Mozilla-style VersionBlame? To: "'ant-user@jakarta.apache.org'" Message-id: <55B75BC35F1AD1499ACF45A9EEB069867D2AA7@essfo01.ad.food.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C0B2FA.B092CD88" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B2FA.B092CD88 Content-Type: text/plain; charset="iso-8859-1" Well, I don't really mind that, because what I'm trying to do is not actually point a finger, but get people to talk to each other in an environment where unit testing is already prevalent. Here's the scenario again: - Jack checked in a piece of global.h that works fine, but changes struct X - It breaks a Jill's foo.c which uses struct X, and VersionBlame (TM) :-) notifies Jill Now Jill's needs to: 1) Change her source file to match the new global.h. Small change to accomodate the new struct X. No big deal. 2) The new global.h struct X is just =weird= (maybe it was a linked list and now it's a btree that should not be malloc'ed/freed, but needs an allocateX function in global.c that sets some pointers to fixed places, chants to the god of C, and other things Jill should not be doing herself. So now... 2.1) Jill looks Jack up (last $author in global.h) and beats him senseless - eeeer - I mean, asks him where is the unit test function for global.h that he maintains and shows the new usage of struct X. 2.2) Jack, like everyone else for their code is required to maintain a unit test for the global.c/.h pair's general usage. 2.3) Jill uses this unit test function as a template to redo her foo.c the right way. 2.4) Any other conflicts that may make her unable to use the test as a template (maybe she was using struct X for a completely different purpose than intended) come to light right away, showing the need for other functions, or Jack's disconnect with struct X's usage reality. In the end, they both end up being smarter - now Jack knows foo.c file uses X member of global.h (and can sleep at night knowing it's being used in the way he intended it to, which will prevent all kinds of problems), and Jill knows where the authoritative code example for using that weird struct X lives. Eventually, the build breaks less and less at night (wishful thinking, I know). So really, the breaking of the build one time is not anyone's "fault" - in most good teams - and not a big deal. What I'm trying to do is turn the build into an automated, active participant of the conversation that should be taking place between the developers and sometimes just doesn't. But that's an excellent implementation idea! Thanks, - David -----Original Message----- From: Diane Holt [mailto:holtdl@yahoo.com] Sent: Wednesday, March 21, 2001 4:23 PM To: ant-user@jakarta.apache.org Subject: Re: Mozilla-style VersionBlame? Hi David, I'm not familiar with how Mozilla is doing this, but I think everything you'd need to do the build-verification/failure-notification part of it with Ant is already available. Whenever I've set up a system like what you're wanting to do, I've always done it on a build-per-change basis -- otherwise, you could potentially be pointing a finger at the wrong change (eg., Jill changes foo.c, and Jack changes global.h and introduces a bug -- foo.c now fails to compile, not because of Jill's change, but because of Jack's, but there's no way for the automated system to know that -- it just sees that foo.c's compile failed). So you'd want some mechanism -- outside of Ant, hooked to your SCM tool -- that triggered a "verification build" whenever a change was submitted. The "verification build" is where Ant would come into it. Ant picks up the change, runs the build, and if the build failed, does all the things you want done once that happens. You'd use things like XmlLogger to generate your HTML page and a listener (see the FAQ for the example that sends mail on a failure), and whatever task(s) you'd need to use to capture the change information (eg., , ,