Here are the responses:
Valid-requests request-list \n
Checked-in pathname \n
New-entry pathname \n
Checked-in
, but the
file is not up to date.
Updated pathname \n
Created
and
Update-existing
are supported.
Created pathname \n
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
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.
Merged pathname \n
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.
Rcs-diff pathname \n
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.
Patched pathname \n
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 mode \n
Checked-in
. Mode
is a file update modifying response
as described in section Introduction to Responses.
Mod-time time \n
Mod-time
is a file update modifying response
as described in section 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 -0400There 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).
Checksum checksum\n
Checksum
is a file update modifying response
as described in section 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).
Copy-file pathname \n
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.
Removed pathname \n
Remove-entry pathname \n
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
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
Set-static-directory
, but clear, not set, the flag.
Set-sticky pathname \n
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-sticky pathname \n
Set-sticky
.
Template pathname \n
Set-checkin-prog dir \n
Checkin-prog
request
for future operations.
Set-update-prog dir \n
Update-prog
request
for future operations.
Notified pathname \n
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
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).
Wrapper-rcsOption pattern -k 'option' \n
Valid-responses
).
M text \n
Mbinary \n
E text \n
M
but send to stderr not stdout.
F \n
MT tagname data \n
+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-inIf 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 doneFor a list of specific tags, see section Tags for the MT tagged text response.
error errno-code ` ' text \n
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
Go to the first, previous, next, last section, table of contents.