By convention, requests which begin with a capital letter do not elicit a response from the server, while all others do -- save one. The exception is `gzip-file-contents'. Unrecognized requests will always elicit a response from the server, even if that request begins with a capital letter.
File contents (noted below as file transmission) can be sent in one of two forms. The simpler form is a number of bytes, followed by a newline, followed by the specified number of bytes of file contents. These are the entire contents of the specified file. Second, if both client and server support `gzip-file-contents', a `z' may precede the length, and the `file contents' sent are actually compressed with `gzip' (RFC1952/1951) compression. The length specified is that of the compressed version of the file.
In neither case are the file content followed by any additional data. The transmission of a file will end with a newline iff that file (or its compressed form) ends with a newline.
Root pathname \n
CVSROOT to use.
Note that pathname is a local directory and not a fully
qualified CVSROOT variable. pathname must
already exist; if creating a new root, use the init request, not
Root. pathname does not include the hostname of the
server, how to access the server, etc.; by the time the CVS protocol is
in use, connection, authentication, etc., are already taken care of.
Valid-responses request-list \n
valid-requests \n
Valid-requests response.
Repository repository \n
Entry and Modified and
also for ci and the other commands; normal usage is to send a
Repository for each directory in which there will be an
Entry or Modified , and then a final Repository
for the original directory, then the command.
Directory local-directory \n
Repository,
but the local name of the directory may differ from the repository name.
If the client uses this request, it affects the way the server returns
pathnames; see section Responses. local-directory is relative to
the top level at which the command is occurring (i.e. the last
Directory or Repository which is sent before the command);
to indicate that top level, `.' should be send for
local-directory.
Max-dotdot level \n
Directory requests are relative to will be
needed. For example, if the client is planning to use a
Directory request for `../../foo', it must send a
Max-dotdot request with a level of at least 2.
Max-dotdot must be sent before the first Directory
request.
Static-directory \n
Repository or Directory should not have
additional files checked out unless explicitly requested. The client
sends this if the Entries.Static flag is set, which is controlled
by the Set-static-directory and Clear-static-directory
responses.
Sticky tagspec \n
Repository has a sticky tag or date tagspec.
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.
Checkin-prog program \n
Directory has a checkin program program.
Such a program would have been previously set with the
Set-checkin-prog response.
Update-prog program \n
Directory has an update program program.
Such a program would have been previously set with the
Set-update-prog response.
Entry entry-line \n
Repository. If the user
is operating on only some files in a directory, Entry requests
for only those files need be included. If an Entry request is
sent without Modified, Unchanged, or Lost for that
file the meaning depends on whether UseUnchanged has been sent;
if it has been it means the file is lost, if not it means the file is
unchanged.
Modified filename \n
Repository. If
the user is operating on only some files in a directory, only those
files need to be included. This can also be sent without Entry,
if there is no entry for the file.
Lost filename \n
Repository. This is used for any case in which Entry is
being sent but the file no longer exists. If the client has issued the
UseUnchanged request, then this request is not used.
Unchanged filename \n
Repository. This request can only be
issued if UseUnchanged has been sent.
UseUnchanged \n
Unchanged, and that files for
which no information is sent are nonexistent on the client side, not
unchanged. This is necessary for correct behavior since only the server
knows what possible files may exist, and thus what files are
nonexistent.
Notify filename \n
edit or unedit command has taken
place. The server needs to send a Notified response, but such
response is deferred until the next time that the server is sending
responses. Response expected: no. Additional data:
notification-type \t time \t clienthost \t working-dir \t watches \nwhere notification-type is `E' for edit or `U' for unedit, time is the time at which the edit or unedit took place, clienthost is the name of the host on which the edit or unedit took place, and working-dir is the pathname of the working directory where the edit or unedit took place. watches are the temporary watches to set; if it is followed by \t then the tab and the rest of the line are ignored.
Questionable filename \n
M response) `?' followed
by the directory and filename. filename must not contain
`/'; it needs to be a file in the directory named by the most
recent Directory request.
Case \n
Entry and
Modified requests for the same file must match in case regardless
of whether the Case request is sent.
Argument text \n
Argumentx text \n
Global_option option \n
valid-requests, it is probably better to
make new global options separate requests, rather than trying to add
them to this request.
Gzip-stream level \n
Kerberos-encrypt \n
Gzip-stream and
the Kerberos-encrypt requests are used, the
Kerberos-encrypt request should be used first. This will make
the client and server encrypt the compressed data, as opposed to
compressing the encrypted data. Encrypted data is generally
incompressible.
Set variable=value \n
expand-modules \n
Module-expansion responses. Note
that the server can assume that this is checkout or export, not rtag or
rdiff; the latter do not access the working directory and thus have no
need to expand modules on the client side.
co \n
ci \n
diff \n
tag \n
status \n
log \n
add \n
remove \n
rdiff \n
rtag \n
admin \n
export \n
history \n
watchers \n
editors \n
annotate \n
Argument, Repository, Entry,
Modified, or Lost requests, if they have been sent. The
last Repository sent specifies the working directory at the time
of the operation. No provision is made for any input from the user.
This means that ci must use a -m argument if it wants to
specify a log message.
init root-name \n
CVSROOT variable. The
Root request need not have been previously sent.
update \n
cvs update command. This
uses any previous Argument, Repository, Entry,
Modified, or Lost requests, if they have been sent. The
last Repository sent specifies the working directory at the time
of the operation. The -I option is not used--files which the
client can decide whether to ignore are not mentioned and the client
sends the Questionable request for others.
import \n
cvs import command. This
uses any previous Argument, Repository, Entry,
Modified, or Lost requests, if they have been sent. The
last Repository sent specifies the working directory at the time
of the operation. The files to be imported are sent in Modified
requests (files which the client knows should be ignored are not sent;
the server must still process the CVSROOT/cvsignore file unless -I ! is
sent). A log message must have been specified with a -m
argument.
watch-on \n
watch-off \n
watch-add \n
watch-remove \n
cvs watch on, cvs
watch off, cvs watch add, and cvs watch remove commands,
respectively. This uses any previous Argument,
Repository, Entry, Modified, or Lost
requests, if they have been sent. The last Repository sent
specifies the working directory at the time of the operation.
release \n
cvs release command has
taken place and update the history file accordingly.
noop \n
Notified responses, etc.
update-patches \n
update
request. The client must issue the -u argument to update
in order to receive patches.
gzip-file-contents level \n
Gzip-stream is suggested
instead of gzip-file-contents as it gives better compression; the
only reason to implement the latter is to provide compression with
CVS 1.8 and earlier. The gzip-file-contents request asks
the server to compress files it sends to the client using gzip
(RFC1952/1951) compression, using the specified level of compression.
If this request is not made, the server must not compress files.
This is only a hint to the server. It may still decide (for example, in
the case of very small files, or files that already appear to be
compressed) not to do the compression. Compression is indicated by a
`z' preceding the file length.
Availability of this request in the server indicates to the client that
it may compress files sent to the server, regardless of whether the
client actually uses this request.
other-request text \n
When the client is done, it drops the connection.
Go to the first, previous, next, last section, table of contents.