Thursday, June 14, 2007

Subversion with a staging area

Most bad builds comes from people commiting source code that have not been fully tested. If you have a single trunk approach, you'd get into situations where someone commits some bad code and everyone suffers when they do an update with the bad code.
Note: This is just theory. I have not implemented this yet.
ClearCase with UCM provides a concept of an integration stream and each developer having their own maintenance stream which gets incorporated. So if you have ClearCase and use UCM great. However, for those that do not have the money for it you can have something similar using Subversion.
Subversion branches are O(1) operations, so setting the structure up in Subversion should be pretty fast.
What we do is add another folder in the root called user-workspaces this folder in turn contains one folder for every user workspace which should be the name of the user generally. Each user workspace folder is an svn copy of trunk.
The user workspace is what the developers check out and commit their changes to.
The Cruise Control build server checks out files from trunk and tries to svn merge each user workspace into it. If it detects a conflict, the build stops as a failure. If there are no conflicts, then Cruise Control continues with the build. If the build is successful, the local build copy with all the merged code is committed to trunk.
Then it applies all the merged changes to each of the user workspace folders in the repository and commits them. So when the developers do an update they would get all the latest changes and their local copy will work provided their changes do not actually cause a build to fail.
If the operation of copying the merged changes to the developer fail (because a developer has committed some change which is not mergable while a build is being executed). Then we have a problem. :( I haven't figure out how to solve that issue yet short of locking everything down while a build is running.

0 comments: