Here are the responses:
request-list
\nIndicate 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.
pathname
\nAdditional 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
.
pathname
\nAdditional data: New Entries line, \n. Like Checked-in, but the file is not up to date.
pathname
\nAdditional 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.
pathname
\nThis 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.
pathname
\nThis 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.
pathname
\nThis 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.
pathname
\nThis 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.
pathname
\nThis 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.
mode
\nThis 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”.
time
\nSet 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).
checksum
\nThe 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).
pathname
\nAdditional 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.
pathname
\nThe file has been removed from the repository (this is the case where cvs prints file foobar.c is no longer pertinent).
pathname
\nThe 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).
pathname
\nThis 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.
pathname
\nLike Set-static-directory, but clear, not set, the flag.
pathname
\nAdditional 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.
pathname
\nClear any sticky tag or date set by Set-sticky.
pathname
\nAdditional 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.
pathname
\nIndicate 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.
pathname
\nReturn 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).
pattern
-k
'option
' \nTransmit 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).
text
\nA 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.
text
\nSame 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).
tagname
data
\nThis 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”.
errno-code
text
\nThe 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.