I think you have made a very persuasive argument here for doing a clean every time. I'm not worried about how long the unit tests take to run, since we don't have any yet ;-) sad but true.
As a follow up question though... about the "clean" target, does the clean target typically delete the source files so that they have to be retrieved from revision control by scratch, or just the obj, lib, exe and other intermediate files? Do you have two separate targets for these different levels of clean? and how do you typically use the two levels? We have fairly small teams here, and structural changes (adding or deleting a directory for example) are not frequent. Even adding source files isn't something that happens every day. -Kelly > -----Original Message----- > I personally think that it's very important for a Continuous > Integration build to be as definitive as possible. That is, if a > developer checks in some changes and triggers a build, if he gets a > "build successful" message then that needs to mean that his/her > changes didn't break anything (that is covered by automated tests). > > If a clean is only performed every five builds, for exampe, then a > developer may get a "build successful" after removing a method that is > used from a different project because the clean target wasn't run... > then a few builds later, some other developer gets the "build failed" > message, but can't understand it because it involves code that s/he > didn't touch... or even worse, it *does* involve code s/he touched, > and so wastes time trying to find out what s/he did wrong when the > build was actually broken by someone else. E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
