Title:  Branch Management
Notice:    Licensed to the Apache Software Foundation (ASF) under one
           or more contributor license agreements.  See the NOTICE file
           distributed with this work for additional information
           regarding copyright ownership.  The ASF licenses this file
           to you under the Apache License, Version 2.0 (the
           "License"); you may not use this file except in compliance
           with the License.  You may obtain a copy of the License at
           .
             http://www.apache.org/licenses/LICENSE-2.0
           .
           Unless required by applicable law or agreed to in writing,
           software distributed under the License is distributed on an
           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
           KIND, either express or implied.  See the License for the
           specific language governing permissions and limitations
           under the License.

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](../governance/lazyConsensus.html) 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](http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html)

####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.