Difference between revisions of "Diff And Patch Tricks"

From eLinux.org
Jump to: navigation, search
(diff-related tools)
(using hardlink tree copies: remove links to BitKeeper)
 
(One intermediate revision by one other user not shown)
Line 18: Line 18:
 
** Meld - Visual diff and merge tool with very nice graphic interface
 
** Meld - Visual diff and merge tool with very nice graphic interface
 
**** Available at: http://meld.sourceforge.net/
 
**** Available at: http://meld.sourceforge.net/
 +
** Tkdiff - Graphical front end to the diff program
 +
**** Available at: http://sourceforge.net/projects/tkdiff/
  
 
== Tips ==
 
== Tips ==
Line 68: 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 [[BitKeeper]]. But last time I used [[BitKeeper]] for the kernel, my
+
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 [[BitKeeper]] to be terrrible slow...
+
tree in RAM, causing BitKeeper to be terrrible slow...
  
 
=== keep build files separate from source files ===
 
=== keep build files separate from source files ===

Latest revision as of 00:44, 13 May 2009

This page just has some miscellaneous tips and tricks for using diff and patch:

Table Of Contents:

diff-related tools

    • patchutils - A set of tools for manipulating patch files
    • 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
    • Meld - Visual diff and merge tool with very nice graphic interface
    • Tkdiff - Graphical front end to the diff program

Tips

Handling reject (.rej) files

See Handling Patch Rejects

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?

  1. 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.