Difference between revisions of "Diff And Patch Tricks"
m (→using hardlink tree copies) |
(→using hardlink tree copies: remove links to BitKeeper) |
||
(2 intermediate revisions by one other user not shown) | |||
Line 16: | Line 16: | ||
**** This is a program to show difference per-word, instead of per-line | **** This is a program to show difference per-word, instead of per-line | ||
**** Available at: http://directory.fsf.org/GNU/wdiff.html | **** Available at: http://directory.fsf.org/GNU/wdiff.html | ||
+ | ** Meld - Visual diff and merge tool with very nice graphic interface | ||
+ | **** Available at: http://meld.sourceforge.net/ | ||
+ | ** Tkdiff - Graphical front end to the diff program | ||
+ | **** Available at: http://sourceforge.net/projects/tkdiff/ | ||
== Tips == | == Tips == | ||
Line 66: | Line 70: | ||
Perhaps all of these tricks became useless with a decent revision control | Perhaps all of these tricks became useless with a decent revision control | ||
− | system like | + | 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 | (previous) machine had only 128 MiB of RAM and thus couldn't keep the whole | ||
− | tree in RAM, causing | + | tree in RAM, causing BitKeeper to be terrrible slow... |
=== keep build files separate from source files === | === keep build files separate from source files === |
Revision as of 17:44, 12 May 2009
This page just has some miscellaneous tips and tricks for using diff and patch:
Table Of Contents:
Contents
- patchutils - A set of tools for manipulating patch files
- (These are included in Red Hat Linux)
- Available at: http://cyberelk.net/tim/patchutils/
- diffinfo - Tim Bird's tool for managing diff files.
- Diffinfo can filter and split diffs using file patterns and regular expression matches.
- Available here: Media:diffinfo
- qdiff - quick diff.
- This is a front-end for diff which ignores files with the same size and modification time. This speeds up diffs of large source tree (like the Linux kernel)
- Available here: Media:qdiff
- wdiff - word diff
- This is a program to show difference per-word, instead of per-line
- Available at: http://directory.fsf.org/GNU/wdiff.html
- Meld - Visual diff and merge tool with very nice graphic interface
- Available at: http://meld.sourceforge.net/
- Tkdiff - Graphical front end to the diff program
- Available at: http://sourceforge.net/projects/tkdiff/
- patchutils - A set of tools for manipulating patch files
Tips
Handling reject (.rej) files
using read-only .orig directories
Tim Bird's tips:
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.