Examining Changes
At this point, you might well be curious what changes the other developer made to httpc.c. To look at the log entries for a given file, you can use the cvs log command:
$ cvs log httpc.c RCS file: /u/src/master/httpc/httpc.c,v Working file: httpc.c head: 1.8 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 8; selected revisions: 8 description: The one and only source file for the trivial HTTP client ---------------------------- revision 1.8 date: 1996/10/31 20:11:14; author: jimb; state: Exp; lines: +1 -1 (tcp_connection): Cast address structure when calling connect. ---------------------------- revision 1.7 date: 1996/10/31 19:18:45; author: fred; state: Exp; lines: +6 -2 (match_header): Make this test case-insensitive. ---------------------------- revision 1.6 date: 1996/10/31 19:15:23; author: jimb; state: Exp; lines: +2 -6 ... $
Most of the text here you can ignore; the portion to look at carefully is the series of log entries after the first line of hyphens. The log entries appear in reverse chronological order, under the assumption that more recent changes are usually more interesting. Each entry describes one change to the file, and may be parsed as follows:
revision 1.8
Each version of a file has a unique revision number. Revision numbers look like 1.1, 1.2, 1.3.2.2, or even 1.3.2.2.4.5. By default, revision 1.1 is the first revision of a file. Each successive revision is given a new number by increasing the rightmost number by one.
date: 1996/10/31 20:11:14; author: jimb; ...
This line gives the date of the change, and the username of the person who committed it; the remainder of the line is not very interesting.
(tcp_connection): Cast ...
This (pretty obviously) is the log entry describing that change.
The cvs log command can select log entries by date range, or by revision number; see the manual for details on this. If you would actually like to see the change in question, you can use the cvs diff command. For example, if you would like to see the changes Fred committed as revision 1.7, you can use the following command:
$ cvs diff -c -r 1.6 -r 1.7 httpc.c
Before we look at the output from this command, let's look at what the various parts mean:
-c
This requests that cvs diff use a more human-readable format for its output. (I'm not sure why it isn't the default.)
-r 1.6 -r 1.7
This tells CVS to display the changes needed to turn revision 1.6 of httpc.c into revision 1.7. You can request a wider range of revisions if you like; for example, -r 1.6 -r 1.8 would display both Fred's changes and your most recent change. (You can even request that changes be displayed backward — as if they were being undone — by specifying the revisions backward: -r 1.7 -r 1.6. This sounds odd, but it is useful sometimes.)
httpc.c
This is the name of the file to inspect. If you don't give it specific files to report on, CVS will produce a report for the entire directory.
Here is the output from the command Index: httpc.c
RCS file: /u/src/master/httpc/httpc.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -c -r1.6 -r1.7
*** httpc.c 1996/10/31 19:15:23 1.6
--- httpc.c 1996/10/31 19:18:45 1.7
***************
*** 62,68 ****
}
! /* Return non-zero iff HEADER is a prefix of TEXT. HEADER should be
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
--- 62,69 ----
}
! /* Return non-zero iff HEADER is a prefix of TEXT, ignoring
! differences in case. HEADER should be lower-case, and
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
***************
*** 76,81 ****
--- 77,84 ----
for (i = 0; i < header_len; i++)
{
char t = text[i];
+ if ('A' <= t && t <= 'Z')
+ t += 'a' - 'A';
if (header[i] != t)
return 0;
}
$
This output takes a bit of effort to get used to, but it is definitely worth understanding.
The interesting portion starts with the first two lines beginning with *** and ---; those describe the older and newer files compared. The remainder consists of two hunks, each of which starts with a line of asterisks. Here is the first hunk:
***************
*** 62,68 ****
}
! /* Return non-zero iff HEADER is a prefix of TEXT. HEADER should be
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
--- 62,69 ----
}
! /* Return non-zero iff HEADER is a prefix of TEXT, ignoring
! differences in case. HEADER should be lower-case, and
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
Text from the older version appears after the *** 62,68 *** line; text from the new appears after the --- 62,69 --- line. The pair of numbers in each indicates the range of lines shown. CVS provides context around the change, and marks the actual lines affected with ! characters. Thus, one can see that the single line in the top half was replaced with the two lines in the bottom half.
Here is the second hunk:
***************
*** 76,81 ****
--- 77,84 ----
for (i = 0; i < header_len; i++)
{
char t = text[i];
+ if ('A' <= t && t <= 'Z')
+ t += 'a' - 'A';
if (header[i] != t)
return 0;
}
This hunk describes the insertion of two lines, marked with + characters. CVS omits the old text in this case, because it would be redundant. CVS uses a similar hunk format to describe deletions.
Like the Unix diff command, output from cvs diff is usually called a patch, because developers have traditionally used the format to distribute bug fixes or small new features. While reasonably readable to humans, a patch contains enough information for a program to apply the changes it describes to an unmodified text file. In fact, the Unix patch command does exactly this, given a patch as input.