Here's a quick mini-howto keep the local kernel changes under CVS w/o going nuts. We won't go into how to use CVS much, since it is rather easy to use. We'll just cover how to do vendor branches. Please send feedback to email@example.com
CVS allows one to create vendor branches. Think of Linus as the Linux vendor. He releases kernels from time to time and you have to integrate them with the local patches you've made. You'll need approximately 1.5x the current source size for disk storage. This could grow large in time, so be advised. This represents between 15-20M typically. If you don't have the disk to burn, then get more disk.
The first step is to get CVS and RCS, build it, install it. It is basically a "./configure ; make ; make install" sort of deal, so I'll not go into detail here.
Now there is one thing that you'll need to do with linux. Since there is a file named core in the distribution (net/core to be precise), you'll need to modify your cvsingnore list to not ignore this file. Here's what I use in my cvsignore file:
! RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* *.old *.bak *.BAK *.orig *.rej .del-* *.a *.o *.obj *.so *.Z *.elc *.lnThis list is taken from the CVS info file, and has had core removed. I don't think there is anyway to just remove core from the list.
Once you have done that, and have created the repository in the last section, you'll need to actually import the sources. I've edited the info files from CVS on how to do this. In general, the info files are a wonderful source of information on CVS and shouldn't be overlooked.
In the terminology used in CVS, the supplier of the program is called a "vendor". In the case of Linux, this would be Linus Torvalds. The unmodified distribution from the vendor is checked in on its own branch, the "vendor branch". CVS reserves branch 1.1.1 for this use.
When you modify the source and commit it, your revision will end up on the main trunk. When a new release is made by the vendor, you commit it on the vendor branch and copy the modifications onto the main trunk.
Use the `import' command to create and update the vendor branch. After a successful `import' the vendor branch is made the `head' revision, so anyone that checks out a copy of the file gets that revision. When a local modification is committed it is placed on the main trunk, and made the `head' revision.
Use the `import' command to check in the sources for the first time. The import command takes three args. The first arg is the directory in the repository that you add, in our case linux. The second arg is the "vendor tag," while the third arg the "release tag." When you use the `import' command to track third-party sources, the "vendor tag" and "release tags" are useful. The "vendor tag" is a symbolic name for the branch. The "release tags" are symbolic names for a particular release, such as `V1_3_64'.
You start by importing the source to your reposiotry
At this point, you need to checkout your sources. The cvs checkout command will do that for you. Go to your development area (away from the CVS area and the area you used to import the linux sources from) and checkout the sources. If you keep all the os hacking in ~/src/os, then the following works:
Now that we have a clean version of the sources, we can import them again.
Now that you have imported the sources to the LINUX vendor branch (and it is important to always use the same Vendor Tag), you need to merge them with your own changes. To do this, "just" check out the files with the CVS merge option.
CVS isn't perfect. It will sometimes require that you do manual
merging by hand. When this is the case, you'll find that the files
have had long strings of less than (<), greater than (>) and
equals signs (=) inserted. You will need to merge these by hand. Any
good suggestions for this text here would be welcomed.
$Id: howtocvs.html,v 1.1 1996/12/31 04:28:01 imp Exp $