rcs: comma-v particulars
3.1.2 Additional particulars of the file format
-----------------------------------------------
• In releases prior to 5.8 (2011-08-30), the grammar included the
production:
newphrase ::= id word* ";"
and used it in the ‘admin’, ‘delta’ and ‘deltatext’ productions.
This allowed third-party programs to interoperate with RCS by
storing opaque (to RCS) data in the file.
As of 5.8, in the name of progress (towards more systematic file
integrity support), the only area reserved for third-party interop
is in the ‘string’ value of the ‘integrity’ field, specifically
after the first formfeed (U+0C). A further restriction (for all
programs) is that the ‘integrity’ value must not contain ‘@’.
*Warning*: This change means you cannot use ‘rlog’ (or ‘rcs log’)
as a workalike for ‘cvs log’ for versions of CVS that write other
kinds of metadata into the file. If you use CVS and have access to
the ‘*,v’ files it writes, you can determine if they require ‘cvs
log’ by the following command:
if grep -E -q '^(deltatype|permissions|kopt)' *,v
then echo 'must use "cvs log"'
else echo 'probably safe to use "rcs log" (for now)'
fi
The “(for now)” bit is a nod to the most probable trajectory for
both RCS and CVS: away from interop.
• Whitespace has no significance except in ‘string’ values. However,
whitespace cannot appear within an ‘id’, ‘num’, or ‘sym’, and an
RCS file must end with newline (U+0A). A ‘string’ value is
enclosed by ‘@’ (U+40) with internal ‘@’ characters doubled. All
other bytes (arbitrary binary data) represent themselves. For
example:
conceptual string persistent representation
--------------------------------------------------------------------------
a string of five words @a string of five words@
another, with one ’@’ char @another, with one '@@' char@
with newline @with newline
and unquoted @ and unquoted @@@
• Identifiers are case sensitive. Keywords are in lower case only.
The sets of keywords and identifiers can overlap.
• Dates, which appear after the ‘date’ keyword, are of the form
‘Y.m.d.H.M.S’, where ‘Y’ is the year, ‘m’ the month (01–12), ‘d’
the day (01–31), ‘H’ the hour (00–23), ‘M’ the minute (00–59), and
‘S’ the second (00–60). (These correspond to ‘strftime’ format
strings, with the exception of ‘Y’, which depends on the particular
year.)
‘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.
• The ‘delta’ nodes form a tree. All nodes whose numbers consist of
a single pair, e.g.:
2.3
2.1
1.3
are on the trunk, and are linked through the ‘next’ field in order
of decreasing numbers. The ‘head’ field in the ‘admin’ node points
to the head of that sequence (i.e., contains the highest pair).
The ‘branch’ node in the ‘admin’ node indicates the default branch
(or revision) for most RCS operations. If empty, the default
branch is the highest branch on the trunk.
All ‘delta’ nodes whose numbers consist of 2N fields (N ≥ 2), e.g.:
3.1.1.1
2.1.2.2
are linked as follows. All nodes whose first 2N−1 number fields
are identical are linked through the ‘next’ field in order of
increasing numbers. For each such sequence, the ‘delta’ node whose
number is identical to the first 2N−2 number fields of the ‘delta’
nodes on that sequence is called the “branchpoint”.
The ‘branches’ field of a node contains a list of the numbers of
the first nodes of all sequences for which it is a branchpoint.
Head
|
v / \
--------- / \
/ \ / \ | | / \ / \
/ \ / \ | 2.1 | / \ / \
/ \ / \ | | / \ / \
/1.2.1.3\ /1.3.1.1\ | | /1.2.2.2\ /1.2.2.1.1.1\
--------- --------- --------- --------- -------------
^ ^ | ^ ^
| | v | |
/ \ | --------- / \ |
/ \ | \ 1.3 / / \ |
/ \ ---------\ / / \-----------
/1.2.1.1\ 1.3.1 \ / /1.2.2.1\ 1.2.2.1.1
--------- \ / ---------
^ | ^
| v |
| --------- |
| \ 1.2 / |
----------------------\ /---------
1.2.1 \ / 1.2.2
\ /
|
v
---------
\ 1.1 /
\ /
\ /
\ /
Figure 3.1: The organization of an example RCS file.