What is a Branch?

In general, a branch is any mechanism that allows one or more developers to modify a file without affecting anyone other than those working on the same branch. There are four kinds of "branch" CVS can manage: 1. The Vendor Branch. A single vendor branch is supported. The "import" command takes a sequence of releases from a source code vendor (called a "vendor" even if no money is involved), placing them on a special "Vendor" branch. The Vendor branch is considered part of the "Main line" of development, though it must be merged into locally modified files on the RCS Main branch before the "import" is complete. See Section 3H ("import"). 2. Your Working directory. A checked-out working directory, can be treated like a private branch. No one but you can touch your files. You have complete control over when you include work committed by others. However, you can't commit or tag intermediate versions of your work. 3. A Development branch. A group of developers can share changes among the group, without affecting the Main line of development, by creating a branch. Only those who have checked-out the branch see the changes committed to that branch. This kind of branch is usually temporary, collapsing (i.e. merge and forget) into the Main line when the project requiring the branch is completed. You can also create a private branch of this type, allowing an individual to commit (and tag) intermediate revisions without changing the Main line. It should be managed exactly like a Development Branch -- collapsed into the Main line (or its parent branch, if that is not the Main Branch) and forgotten when the work is done. 4. A Release branch. At release time, a branch should be created marking what was released. Later, small changes (sometimes called "patches") can be made to the release without including everything else on the Main line of development. You avoid forcing the customer to accept new, possibly untested, features added since the release. This is also the way to correct bugs found during testing in an environment where other developers have continued to commit to the Main line while you are testing and packaging the release. Although the internal format of this type of branch (branch tag and RCS branches) is the same as in a development branch, its purpose and the way it is managed are different. The major difference is that a Release branch is normally Permanent. Once you let a release out the door to customers, or to the next stage of whatever process you are using, you should retain forever the branch marking that release. Since the branch is permanent, you cannot incorporate the branch fixes into the Main line by "collapsing" (merging and forgetting) the release branch. For large changes to many files on the release branch, you will have to perform a branch merge using "update -j -j ". (See 4C.7) The most common way to merge small changes back into Main line development is to make the change in both places simultaneously. This is faster than trying to perform a selective merge.