|
Size: 3970
Comment:
|
← Revision 4 as of 2013-03-15 20:38:06 ⇥
Size: 0
Comment: We don't use cvs any more. FIXME: make git page.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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` ---- CategoryDocs |
KernelNewbies:
- Diff for "Documents/KernelSrcInCVS"
Differences between revisions 3 and 4