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 [http://old.kernelnewbies.org/faq/index.php3#acpatches.xml -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