Branching
In
the introduction to this chapter, I defined a branch as a forked line
of development in your project, with the line that has been forked
off called the branch, and the main line the trunk. CVS builds the
branch and the trunk from the same source data, up until the point at
which they diverge, which is called the
base
of the branch. From that point, CVS
stores the changes made to the branch separately from the changes in
the trunk. Revisions on the branch are given their own revision
numbers, based on the revision number of the base of the branch.
You can branch a single file, any group of files, or a whole project just as you can tag individual files or any group of them. I usually recommend branching a project. In my experience, if you branch one file, you will eventually need to branch others in the project for the same reason. It is much easier to keep track of a single branch over the whole project than a group of unrelated branches of individual files.
A tag marks a specific revision of each tagged file, and a sandbox checked out with that tag cannot be changed. In contrast, a branch creates revisions that can be edited, committed, checked out, updated, and tagged independently of the revisions on the trunk. In many ways, a branch can be treated as an independant development line of a project.
You can tag a file with any number of tags, as long as each tag name in that file is unique. CVS also allows you to tag branch revisions with several tags on the branch. CVS ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access