in starting anything new at this point, so he just decides to go home.
Eddie never checks anything into the main trunk. He only checks stuff into his private branch, and then merges changes into the trunk. His care and attention to detail are admirable, but he's spending far more time using his source control tool than working on his code.
Let's not even think about what the kids would be like if Eddie and Nelly were to get married.
Once you established the proper level of comfort with the branching features of your source control tool, the next question is how to use those features effectively.
One popular methodology for SCM is often called "code promotion." The basic idea here is that your code moves through three stages, "dev" (stuff that is in active development), "test" (stuff that is being tested) and "prod" (stuff that is ready for production release):
- As code gets written by programmers, it is placed in the dev tree. This tree is "basically unstable". Programmers are only allowed to check code into dev.
- When the programmers decide they are done with the code, they "promote" it from dev to test. Programmers are not allowed to check code directly into the test tree. The only way to get code into test is to promote it. By promoting code to test, the programmers are handing the code over to the QA team for testing.
- When the testers decide the code meets their standards, they promote it from test to prod. Code can only be part of a release when it has been promoted to prod.
For a variety of reasons, I personally don't like working this way, but there's nothing wrong with it. Lots of people use this code promotion model effectively, especially in larger companies where the roles of programmer and tester are very clearly separated.
I understand that PVCS has specific feature support for "promotion groups," although I've never used this product personally. With other source control tools, the code promotion model can be easily implemented using three branches, one for dev, one for test, and one for prod. The Merge Branches feature is used to promote code from one level to the next.
Eric's Preferred Branching Practice
Best Practice: Keep a "basically unstable" trunk
Do your active development in the trunk, the stability of which increases as you approach release. After you ship, create a maintenance branch and always keep it very stable.
Here at SourceGear our main development tree is called the "trunk." In our repository it is rooted at $/trunk and it contains all the source code and documentation for our entire product.
Most new code is checked into the trunk. In general, our developers try to never "break the tree." Anyone who checks in code which causes the trunk builds to fail will be the recipient of heaping helpings of trash talk and teasing until he gets it fixed. The trunk should always build, and as much as possible, the resulting build should always work.
Nonetheless, the trunk is the place where active development of new features is happening. The trunk could be described as "basically unstable," a philosophy of branching which is explained in Essential CVS , a fine book on CVS by O'Reilly. In our situation, the stability of the trunk build fluctuates over the months during our development cycle.
During the early and middle parts of a development cycle, the trunk is often not very stable at all. As we approach alpha, beta and final release, things settle down and the trunk gets more and more stable. Not long