When using source control, the way I am used to working is to develop on the trunk and then branch the trunk just prior to moving into QA.
I was talking with some other people in the department and apparently there are some passionate views about a different way of working, which would be to create the new branch at the very beginning of the development cycle, do development work on that branch, and then merge it back to the trunk at the end. The idea on this approach is to keep the trunk pristine.
While I’m highly skeptical of the claim that one proponent made that the latter approach is the “standard” approach (though happy to be told otherwise), I wouldn’t be surprised to hear that it is fairly common. I can imagine some benefits to that (easier to pick and choose when to deploy which feature or set of features) but also some drawbacks (potential merge issues since every single branch must be merged back to the trunk).
Did some subsequent research and found this: http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx
Would be curious to hear from people their sense for the relative strengths and weaknesses of these approaches are, and also about any other approaches that people may be using.
This is a very similar question to this previous SO item:
Subversion – should anyone be developing off the trunk?
Not exactly identical, but a lot of the concepts in the responses are the same.
My personal opinion? The trunk is for active development; development lines of older versions that you want to keep “pristine” should be held in version branches (and tags for releases). You can still try to maintain a “the trunk should always compile” maxim even with active development being on trunk.