1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
It would be nice for the RCS file format (which is implemented by a
great many tools, both free and non-free, both by calling GNU RCS and
by reimplementing access to RCS files) were documented in some
standard separate from any one tool. But as far as I know no such
standard exists. Hence this file.
The place to start is the rcsfile.5 manpage in the GNU RCS 5.7
distribution. Then look at the diff at the end of this file (which
contains a few fixes and clarifications to that manpage).
If you are interested in MKS RCS, src/ci.c in GNU RCS 5.7 has a
comment about their date format. However, as far as we know there
isn't really any document describing MKS's changes to the RCS file
format.
The rcsfile.5 manpage does not document what goes in the "text" field
for each revision. The answer is that the head revision contains the
contents of that revision and every other revision contain a bunch of
edits to produce that revision ("a" and "d" lines). The GNU diff
manual (the version I looked at was for GNU diff 2.4) documents this
format somewhat (as the "RCS output format"), but the presentation is
a bit confusing as it is all tangled up with the documentation of
several other output formats. If you just want some source code to
look at, the part of CVS which applies these is RCS_deltas in
src/rcs.c.
The first time I read rcsfile.5 I didn't really notice the part about
the order of the revisions. This order _is_ important and CVS relies
on it. It is documented but it would be clearer if the example in
rcsfile.5 also showed the order of the revisions (and the "next" and
"branch" fields and anything else where it would be useful to have an
example of how a revision tree is represented in an RCS file).
There is one case where CVS uses CVS-specific, non-compatible changes
to the RCS file format, and this is magic branches. See cvs.texinfo
for more information on them. CVS also sets the RCS state to "dead"
to indicate that a file does not exist in a given revision (this is
stored just as any other RCS state is).
Diff follows:
(Note that in the following diff the old value for the Id keyword was:
Id: rcsfile.5in,v 5.6 1995/06/05 08:28:35 eggert Exp
and the new one was:
Id: rcsfile.5in,v 5.7 1996/12/09 17:31:44 eggert Exp
but since this file itself might be subject to keyword expansion I
haven't included a diff for that fact).
===================================================================
RCS file: RCS/rcsfile.5in,v
retrieving revision 5.6
retrieving revision 5.7
diff -u -r5.6 -r5.7
--- rcsfile.5in 1995/06/05 08:28:35 5.6
+++ rcsfile.5in 1996/12/09 17:31:44 5.7
@@ -85,7 +85,8 @@
.LP
\f2sym\fP ::= {\f2digit\fP}* \f2idchar\fP {\f2idchar\fP | \f2digit\fP}*
.LP
-\f2idchar\fP ::= any visible graphic character except \f2special\fP
+\f2idchar\fP ::= any visible graphic character,
+ except \f2digit\fP or \f2special\fP
.LP
\f2special\fP ::= \f3$\fP | \f3,\fP | \f3.\fP | \f3:\fP | \f3;\fP | \f3@\fP
.LP
@@ -119,12 +120,23 @@
the minute (00\-59),
and
.I ss
-the second (00\-60).
+the second (00\-59).
+If
.I Y
-contains just the last two digits of the year
-for years from 1900 through 1999,
-and all the digits of years thereafter.
-Dates use the Gregorian calendar; times use UTC.
+contains exactly two digits,
+they are the last two digits of a year from 1900 through 1999;
+otherwise,
+.I Y
+contains all the digits of the year.
+Dates use the Gregorian calendar.
+Times use UTC, except that for portability's sake leap seconds are not allowed;
+implementations that support leap seconds should output
+.B 59
+for
+.I ss
+during an inserted leap second, and should accept
+.B 59
+for a deleted leap second.
.PP
The
.I newphrase
@@ -144,16 +156,23 @@
field in order of decreasing numbers.
The
.B head
-field in the
-.I admin
-node points to the head of that sequence (i.e., contains
+field points to the head of that sequence (i.e., contains
the highest pair).
The
.B branch
-node in the admin node indicates the default
+field indicates the default
branch (or revision) for most \*r operations.
If empty, the default
branch is the highest branch on the trunk.
+The
+.B symbols
+field associates symbolic names with revisions.
+For example, if the file contains
+.B "symbols rr:1.1;"
+then
+.B rr
+is a name for revision
+.BR 1.1 .
.PP
All
.I delta
|
