Version Control Standards

By Michael Flanakin @ 11:01 AM :: 2383 Views :: Development, Patterns & Practices, Configuration Mgmt, Open Source/Standards :: Digg it!

Standards are very important; especially in team environments. One thing that's been getting to me the past few months is what seems to be a lack of standards when it comes managing Visual SourceSafe (VSS) and Team Foundation Server (TFS) repositories. Since most of my version control experience is with Subversion, I want to bounce back to the fact that data in the repositories is managed very simply. You have three (or four) top-level directories that represent the major version controlled entities: branches, tags, and trunk. The term "tag" may not be familiar to some, so let me just say that tags and labels are the same thing -- an ear-marked version of the repository in a significant state. "Trunk" is another term that some may not be familiar with, but it is essentially the main line of code you're working with. I love the fact that Subversion introduces you to these right off the bat because it almost forces you to learn and abide by good version control practices. You don't have this in the VSS/TFS world. For those who caught on to the optional fourth directory with Subversion, that would be shelves. "What? Subversion doesn't support shelving!" you say? Not true. A shelf is simply a branch in the Subversion world Mobile-ready link. (Shameless plug: Woohoo! I'm the first result when searching for shelving in Subversion.)

As I mentioned, digging into VSS and TFS for the first time, you don't really see these same principles. It's too bad, because that can cause chaos in the field. Well, maybe the word "chaos" is too strong of a word; but you'll be hard-pressed to find two implementations that work the same exact way. Putting some thought into it, I guess the best thing I can come up with is having an application directory with branch directories sitting alongside it. For instance, if my application is called MyApp, I would have MyApp, MyApp-1.0, MyApp-2.0, and MyApp-2.1. These map to the main and release branches, respectively. Not rocket science, I know, but I just haven't seen a common practice. If anyone has one, I'd love to hear about it. If I have more than one releasable project within my repository, then I'd include all project-related branches within a parent directory called MyApp, or something similar. Then, other releasable projects could sit alongside this one. Again, pretty simple.

Beyond this structure, which will probably change over the coming months, I also have something else of mild interest. Time and time again, I need to explain version control concepts to developers who haven't dealt with configuration management before. Not that I mind, but I recently created an image to visualize this for a project I'm on. I figured I'd share this for others to take advantage of. Looking at it, it's fairly easy to explain how the release cycle works and when/where branching and merging comes into play.

Note that this isn't specific to any type of repository, so whether you use VSS, TFS, Svn, or any other version control solution, it should apply to you just fine. The dark blue line represents the main branch (or trunk). At some point, a code freeze is identified, which is when the codebase is branched for the release. Testing is performed and bug fixes are applied to the release branch while, at the same time, changes are also made to the main branch for the follow-on release. Once the release branch is considered stable, a tag/label is applied (identified by the red star-burst), the release is deployed, and the changes applied to the branch are merged (identified by the orange line) back to the main branch (or trunk). Over time, while development on the main branch is moving along, there will inevitably be bugs in the production system. Let's just say your next major/minor release isn't for another 6 months. In that case, you'll probably want to do a point release to push out a bug fix or two (ok, 10 or 20 :-P). In this case, developers will pull the latest (aka head) from the specific release branch and apply necessary fixes. This is again tested, tagged/labeled, and re-deployed. To get these changes back into the main branch, the release branch is again merged to the main branch. This process will continue for the life of the project.

Honestly, it's all pretty simple; but as they say, "a picture is worth a thousand words."