Build system thoughts

[Bill Barry]

John D. Mitchell wrote:
> Some questions to help clarify the context:
>
> * How big/complex are your incremental/full builds?  In other words, 
> what's the purpose of your CI system?  Is this for the centralized 
> monitoring/reporting, pristine build environment, etc. or do you need 
> it because the builds are so large/complex that they can't be done 
> e.g., locally?
The builds generally aren't too complex, but they do take a couple of 
minutes (15-30 now usually, but this is constantly growing) for 
automated tests and such to run. The purpose for it is:
1. monitoring the health of the entire tree
2. being able to report on build state for any branch
3. find branches that both the developer and the tests say are good for 
merging into the main tree

Builds are small enough to be done locally, but it is unlikely that 
developers will run all tests for every build (or even every commit). It 
is much more likely that the dev will ensure the build compiles and 
*maybe* that what he is working on correctly runs. I don't want to even 
force the devs to do that, I want to encourage many small commits 
knowing that we can wait to merge them until after the developer feels 
the work is done and that the CI environment says the build successfully 
passes all tests.
>
> * What are you trying to gain by using branches instead of clones?
One of the big pain points for using clones is configuration when 
working on webapps and windows services. Every time we need to work in a 
different directory we need to open up IIS and switch the directory (or 
perhaps sets of virtual directories, we have one app that uses 3 vdirs, 
one for the app and 2 for webservices the app uses). We also have to 
remove and reregister a windows service every time we switch from one 
clone to another.
>
> * How do you deal with releases and other long-lived versions?
tag a release and branch for bugfixes (the same way we do now); I am not 
sure what you are asking here
>
> * How do you deal with feature branches that multiple people are 
> working on together?
Since all the feature branches are in the central repository, and are 
pushed and pulled from all the developers, we can simply update to them.