Tips

Handling reject (.rej) files

using read-only .orig directories

In order to save space and ensure consistency, I always keep some read-only original
kernel trees around, and symlink to them whenever I need to to diffs.

In a "base" directory, I untar each full kernel tree, rename the top directory
with a ".orig" extension, and make the entire thing read-only with chmod -R a-w *

In directory where I'm working, I symlink to this tree with a command like
the following: ln -s ../base/linux-2.6.8.1.orig .

I always do diffs between these one of these read-only .orig directories and
my working directory.

using hardlink tree copies

Geert Uytterhoeven wrote:

If you want to test a lot of trees, each with only a few changes, you may want
to save disk space and manipulation time using these `tricks':

Don't keep 'full' trees around, use 'cp -rl' to clone a tree using hard links and apply the patches to the cloned tree. In 2.6 (contrary to 2.4), it's safe to build in a hardlinked source tree.

Afterwards 'diff -purN' between the original and the cloned-and-modified
tree is blazing fast (on Linux, at least :-).
But be careful when editing files in such a cloned tree, to avoid
unintentional modification of all copies of a file

Q. Do you know if there are any editor wrappers that check for this situation and do the right thing?

Sorry, I don't know. Probably there are. Perhaps just enabling backups with vim

is sufficient. I just became used to manually deleting the file before saving
the modified version. Also keeping pristine source trees owned by a different
user (e.g. 'src') does help, by preventing you from making mistakes.

Someone was working on a dynamic library (to be preloaded using $LD_PRELOAD)
that would wrap around open() and implement copy-on-write semantics for files
in a (configurable) list of directories. You should be able to find it in the
lkml archives. I never tried that library, though.

If you want to go the way of zillions of trees hardlinked together, you may
want to take a look at 'same' (ftp://ftp.bitwizard.nl/same/), a utility to hard
link together identical files.

Perhaps all of these tricks became useless with a decent revision control
system like BitKeeper. But last time I used BitKeeper for the kernel, my
(previous) machine had only 128 MiB of RAM and thus couldn't keep the whole
tree in RAM, causing BitKeeper to be terrrible slow...

keep build files separate from source files

Geert Uytterhoeven wrote:

To keep your source trees clean and uncluttered for easier diffing, build in a separate directory and use the `O=' feature of the 2.6 build system.