> I guess what I'm thinking about is that I might commit a few small > but possibly related changes, close together in time - I wouldn't > want each one to trigger a rebuild sequence, I guess I'd want it to > wait until several changes were in and I'd stopped messing about, > then do the rebuild.
As far as I understand the Continuous Integration idea, each commit that you make should be an atomic set of changes which does not break the code, and you then build and test that set of changes, and you are aiming to get a green light at the end of it. If the build/test cycle fails, you can then revert that one commit. Adding a new function call in one commit and then the definition in another commit, and correcting the call parameters in a third is not going to fit well with the Continuous Integration idea. And yes, I deliberately put them that way round even though I know no-one here would do it like that :-) Don't forget, you should have already successfully built the [set of] changes on your own box before you commit it to the central repository where it will be picked up by the Continuous Integration system. D. PS What I want to know is how we all pass the rubber chicken around :-) http://jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
