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 Jetspeed 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 Jetspeed 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 develompent
on the same subject, a brand new branch is creted. 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-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 Jetspeed.
The 'coordinating person' is responsible for exchange of information between developers,
maintaing the branches' TODO and timely merging the changes into the trunk (closing the branch).
The shorter a branch stays outside the trunk, the better, because that decrases 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.