Source Management Tools

Here are some different source management tools commonly used with Linux:

Overview

 * David Wheeler has an excellent breakdown of various SCM tools at: http://www.dwheeler.com/essays/scm.html
 * IBM has an good overview of available tools at: http://www-128.ibm.com/developerworks/linux/library/l-vercon/
 * There is a comparison of several different tools at: http://better-scm.berlios.de/comparison/comparison.html

Patch Management Tools

 * diff - to create patches
 * use 'man diff' on your local system for information
 * patch - to apply patches
 * use 'man patch' on your local system for information
 * Quilt is good for managing a group of patches relative to a single source base.
 * diffstat reads a patch file (or standard input) and displays a histogram of the insertions, deletions, and modifications per-file. It is useful for reviewing large, complex patch files. It reads from one or more input files or from standard input. If an input filename ends with .bz2, .Z or .gz, diffstat will read the uncompressed data via a pipe from the corresponding program.
 * diffstat is included in most Linux distributions
 * diffstat home page
 * diffstat man page
 * Tim's patch management tools - diffinfo and friends - a more verbose diffstat, with splitting, joining and comparing of patches
 * See also Diff And Patch Tricks

GIT
GIT is the source code management tool used by many kernel developers.
 * GIT project home page: http://git.or.cz/
 * GIT for SVN users: http://git.or.cz/course/svn.html
 * Pratical Guide to Using Git, a tutorial given by the excellent kernel developer James Bottomley at the Ottawa Linux Symposium 2008

GIT is distributed: every developer have a copy of the whole project and its history, this doubles as backup as well as makes operations super fast since you don't need to go through network.

GIT is about series of patches that work in a tree form, each tree leaf is a branch. Branches are easy and fast, you can create and delete as much as you wish and you can optionally push them upstream, so it's advised that development happens in your own tree and that you rebase your work on top of upstream 'master', that way you get a consistent sequence of patches to implement features. With GIT you can go back in history and edit commits, delete them, reorder or even merge lots of commits into a single commit for publishing, usually required for projects that employ code review.