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.
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
|
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.
|
Rcs-diff 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 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
|
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 .
|
Mode mode \n
|
This mode applies to the next file mentioned in
Checked-in . Mode is a file update modifying response
as described in Response intro.
|
Mod-time time \n
|
Set the modification time of the next file sent to time.
Mod-time is a file update modifying response
as described in Response intro.
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).
|
Checksum checksum\n
|
The checksum applies to the next file sent (that is,
Checksum is a file update modifying response
as described in Response intro).
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
|
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.
|
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 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
|
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).
|
Wrapper-rcsOption pattern -k 'option' \n
|
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 ).
|
M text \n
|
A one-line message for the user.
|
Mbinary \n
|
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.
|
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).
|
MT tagname data \n
|
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 Text tags.
|
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.
|