When you import a project into CVS, you create two branches: HEAD (or the main branch) and a vendor branch. Typically there are no further changes to the vendor branch, and development focuses on HEAD.
The vendor branch was put there for problems like that of our linux tree : tracking a "vendor". When 2.4.1 was imported, it was given the vendor branch Vendor_Linux and the release tag of LINUX_2_4_1. When version 2.4.2 was imported, it was given the same vendor branch, and release tag LINUX_2_4_2 (see a pattern?).
Whenever there is a new version of the Linux kernel we want to sync with, we should first tag the current HEAD state:
cvs tag LAST_2_4_7
Now we can use the CVS import command to put the unpatched new source on the vendor branch:
cvs import -I ! linux-2.4 Vendor_Linux LINUX_2_4_8
(the -I ! is very important - it cancels CVS' behavior of ignoring some files).
Notice here that we are using import on raw source, not patching and checking in. This has the interesting side effect of not removing old files. This means you almost never want to check out the head of the Vendor_Linux branch.
We first import the source without all the patches (like XFS...) because we want to have a reference point within the CVS tree. Now we can always get back to the virgin source for this release. You can disregard conflicts at this point.
Now we need to add in all the non-Cobalt patches. At the time of this writing, that was XFS and kgdb. To do this, apply all the patches to the distribution source (not the checked out source -- we're going to import it again). Make sure you generate clean diffs as you go, and that everything patches in cleanly. Once you have a clean tree with all the patches applied, import it again.
cvs import -I ! linux-2.4 Vendor_Linux LINUX_2_4_8+PATCHES
This will make the vendor branch have the current distribution linux kernel plus all the patches about which we care. If we have modified files (and we have) there will likely be conflicts. Now we need to merge those changes into the HEAD branch. To do this, you have several choices - you can try to merge all the conflicting files by hand, or you can let CVS try for you.
Back up your existing kernel CVS tree, in case you need to make quick diffs. Now run:
cvs checkout -ko -j LINUX_2_4_7+PATCHES -j LINUX_2_4_8+PATCHES linux-2.4
This will take all the diffs between 2.4.7 and 2.4.8 (with all patches applied) and try to merge them with the current HEAD and drop it onto your system. If head is sufficiently clean (doubtful), you can just CVS commit the changes. More probably, you will have to find conflicts and resolve them. Use this command to show you conflicts:
cvs -nq update -d
Any lines flagged with a C are conflicts. Merge those. This may be very hard - do what you need to do to get this codebase in sync. Once you have all the conflicts merged. Compile and test the darn thing, PLEASE!!!
Once you have verified that your changes are OK, run the above CVS command again. Make sure there are no more conflicts, and that all the files in the list are actually meant to be committed. If all is clear, you can, at last, commit your changes.
cvs commit
Now that you have brought HEAD in sync with the currently released version, you have to tag the tree - do this RIGHT AWAY, lest you forget.
cvs tag LINUX_2_4_8+PATCHES_MERGED
Now it is apparent to anyone with sufficient clues what is going on. There is a 2.4.3 vendor tag and a 2.4.3_merged HEAD tag. Beautiful.
The last thing to do is add the clean patches to the unofficial-patches directory on the Vendor_Linux branch.
If you choose not to follow these guidelines, and I am still in the business of maintaining the kernel code-base, I will hunt you down and slap you with a 5.25" floppy disk.
Thanks for listening :)
--Tim
In general, we want to avoid this, if we can. However, sometimes it is really necessary. We will deal with this entirely on the vendor branch.
Check out the latest LINUX tag from the Vendor_Linux branch. These are the tags that have the form LINUX_2_4_6. If there are already patches applied, see the "Patches on patches" section below.
cvs co -ko -r LINUX_2_4_6 linux-2.4
or
cvs co -ko -r LINUX_2_4_6+PATCHES linux-2.4
Once you have this checked out, you can apply the patch in question. Make sure to merge any conflicts and remove any extraneous files. Also, make sure to run make distclean. You can find problems with this command:
cvs -nq update -d
Once you are patched up, you want to make it safe to import. To do this, you need to remove the CVS directories. This removes the ability to compare with the CVS tree, so be sure you are ready.
find . -type d -name CVS | xargs rm -rf
Now you have a clean, patched source base to import. If your patch did not apply cleanly, you'll want to take this chance to run a diff against a checkout of the same tag, but unpatched. This will give you a clean-applying patch for later. Now you can import.
cvs import -I ! linux-2.4 Vendor_Linux LINUX_2_4_6+PATCHES
Now you can follow the directions above to merge these changes into the head brach, and tag it with LINUX_2_4_6+PATCHES_MERGED.
For future maintenance, new kernel releases should be done as follows:
The last thing you need to do is update the unoffical patches. Checkout the new +PATCHES tag, first. In the unofficial-patches directory, do:
cvs update -r Vendor_Linux
Add the new patch (preferably bzipped):
cvs add -kb newpatch.bz2
(note the '-kb' option. It is needed for binary files).
Now update the PATCHES file, and commit these changes. These files only live on the head of the Vendor_Linux branch, and should never be tagged with any kernel.
Whew, I am sure I missed something, bit hopefully that will do for now, until experience teaches us more.