• Immutable Page
  • Info
  • Attachments

Diff for "Documents/KernelSrcInCVS"

Differences between revisions 2 and 4

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`
Tell others about this page: