Typically, development in Rave is done against trunk; however, occasions arise where significant modifications to the code base are to be made or there is a desire to keep working on an older version of trunk. In these instances, a branch should be created to support committing incremental changes that might leave the codebase in a non-ideal state or provide support for an older version.

This page describes how branches are managed in Rave

Creating a new branch

Branches should be created sparingly and for valid cause. The committer proposing the branch should announce their intention to create the branch, provide a rationale and use lazy consensus before creating the branch.

The actual task of creating a branch can be accomplished in many ways, one of which is documented in the svn book

Keeping the branch up to date

If the purpose of the branch is to develop large sets of modifications intended to be integrated into trunk, it is crucial that a working branch continually merge changes in from trunk. Merging instructions can be found in the aforementioned svn book.

Integrating the branch into trunk

Before merging changes from the branch back to trunk, the committer should seek lazy consensus. The period for this consensus should vary depending on the nature of the changes and the degree to which they will modify the codebase. If the committer is unable to determine an appropriate time, 72hrs can be used to be sure that the entire community has the opportunity to review the changes.

Branches that are to be merged back into trunk should use the --reintegrate flag when merging the changes from the branch to trunk. See the svn book for more details on the operation of merging.

Branch Removal

Removal of a branch should be evaluated on a case-by-case basis. In general, if a branch was created for the sole purpose of making large code changes, it is a potential candidate for removal. Again, use the lazy consensus model to give everyone the opportunity to provide feedback.