I have a Kiln/Mercurial code repository for a web app that uses Cruise Control.NET for continuous integration. Normally, we commit our code locally and when we're ready to test, we push to our central Kiln server. Cruise Control regularly checks the repository on that server for a new revision and when it finds it, it builds it and copies the resulting files out to the appropriate web server. If it tests out, we then manually force a build to our main production server and all is good.
Recently however, we had a small hiccup. We found a bug in a version that was pushed out to production last month and it needs to be fixed. There have been 50 or so commits since then and the code introduced in those 50 commits is nowhere near ready for production. We know we can locally roll back (update) to the version that was pushed out to production and fix the code but we have no way to push that to Kiln and get it out to Cruise Control -- Mercurial on the Kiln server complains of multiple heads. What's the best way to tackle this?
We've googled around a bit and found references to branching and tags. We ended up making a new branch in the repository on the Kiln server. That branch had our main repository minus those 50 commits. We then made our bugfix and edited the Cruise Control configuration to look there instead of the main repository. After some builds, we had our bug fixed on the production server. This seems like a substantial amount of work to roll back, make a fix, and push that to a web server.
Since we're a small shop, we usually have our own projects to work on. There's been no intentional branching (until now) and even minimal merging so although we're not new to version control, there are somewhat common aspects to that concept that we haven't had to deal with yet.
