Branching in CVS splits a project's development into separate, parallel histories. Changes made on one branch do not affect the other branches. Branching can be used extensively to maintain multiple versions of a product for providing support and new features.
Merging converges the branches back to the main trunk. In a merge, CVS calculates the changes made on the branch between the point where it diverged from the trunk and the branch's tip (its most recent state), then applies those differences to the project at the tip of the trunk.
The main trunk of the source tree and the various branches should have a owner assigned who will be responsible for.
Keep the list of configurable items for the branch or trunk.
The owner will be the maintainer of the contents list for the branch or trunk. This list should contain the item name and a brief description about the item. This list is essential since new artifacts are always added to or removed from the repository on an ongoing basis. This list will be able to track the new additions/deletions to the repository for the respective branch.
Establish a working policy for the branch or trunk.
The owner will establish policies for check-in and check-out. The policy will define when the code can be checked in (after coding or after review etc.,). Who is responsible to merge changes on the same file and resolve conflicts (the author or the person who recently changed the file).
Identify and document policy deviations
Policies once established tend to have exceptions. The owner will be responsible for identifying the workaround and tracking/documenting the same for future use.
Responsible for merge with the trunk
The branch owner will be responsible for ensuring that the changes in the branch can be successfully merged with the main trunk at a reasonable point in time.
As part of the release process, the entire code base must be tagged with an identifier that can help in uniquely identifying the release. A tag gives a label to the collection of revisions represented by one developer's working copy (usually, that working copy is completely up to date so the tag name is attached to the “latest and greatest” revisions in the repository).
The identifier for the tag should provide enough information to identify the release at any point in time in the future. One suggested tag identifier is of the form.
release_{major version #}_{minor version #}
As one reader pointed out to me, a good practice here is to tag the release first. Checkout the entire codebase using the tag, and then proceed to go through a build / deploy / test process before making the actual release. This will absolutely ensure that what “leaves the door ” is a verified and tested codebase.
After each software release, once the CVS repository is tagged, a branch has to be immediately created. This branch will serve as the bug fix baseline for that release. This branch is created only if the release is not a bug fix or patch release in the first place. Patches that have to be made for this release at any point in time in the future will be developed on this branch. The main trunk will be used for ongoing product development.
With this arrangement, the changes in the code for the ongoing development will be on the main trunk and the branch will provide a separate partition for hot fixes and bug fix releases.
The identifier for the branch name can be of the form.
release_{major version #}_{minor version #}_patches
This practice extends from the previous practice of creating a separate branch after a major release. The branch will serve as the code base for all bug fixes and patch release that have to be made. Thus, there is a separate repository “sandbox” where the hot fixes and patches can be developed apart from the mainstream development.
This practice also ensures that bug fixes done to previous releases do not mysteriously affect the mainstream version. In addition, new features added to the mainstream version do not creep into the patch release accidentally.
Since all the bug fixes for a given release are done on its corresponding branch, the patch releases are made from the branch. This ensures that there is no confusion on the feature set that is released as part of the patch release.
After the patch release is made, the branch has to be tagged using the release tagging practice (see Tag each release).