ClearChain

CVS

Benjamin Close

This page contains various helpful hints for using CVS.

Contents

 [hide]

Importing To a NEW Vendor Branch

This directory contains virgin sources of the original distribution files on a “vendor” branch. Do not, under any circumstances, attempt to upgrade the files in this directory via patches and a cvs commit. New versions or official-patch versions must be imported. Please remember to import with “-ko” to prevent CVS from corrupting any vendor RCS Ids.

To upgrade to a newer version of a project, when it is available:

  1. Unpack the new version into an empty directory.

[Do not make ANY changes to the files.]

 cvs import -ko -m 'Virgin import of Project v<version>' www/share/contrib/project VENDOR project_<version>

Do not, under any circumstances, deviate from this procedure.

To make local changes to cpio, simply patch and commit to the main branch (aka HEAD). Never make local changes on them VENDOR branch.

All local changes should be submitted back to the maintainer of the project for inclusion in the next vendor release.

Importing to an EXISTING Vendor Branch

This text is taken from: http://www.mewburn.net/luke/papers/3rdparty-and-cvs.html Many thanks to the author as it has saved me lots of grief.

It is rare for third-party software to remain unchanged forever; updates are available (even on a regular basis).

An important part of managing third-party software is upgrading to a newer version in a sane way.

The process to import an updated version of a package is similar to importing the original package. However, because changes in the newer version may conflict with any local changes that you may have made to the product, there are a couple of steps that are different.

In this example, we’ll be upgrading dhcp 2.0b1 from pl18 to pl27.

In the directory containing the extracted source import the new version:

 % cvs import -m 'ISC dhcp 2.0b1pl27' net/dhcp ISC dhcp-2-0-b1-pl27
 U net/dhcp/CHANGES
 C net/dhcp/Makefile.conf
     ...
 U net/dhcp/server/dhcpd.leases.cat5
 1 conflicts created by this import.

Use the following command to help the merge:

 cvs checkout -jISC:yesterday -jISC net/dhcp

As you can see there was a conflict on the import (Makefile.conf; the file with the status character of “C”). This is CVS’s way of indicating that those files have been modified from the previous release of the vendor code. Checkout the updated source, automatically merging in any changes. Whether or not CVS suggests a checkout command, you should use a checkout of the form:

 cvs checkout -j old-release-tag -j new-release-tag module

old-release-tag is the previous release tag, and new-release-tag is the one just imported.

For this example the cvs command is:

 % cvs checkout -j dhcp-2-0-b1-pl18 -j dhcp-2-0-b1-pl27 net/dhcp
 U net/dhcp/CHANGES
 U net/dhcp/Makefile.conf
 RCS file: /src/cvsroot/net/dhcp/Makefile.conf,v
 retrieving revision 1.1.1.1
 retrieving revision 1.1.1.2
 Merging differences between 1.1.1.1 and 1.1.1.2 into Makefile.conf
 	...
 U net/dhcp/server/dhcpd.leases.cat5

The advantages of using checkout -j old-release-tag -j new-release-tag include:

Remember; always use cvs checkout -j old-release-tag -j new-release-tag when checking out code for the first time after you have updated a vendor release. It saves a lot of time.

Search for and resolve any conflicts. A couple of CVS commands are useful for this. cvs update will show any files modified, added, or removed by the vendor between releases.

 % cvs update
 M Makefile.conf

Note that even though include/site.h was locally modified in the previous release, it does not show up as modified here. This is because it was not actually modified by the vendor between the two vendor releases.

cvs diff will display any changes between the last release and this code; changes either from local updates or from the new release. The diff output will also display our changes to include/site.h.

It is probably more useful to use cvs diff -r VENDOR to display changes between the most recent vendor release and this code:

 % cvs diff -r ISC
 Index: Makefile.conf
 =======================================================
 RCS file: /src/cvsroot/net/dhcp/Makefile.conf,v
 retrieving revision 1.1.1.2
 diff -r1.1.1.2 Makefile.conf
 133a134,141
 > ## RMITCS overrides
 > #BINDIR = /usr/local/sbin
 > #CLIENTBINDIR = /usr/local/sbin
 > #ADMMANDIR = /usr/local/man/cat1m
 > #FFMANDIR = /usr/local/man/cat4
 > #VARRUN = /var/run
 > #VARDB = /var/run/dhcp
 > #SCRIPT=none
 Index: includes/site.h
 =======================================================
 RCS file: /src/cvsroot/net/dhcp/includes/site.h,v
 retrieving revision 1.1.1.1
 retrieving revision 1.2
 diff -r1.1.1.1 -r1.2
 39a40
 > #define _PATH_DHCPD_PID       "/var/run/dhcpd.pid"
 45a47
 > #define _PATH_DHCPD_DB        "/var/run/dhcpd.leases"
 50a53
 > #define _PATH_DHCPD_CONF      "/usr/local/etc/dhcpd.conf"

Peruse the output of the diffs and determine if things look reasonable. In this case I am fairly happy with the changes. Refer to the CVS info documentation [4] node “Conflicts example” for more information on resolving conflicts.

Ignoring files via cvsignore

There are certain file names that frequently occur inside your working copy, but that you don’t want to put under CVS control. Examples are all the object files that you get while you compile your sources. Normally, when you run ‘cvs update’, it prints a line for each file it encounters that it doesn’t know about (see section A.16.2 update output).

CVS has a list of files (or sh(1) file name patterns) that it should ignore while running update, import and release. This list is constructed in the following way.

   RCS     SCCS    CVS     CVS.adm
   RCSLOG  cvslog.*
   tags    TAGS
   .make.state     .nse_depinfo
   *~      #*      .#*     ,*      _$*     *$
   *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
   *.a     *.olb   *.o     *.obj   *.so    *.exe
   *.Z     *.elc   *.ln
   core

In any of the 5 places listed above, a single exclamation mark (‘!’) clears the ignore list. This can be used if you want to store any file which normally is ignored by CVS.

Specifying ‘-I !’ to cvs import will import everything, which is generally what you want to do if you are importing files from a pristine distribution or any other source which is known to not contain any extraneous files. However, looking at the rules above you will see there is a fly in the ointment; if the distribution contains any ‘.cvsignore’ files, then the patterns from those files will be processed even if ‘-I !’ is specified. The only workaround is to remove the ‘.cvsignore’ files in order to do the import. Because this is awkward, in the future ‘-I !’ might be modified to override ‘.cvsignore’ files in each directory.

Note that the syntax of the ignore files consists of a series of lines, each of which contains a space separated list of filenames. This offers no clean way to specify filenames which contain spaces, but you can use a workaround like ‘foo?bar’ to match a file named ‘foo bar’ (it also matches ‘fooxbar’ and the like). Also note that there is currently no way to specify comments.

Branches / Merging Branches / Trunk Merging

This example was taken from: http://dri.freedesktop.org/wiki/CvsPolicy

 

How to check out a branch

  cvs co -r <keyword>-<revision>-branch xc

How to make a branch

You have no checked out trees

If you want to use the main trunk as the anchor for your branch:

  cvs rtag -b <keyword>-<revision>-branch
  cvs co -b <keyword>-<revision>-branch

If you want to use some other tag as the anchor for your branch:

  cvs rtag -b -r <tag> <keyword>-<revision>-branch
  cvs co -b <keyword>-<revision>-branch

You have a checked out trunk, and you want to tag it and start using it as a branch

  cd <root-of-your-checked-out-tree>
  cvs tag -b <keyword>-<revision>-branch
  cvs update -r <keyword>-<revision>-branch

This makes the {{{<keyword>-<revision>-branch}}} tag sticky. You can verify this by using {{{cvs status}}}, for example in `XFree39/xc`, do this:

  cvs status Makefile

or

  cvs status -v Makefile

How to merge the trunk into your branch

Before you merge your code into the trunk you should first merge the latest trunk code into your branch. After merged code has been tested on your branch, merging into the trunk should be simple.

  cvs tag <keyword>-<revision>-<date>-freeze
  cvs update -d -j HEAD
  cvs tag <keyword>-<revision>-<date>

How to merge your branch to the main trunk

to date (i.e., in case you changed some files from between the time you merged the trunk onto the branch until you merged the branch onto the trunk).

You can make the tag with:

  cvs tag <keyword>-<revision>-<date>
  cvs update -A

(Alternatively, you can just check out a new copy of the main trunk.)

  cvs update -j <keyword>-<revision>-branch
  cvs commit -m 'Merged <keyword>-<revision>'
  cvs tag <keyword>-<revision>-<date>-merge

Say you keep hacking on your branch after the merge to test a few extra things and you want to merge again. You get the main trunk checked out, as in step 1, then you merge only those changes between your last merge and the most recent revision in your branch:

  cvs update -j <keyword>-<revision>-<date> \
             -j <keyword>-<revision>-branch
Exit mobile version