keywords

The keywords file contains user defined mappings of the standard rcs keywords (see Chapter 13, Keyword substitution).

For each module listed the first line defines the module(s) that the keyword list applies to, then on subsequent lines the keywords are listed, indented by at least one space. The special module name ALL refers to all modules, and is used by default.

ALL
  Maintainer   Joe Bloggs
^Foo$
  Maintainer   Fred Bloggs

In the example above, Joe Bloggs maintains the repository and his brother Fred maintains the Foo module on his own. The rcs tag $Maintainer$ will be expanded differently depending on the location of any source files.

You can also redefine or remove RCS tags, for example when tracking third party sources it may be desirable for the RCS tags from the imported sources to remain intact.

ALL
  Id
  LocalId    %f %v %d %a %s

Listing a keyword with no definition disables its standard usage. In the example above $Id$ will no longer be considered as an RCS keyword, and $LocalId$ has been defined with the pattern previously assigned to $Id$.

When redefining keywords you can use any variable listed in the common syntax, plus the following:

%p

Path relative to repository root

%f

Filename

%a

Author

%d

Date formatted in human readable format

%D

Date formatted in RCS format

%l

File locker (not normally useful in cvsnt)

%s

State (normally one of Exp or Dead)

%v

Version number

%N

RCS $Name$ value

%b

Bug identifier(s) identified with file

%C

Commit/Session identifier

%t

Branch that revision is a member of

The standard RCS keywords are defined as follows:

ALL
  Author     %a
  Date       %d
  Header     %r/%p/%f %v %d %a %s
  CVSHeader  %p/%f %v %d %a %s
  Id         %f %v %d %a %s
  Locker     %l
  Log        %f
  Name       %N
  RCSfile    %f
  Revision   %v
  Source     %r/%p/%f
  State      %s
  CommitId   %C
  Branch     %t

Storing user defined information using keywords

The keywords file is parsed on checkout, which means it isn't useful for storing environment variables or other dynamic data. To store such data user defined variables (see the section called “Expansions in administrative files”) can be used.

For example, using the following keywords file

ALL
  Weather    $WEATHER

the definition of WEATHER be defined during commit as a user defined variable

$ cvs -s WEATHER=Sunny commit -m "Fix stuff" foo.c

This is then associated with that revision for future checkouts.

Compatibility note: Programs which try to read the repository may fail on files with this data stored. If you use such software check that it still works afterwards.