Go to the first, previous, next, last section, table of contents.

## Responses

After a command which expects a response, the server sends however many of the following responses are appropriate. The server should not send data at other times (the current implementation may violate this principle in a few minor places, where the server is printing an error message and exiting--this should be investigated further).

Pathnames are of the actual files operated on (i.e. they do not contain ``,v'` endings), and are suitable for use in a subsequent `Repository` request. However, if the client has used the `Directory` request, then it is instead a local directory name relative to the directory in which the command was given (i.e. the last `Directory` before the command). Then a newline and a repository name (the pathname which is sent if `Directory` is not used). Then the slash and the filename. For example, for a file ``i386.mh'` which is in the local directory ``gas.clean/config'` and for which the repository is ``/rel/cvsfiles/devo/gas/config'`:

    gas.clean/config/
    /rel/cvsfiles/devo/gas/config/i386.mh

Any response always ends with ``error'` or ``ok'`. This indicates that the response is over.

`Valid-requests request-list \n`
  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.
`Checked-in pathname \n`
  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.
`New-entry pathname \n`
  Additional data: New Entries line, \n. Like `Checked-in`, but the file is not up to date.
`Updated pathname \n`
  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.
`Created pathname \n`
  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.
`Update-existing pathname \n`
  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.
`Merged pathname \n`
  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.
`Patched pathname \n`
  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 a patch. This 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. The client must apply this patch 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.
`Mode mode \n`
  This mode applies to the next file mentioned in `Checked-in`. It does not apply to any request which follows a `Checked-in`, `New-entry`, `Updated`, `Merged`, or `Patched` response.
`Checksum checksum\n`
  The checksum applies to the next file sent over via `Updated`, `Merged`, or `Patched`. 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. This response is optional, and is only used if the client supports it (as judged by the `Valid-responses` request).
`Copy-file pathname \n`
  Additional data: newname \n. Copy file pathname to newname in the same directory where it already is. This does not affect `CVS/Entries`.
`Removed pathname \n`
  The file has been removed from the repository (this is the case where cvs prints ``file foobar.c is no longer pertinent'`).
`Remove-entry pathname \n`
  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).
`Set-static-directory pathname \n`
  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.
`Clear-static-directory pathname \n`
  Like `Set-static-directory`, but clear, not set, the flag.
`Set-sticky pathname \n`
  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 first character of tagspec is ``T'` for a tag, or ``D'` for a date. The remainder of tagspec contains the actual tag or date.
`Clear-sticky pathname \n`
  Clear any sticky tag or date set by `Set-sticky`.
`Template pathname \n`
  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.
`Set-checkin-prog dir \n`
  Additional data: prog \n. Tell the client to set a checkin program, which should be supplied with the `Checkin-prog` request for future operations.
`Set-update-prog dir \n`
  Additional data: prog \n. Tell the client to set an update program, which should be supplied with the `Update-prog` request for future operations.
`Notified pathname \n`
  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.
`Module-expansion pathname \n 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).
`M text \n`
  A one-line message for the user.
`E text \n`
  Same as `M` but send to stderr not stdout.
`F \n`
  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).
`error errno-code `` '` text \n`
  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.
`ok \n`
  The command completed successfully.

Go to the first, previous, next, last section, table of contents.