The branches are a feature of CVS that allows the development to be partitioned so that one stream does not affect the other. They prove to be useful, when there is a need to perform modifications that are hard to perform as a consecutive gradual transitions that work well in the usual course of development. When files that are depended upon by numerous other files need to be substantially changed all the other would have to be modified along with them. That would require that a lone developer performs all these changes in his own snapshot and then checks them all in, causing the sources to leap forward. As your project grows, situations arise that this is no longer possible. It's good to have version control on the gradual changes as opposed to quantum-leap changes. It's also important to have the larges set of eyes possible looking at the code as soon as possible. On the other hand, we strive to keep Turbine CVS tree compilable and working at all times. This calls for usage of branches whenever vast modifications of the sources are needed.
The CVS book describes multiple approaches to performing development using branches. We decided that the simplest approach called Flying Fish technique will fit our needs best. It involves creating a branch when there is a need for a separate thread of development, and abandoning the branch once all the changes are merged with the trunk. If need arises for separated development on the same subject, a brand new branch is created. This saves us the additional complexity of merging changes back and forth between the trunk and the branches and keeping track of what was merged into where. We want the things to be as simple as possible.
The naming scheme used for the branches is as following: The name of the branch
is composed of a name describing the subject being worked on, followed by an
underscore and a two digit number used to distinguish multiple branches for the
same subject.
Actual tag names are then:
subject_number-sprout for marking the revision of the trunk
where the branch diverged
subject_number-branch for the branch itself
subject_number-before-merge for marking the last revision of
files before merging in the branch
subject_number-merge for marking the revision of the trunk
with changes made on the branch merged in
Below, you can find a list of branches that were used during the development of ${project.name}. The 'coordinating person' is responsible for exchange of information between developers, maintaining the branches and timely merging the changes into the trunk (closing the branch). The shorter a branch stays outside the trunk, the better, because that decreases the number of conflict that will arise while merging back. Developers that are working on the trunk of the CVS should not make modifications to the code named in 'affected sources' to prevent merging conflicts. Instead, they should direct all requests / patches to the coordinating person. Developers wishing to join the development of the branching code, should contact the coordinating person.
If you wish to learn more about branches, download the CVS book at Red Bean.com, or browse a CVS manual online.
PDF Documentation