Indicate what requests the server will accept. request-list is a space separated list of tokens. If the server supports sending patches, it will include update-patches in this list. The update-patches request does not actually do anything.

Additional data: New Entries line, \n. This means a file pathname has been successfully operated on (checked in, added, etc.). name in the Entries line is the same as the last component of pathname.

Additional data: New Entries line, \n. Like Checked-in, but the file is not up to date.

Additional data: New Entries line, \n, mode, \n, file transmission. A new copy of the file is enclosed. This is used for a new revision of an existing file, or for a new file, or for any other case in which the local (client-side) copy of the file needs to be updated, and after being updated it will be up to date. If any directory in pathname does not exist, create it. This response is not used if Created and Update-existing are supported.

This is just like Updated and takes the same additional data, but is used only if no Entry, Modified, or Unchanged request has been sent for the file in question. The distinction between Created and Update-existing is so that the client can give an error message in several cases: (1) there is a file in the working directory, but not one for which Entry, Modified, or Unchanged was sent (for example, a file which was ignored, or a file for which Questionable was sent), (2) there is a file in the working directory whose name differs from the one mentioned in Created in ways that the client is unable to use to distinguish files. For example, the client is case-insensitive and the names differ only in case.

This is just like Updated and takes the same additional data, but is used only if a Entry, Modified, or Unchanged request has been sent for the file in question.

This response, or Merged, indicates that the server has determined that it is OK to overwrite the previous contents of the file specified by pathname. Provided that the client has correctly sent Modified or Is-modified requests for a modified file, and the file was not modified while CVS was running, the server can ensure that a user's modifications are not lost.

This is just like Updated and takes the same additional data, with the one difference that after the new copy of the file is enclosed, it will still not be up to date. Used for the results of a merge, with or without conflicts.

It is useful to preserve an copy of what the file looked like before the merge. This is basically handled by the server; before sending Merged it will send a Copy-file response. For example, if the file is aa and it derives from revision 1.3, the Copy-file response will tell the client to copy aa to .#aa.1.3. It is up to the client to decide how long to keep this file around; traditionally clients have left it around forever, thus letting the user clean it up as desired. But another answer, such as until the next commit, might be preferable.

This is just like Updated and takes the same additional data, with the one difference that instead of sending a new copy of the file, the server sends an RCS change text. This change text is produced by diff -n (the GNU diff -a option may also be used). The client must apply this change text to the existing file. This will only be used when the client has an exact copy of an earlier revision of a file. This response is only used if the update command is given the -u argument.

This is just like Rcs-diff and takes the same additional data, except that it sends a standard patch rather than an RCS change text. The patch is produced by diff -c for cvs 1.6 and later (see POSIX.2 for a description of this format), or diff -u for previous versions of cvs; clients are encouraged to accept either format. Like Rcs-diff, this response is only used if the update command is given the -u argument.

The Patched response is deprecated in favor of the Rcs-diff response. However, older clients (CVS 1.9 and earlier) only support Patched.

This mode applies to the next file mentioned in Checked-in. Mode is a file update modifying response as described in the section called “Introduction to Responses ”.

Set the modification time of the next file sent to time. Mod-time is a file update modifying response as described in the section called “Introduction to Responses ”. The time is in the format specified by RFC822 as modified by RFC1123. The server may specify any timezone it chooses; clients will want to convert that to their own timezone as appropriate. An example of this format is:

26 May 1997 13:01:40 -0400

There is no requirement that the client and server clocks be synchronized. The server just sends its recommendation for a timestamp (based on its own clock, presumably), and the client should just believe it (this means that the time might be in the future, for example).

If the server does not send Mod-time for a given file, the client should pick a modification time in the usual way (usually, just let the operating system set the modification time to the time that the CVS command is running).

The checksum applies to the next file sent (that is, Checksum is a file update modifying response as described in the section called “Introduction to Responses ”). In the case of Patched, the checksum applies to the file after being patched, not to the patch itself. The client should compute the checksum itself, after receiving the file or patch, and signal an error if the checksums do not match. The checksum is the 128 bit MD5 checksum represented as 32 hex digits (MD5 is described in RFC1321). This response is optional, and is only used if the client supports it (as judged by the Valid-responses request).

Additional data: newname \n. Copy file pathname to newname in the same directory where it already is. This does not affect CVS/Entries.

This can optionally be implemented as a rename instead of a copy. The only use for it which currently has been identified is prior to a Merged response as described under Merged. Clients can probably assume that is how it is being used, if they want to worry about things like how long to keep the newname file around.

The file has been removed from the repository (this is the case where cvs prints file foobar.c is no longer pertinent).

The file needs its entry removed from CVS/Entries, but the file itself is already gone (this happens in response to a ci request which involves committing the removal of a file).

This instructs the client to set the Entries.Static flag, which it should then send back to the server in a Static-directory request whenever the directory is operated on. pathname ends in a slash; its purpose is to specify a directory, not a file within a directory.

Like Set-static-directory, but clear, not set, the flag.

Additional data: tagspec \n. Tell the client to set a sticky tag or date, which should be supplied with the Sticky request for future operations. pathname ends in a slash; its purpose is to specify a directory, not a file within a directory. The client should store tagspec and pass it back to the server as-is, to allow for future expansion. The first character of tagspec is T for a tag, D for a date, or something else for future expansion. The remainder of tagspec contains the actual tag or date.

Clear any sticky tag or date set by Set-sticky.

Additional data: file transmission (note: compressed file transmissions are not supported). pathname ends in a slash; its purpose is to specify a directory, not a file within a directory. Tell the client to store the file transmission as the template log message, and then use that template in the future when prompting the user for a log message.

Indicate to the client that the notification for pathname has been done. There should be one such response for every Notify request; if there are several Notify requests for a single file, the requests should be processed in order; the first Notified response pertains to the first Notify request, etc.

Return a file or directory which is included in a particular module. pathname is relative to cvsroot, unlike most pathnames in responses. pathname should be used to look and see whether some or all of the module exists on the client side; it is not necessarily suitable for passing as an argument to a co request (for example, if the modules file contains the -d option, it will be the directory specified with -d, not the name of the module).

Transmit to the client a filename pattern which implies a certain keyword expansion mode. The pattern is a wildcard pattern (for example, *.exe. The option is b for binary, and so on. Note that although the syntax happens to resemble the syntax in certain CVS configuration files, it is more constrained; there must be exactly one space between pattern and -k and exactly one space between -k and ', and no string is permitted in place of -k (extensions should be done with new responses, not by extending this one, for graceful handling of Valid-responses).

A one-line message for the user. Note that the format of text is not designed for machine parsing. Although sometimes scripts and clients will have little choice, the exact text which is output is subject to vary at the discretion of the server and the example output given in this document is just that, example output. Servers are encouraged to use the MT response, and future versions of this document will hopefully standardize more of the MT tags; see the section called “Tags for the MT tagged text response ”.

Additional data: file transmission (note: compressed file transmissions are not supported). This is like M, except the contents of the file transmission are binary and should be copied to standard output without translation to local text file conventions. To transmit a text file to standard output, servers should use a series of M requests.

Same as M but send to stderr not stdout.

Flush stderr. That is, make it possible for the user to see what has been written to stderr (it is up to the implementation to decide exactly how far it should go to ensure this).

This response provides for tagged text. It is similar to SGML/HTML/XML in that the data is structured and a naive application can also make some sense of it without understanding the structure. The syntax is not SGML-like, however, in order to fit into the CVS protocol better and (more importantly) to make it easier to parse, especially in a language like perl or awk.

The tagname can have several forms. If it starts with a to z or A to Z, then it represents tagged text. If the implementation recognizes tagname, then it may interpret data in some particular fashion. If the implementation does not recognize tagname, then it should simply treat data as text to be sent to the user (similar to an M response). There are two tags which are general purpose. The text tag is similar to an unrecognized tag in that it provides text which will ordinarily be sent to the user. The newline tag is used without data and indicates that a newline will ordinarily be sent to the user (there is no provision for embedding newlines in the data of other tagged text responses).

If tagname starts with + it indicates a start tag and if it starts with - it indicates an end tag. The remainder of tagname should be the same for matching start and end tags, and tags should be nested (for example one could have tags in the following order +bold +italic text -italic -bold but not +bold +italic text -bold -italic). A particular start and end tag may be documented to constrain the tagged text responses which are valid between them.

Note that if data is present there will always be exactly one space between tagname and data; if there is more than one space, then the spaces beyond the first are part of data.

Here is an example of some tagged text responses. Note that there is a trailing space after Checking in and initial revision: and there are two trailing spaces after <-. Such trailing spaces are, of course, part of data.

MT +checking-in
MT text Checking in
MT fname gz.tst
MT text ;
MT newline
MT rcsfile /home/kingdon/zwork/cvsroot/foo/gz.tst,v
MT text   <--
MT fname gz.tst
MT newline
MT text initial revision:
MT init-rev 1.1
MT newline
MT text done
MT newline
MT -checking-in

If the client does not support the MT response, the same responses might be sent as:

M Checking in gz.tst;
M /home/kingdon/zwork/cvsroot/foo/gz.tst,v  <--  gz.tst
M initial revision: 1.1
M done

For a list of specific tags, see the section called “Tags for the MT tagged text response ”.

The command completed with an error. errno-code is a symbolic error code (e.g. ENOENT); if the server doesn't support this feature, or if it's not appropriate for this particular message, it just omits the errno-code (in that case there are two spaces after error). Text is an error message such as that provided by strerror(), or any other message the server wants to use. The text is like the M response, in the sense that it is not particularly intended to be machine-parsed; servers may wish to print an error message with MT responses, and then issue a error response without text (although it should be noted that MT currently has no way of flagging the output as intended for standard error, the way that the E response does).

The command completed successfully.