Keeping kernel sources in a CVS tree is quite handy if you're working on your own set of kernel changes. Doing so is quite easy, but can look rather difficult when you don't know the trick. This page explains how.

The basic idea behind these guidelines is that you treat kernel sources from Linus or Alan as vendor branches, and that you branch your own development kernel tree from the vendor branch.

The guidelines on this page assume that you have some basic knowledge about CVS and that you created a mylinux module. If you don't have the knowledge, there are several ways to learn more about CVS:

• Read The Fscking Manual (man cvs)

• The [http://www.cvshome.org/docs/manual/ online CVS manual]

• The [http://faq.cvshome.org/fom.pl CVS FAQ]

• The excellent book [http://cvsbook.red-bean.com/ Open Source Development with CVS]

Importing the kernel source

Prerequisites:

• CVS repository
• Kernel source tree

Now let's assume that the kernel you want to import is linux-2.4.7:

• cd linux cvs import -ko -I '!' -m "import linux-2.4.7" mylinux linus linus_2_4_7

This imports linux-2.4.7 into the mylinux module using vendor branch linus and vendor tag linus_2_4_7. We also tell CVS to import all files (-I '!') and not to do keyword substitution (-ko).

Importing an -ac kernel tree is as easy:

• cd linux cvs import -ko -I '!' -m "import linux-2.4.7-ac10" mylinux alan alan_2_4_7_ac10

Adding even more vendor branches is left as an excersise to the reader. Creating your own work branch

Prerequisites:

• CVS repository

To create a branch to hack on your own kernel from one of the vendor branches, use:

• cvs rtag -r linus_2_4_7 -b my_2_4_7 mylinux

This creates a branch my_2_4_7 from the linux-2.4.7 kernel tree. Checking out your own branch

Prerequisites:

• CVS repository

Check out your newly created branch:

• cvs checkout -r my_2_4_7 mylinux

Now cd mylinux and start hacking on your own kernel source tree. Upgrading to a newer kernel version

Prerequisites:

• CVS repository
• CVS sand box

If you want to upgrade to a new kernel version, first import that kernel version and create your own work branch for it, like described previously.

Now commit your changes to your current work branch:

• cd mylinux cvs commit

Update your sand box to the new work branch (assuming it is called my_2_4_8):

• cvs update -dP -r my_2_4_8

Merge in the differences from your previous work branch:

• cvs update -dP -j linus_2_4_7 -j my_2_4_7

Now start solving the merge conflicts (if any) and continue hacking on the new work branch. Creating a diff

Prerequisites:

• CVS repository
• CVS sand box

A diff between arbitrary kernel versions can be made without any sand box:

• cvs rdiff -u -r linus_2_4_0 -r alan_2_4_7_ac10 mylinux > mydiff

This creates a unified diff (-u) file between linux-2.4.0 and linux-2.4.7-ac10.

You can also make a diff between your current sand box and an arbitrary kernel version:

• cd mylinux

  cvs diff -u -N linus_2_4_6 > mydiff

(Note that the -N flag only works with recent versions of CVS. Earlier versions produce a patch of changed files only.)

Problems with existing CVS tags.

Some kernel developers use CVS privately, and the diffs they send Linus for inclusion contain tags such as $id: $ If you add a file without using the -ko option, CVS will perform substitution on that file, which makes for noisy diffs against vanilla trees. If you forgot to use -ko, all is not lost. You can 'fix' the repository by using cvs admin -ko But get into the habit of importing/adding files with -ko