ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Martinez <dmarti...@food.com>
Subject RE: Mozilla-style VersionBlame?
Date Thu, 22 Mar 2001 18:05:33 GMT

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., <exec>, <propertyfile>, <script> -- whatever
works for your needs), etc.

Diane

Mime
View raw message