Go to the previous, next section.
If you modify a program to better fit your site, you probably want to include your modifications when the next release of the program arrives. CVS can help you with this task.
In the terminology used in CVS, the supplier of the program is called a vendor. The unmodified distribution from the vendor is checked in on its own branch, the vendor branch. CVS reserves branch 1.1.1 for this use.
When you modify the source and commit it, your revision will end up on the main trunk. When a new release is made by the vendor, you commit it on the vendor branch and copy the modifications onto the main trunk.
Use the import command to create and update
the vendor branch. After a successful import
the vendor branch is made the `head' revision, so
anyone that checks out a copy of the file gets that
revision. When a local modification is committed it is
placed on the main trunk, and made the `head'
revision.
Use the import command to check in the sources
for the first time. When you use the import
command to track third-party sources, the vendor
tag and release tags are useful. The
vendor tag is a symbolic name for the branch
(which is always 1.1.1, unless you use the `-b
branch' flag---See section import options). The
release tags are symbolic names for a particular
release, such as `FSF_0_04'.
Suppose you use wdiff (a variant of diff
that ignores changes that only involve whitespace), and
are going to make private modifications that you want
to be able to use even when new releases are made in
the future. You start by importing the source to your
repository:
$ tar xfz wdiff-0.04.tar.gz $ cd wdiff-0.04 $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
The vendor tag is named `FSF_DIST' in the above example, and the only release tag assigned is `WDIFF_0_04'.
When a new release of the source arrives, you import it into the
repository with the same import command that you used to set up
the repository in the first place. The only difference is that you
specify a different release tag this time.
$ tar xfz wdiff-0.05.tar.gz $ cd wdiff-0.05 $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
For files that have not been modified locally, the newly created
revision becomes the head revision. If you have made local
changes, import will warn you that you must merge the changes
into the main trunk, and tell you to use `checkout -j' to do so.
$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
The above command will check out the latest revision of `wdiff', merging the changes made on the vendor branch `FSF_DIST' since yesterday into the working copy. If any conflicts arise during the merge they should be resolved in the normal way (see section Conflicts example). Then, the modified files may be committed.
Using a date, as suggested above, assumes that you do not import more than one release of a product per day. If you do, you can always use something like this instead:
$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
In this case, the two above commands are equivalent.
There is no way to tell CVS that some of the files
which are added in a cvs import are binary. So
if you import files, and some of the new ones are
binary, you need to go back and use cvs admin
-kb on the binary files, as described in section Handling binary files.
Go to the previous, next section.