No. I'm not talking about committing to a source control system. I'm talking about the different models you can use when committing your code to your source control system. Why am I talking about it? Well, David Starr over at Elegant Code is asking the question, and he lists out two popular models. You'll have to go read the post for the details, but the two can basically be broken down into a standard check-in / check-out model and a branch and merge model.

He mentions Perforce as poster child for the branch and merge model, but I've used Perforce and while it's great for doing that type of development, we used it in the standard check-in / check out mode, with a higher level merge function to create our test and release builds.

From my experience, and I've used VSS, SVN, CVS, Vault, PerForce, and MKS, and I've never seen anyone use the branch / merge model for everyday development. Most development project I've been a part of typically do use branching, but usually for one of two purposes: Either after the fact, to be able to continue maintenance on releases while the main trunk can still be moved forward.

The other time we branch is when we are working on a major feature that multiple need to work on at the same time. We typically try to keep our main trunk in good condition, and if we have a major feature that needs to be done, we'll branch it, and have that branch be unstable while it's being finished. Once it's done, we merge it back into the main branch. It's higher level than what David lists - the branch / merge process isn't on every check in. It's on the high level features.

And that's what PerForce offers you - if you look at the development branch as the branch and the test branch as the trunk, then developers are always working on the branch, and when a build is ready, the appropriate check ins are merged back into the trunk (test branch). The same model is used to move from test (the branch) to release (the trunk). But in essense, to developers, you're still using the same check-in / check-out style of source control use.

I'm sure it's possible that others do it differently, and could require a branch on every check-out, but my guess is the way I described is fairly common. And in case you're wondering, the project we used PerForce on had thirty or more developers in multiple locations, and was a huge project that's in some restaurants throughout the nation. It was a big project, and that's where I think we saw the most benefit from using PerForce.