CVS---Concurrent Versions System. Node: Wrappers

PREVmodules UPAdministrative files NEXTcommit files

C.2: The cvswrappers file

Wrappers allow you to set a hook which transforms files on their way in and out of CVS.

The file `cvswrappers' defines the script that will be run on a file when its name matches a regular expresion. There are two scripts that can be run on a file or directory. One script is executed on the file/directory before being checked into the repository (this is denoted with the -t flag) and the other when the file is checked out of the repository (this is denoted with the -f flag). The `-t'/`-f' feature does not work with client/server CVS.

The `cvswrappers' also has a `-m' option to specify the merge methodology that should be used when a non-binary file is updated. MERGE means the usual CVS behavior: try to merge the files. COPY means that cvs update will refuse to merge files, as it also does for files specified as binary with `-kb' (but if the file is specified as binary, there is no need to specify `-m 'COPY''). CVS will provide the user with the two versions of the files, and require the user using mechanisms outside CVS, to insert any necessary changes. WARNING: do not use COPY with CVS 1.9 or earlier--such versions of CVS will copy one version of your file over the other, wiping out the previous contents. The `-m' wrapper option only affects behavior when merging is done on update; it does not affect how files are stored. See Binary files, for more on binary files.

The basic format of the file `cvswrappers' is:

wildcard     [option value][option value]...

where option is one of
-f           from cvs filter         value: path to filter
-t           to cvs filter           value: path to filter
-m           update methodology      value: MERGE or COPY
-k           keyword expansion       value: expansion mode

and value is a single-quote delimited value.
*.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
*.c      -t 'indent %s %s'

The above example of a `cvswrappers' file states that all files/directories that end with a .nib should be filtered with the `wrap' program before checking the file into the repository. The file should be filtered though the `unwrap' program when the file is checked out of the repository. The `cvswrappers' file also states that a COPY methodology should be used when updating the files in the repository (that is, no merging should be performed).

The last example line says that all files that end with .c should be filtered with `indent' before being checked into the repository. Unlike the previous example, no filtering of the .c file is done when it is checked out of the repository. The -t filter is called with two arguments, the first is the name of the file/directory to filter and the second is the pathname to where the resulting filtered file should be placed.

The -f filter is called with one argument, which is the name of the file to filter from. The end result of this filter will be a file in the users directory that they can work on as they normally would.

Note that the `-t'/`-f' features do not conveniently handle one portion of CVS's operation: determining when files are modified. CVS will still want a file (or directory) to exist, and it will use its modification time to determine whether a file is modified. If CVS erroneously thinks a file is unmodified (for example, a directory is unchanged but one of the files within it is changed), you can force it to check in the file anyway by specifying the `-f' option to cvs commit (see commit options).

For another example, the following command imports a directory, treating files whose name ends in `.exe' as binary:

cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
PREVmodules UPAdministrative files NEXTcommit files