Chris Rathjen has a post requesting information on how we deal with branching in change management so I thought it would make a good post subject.

At Exony we use Perforce as our source control system for two reasons: it's wickedly fast plus the branch and integration features are excellent. It is similar to SourceSafe in that the repository is structured much like a file system. We have a number of products that use internally developed shared libraries and third party SDKs. The tree on the left of the diagram below shows how things are structured. The right hand side shows the version lines with branch and integrations.

Each product or library has a folder which contains sub-folders representing available versions. All new development happens on the main branch. The nightly build scripts will attempt to integrate changes into the build branch (orange arrows) and then rebuild. If, for any reason, the build fails then the integration is rolled back. This ensures the build branch is always in a build-able state. Perforce change sets come in handy here because you can either commit or revert them based on the build outcome.

When it's nearly time to ship we branch the latest build branch into a "QA" folder (green arrows). This is the v1.0, v2.0, etc folder. This is the build that gets QA'd before it goes out of the door. Any fixes are still made in the main branch and once the nightlies copy the code into the build branch, we do manual integrations into the QA branch. This way we can verify that nothing major is going to de-stable the QA line.

After a release any fixes are made in the correct versioned branch before being reverse integrated back to the mainline if they are still relevant there (not shown on diagram).

Also, every time a build script is run the file versions in that branch are labelled with the build number. That way we can go back to any build on any branch if needed.

The third party SDKs, e.g. Microsoft SOAP or MSXML4, are also stored. These third party folders only contain headers, libs and DLLs used in the build process as there is no reason to store additional binaries such as CHM files.

Sharing code is also based on branching and integration (red dotted lines). Once a shared library is released then its actually integrated into the relevant product mainline. That way we isolate the product from any changes that may be happening to the shared libraries or any other product.

Overall the process works well and we haven't had any build related late nights since implementation (although there have been a couple of product related ones). It's nice to be able to hit a button, grab a coffee and wait for your product ISO to drop out at the end ready for burning onto CDs.