Synopsis: rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
Requires: repository.
Changes: nothing.
Synonyms: patch, pa
Builds a Larry Wall format patch(1) file between two releases, that can be fed directly into the patch program to bring an old release up-to-date with the new release. (This is one of the few cvsnt commands that operates directly from the repository, and doesn't require a prior checkout.) The diff output is sent to the standard output device.
You can specify (using the standard -r and -D options) any combination of one or two revisions or dates. If only one revision or date is specified, the patch file reflects differences between that revision or date and the current head revisions in the rcs file.
Note that if the software release affected is contained in more than one directory, then it may be necessary to specify the -p option to the patch command when patching the old sources, so that patch is able to find the files that are located in other directories.
These standard options are supported by rdiff (the section called “Common command options”, for a complete description of them):
dateUse the most recent revision no later than
date.
If no matching revision is found, retrieve the most recent revision (instead of ignoring the file).
Local; don't descend subdirectories.
Examine directories recursively. This option is on by default.
tagUse revision tag.
In addition to the above, these options are available:
Use the context diff format. This is the default format.
Create a summary change report instead of a patch. The summary includes information about files that were changed or added between the releases. It is sent to the standard output device. This is useful for finding out, for example, which files have changed between two dates or revisions.
A diff of the top two revisions is sent to the standard output device. This is most useful for seeing what the last change to a file was.
Use the unidiff format for the context diffs. Remember that old versions of the patch program can't handle the unidiff format, so if you plan to post this patch to the net you should probably not use -u.
vnExpand keywords according to the rules current in rcs
version vn (the expansion format changed with
rcs version 5). Note that this option is no longer accepted.
cvsnt will always expand keywords the way that rcs version 5
does.
Suppose you receive mail from foo@example.net asking for an update from release 1.2 to 1.4 of the tc compiler. You have no such patches on hand, but with cvsnt that can easily be fixed with a command such as this:
$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ $$ Mail -s 'The patches you asked for' foo@example.net
Suppose you have made release 1.3, and forked a branch called R_1_3fix for bugfixes. R_1_3_1 corresponds to release 1.3.1, which was made some time ago. Now, you want to see how much development has been done on the branch. This command can be used:
$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name cvs rdiff: Diffing module-name File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6 File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4 File bar.h,v changed from revision 1.29.2.1 to 1.2