(cvsclient.info.gz) Goals
Info Catalog
(cvsclient.info.gz) Introduction
(cvsclient.info.gz) Top
(cvsclient.info.gz) Connection and Authentication
2 Goals
*******
* Do not assume any access to the repository other than via this
protocol. It does not depend on NFS, rdist, etc.
* Providing a reliable transport is outside this protocol. The
protocol expects a reliable transport that is transparent (that
is, there is no translation of characters, including characters
such as such as linefeeds or carriage returns), and can transmit
all 256 octets (for example for proper handling of binary files,
compression, and encryption). The encoding of characters
specified by the protocol (the names of requests and so on) is the
invariant ISO 646 character set (a subset of most popular
character sets including ASCII and others). For more details on
running the protocol over the TCP reliable transport, see
Connection and Authentication.
* Security and authentication are handled outside this protocol (but
see below about `cvs kserver' and `cvs pserver').
* The protocol makes it possible for updates to be atomic with
respect to checkins; that is if someone commits changes to several
files in one cvs command, then an update by someone else would
either get all the changes, or none of them. The current CVS
server can't do this, but that isn't the protocol's fault.
* The protocol is, with a few exceptions, transaction-based. That
is, the client sends all its requests (without waiting for server
responses), and then waits for the server to send back all
responses (without waiting for further client requests). This has
the advantage of minimizing network turnarounds and the
disadvantage of sometimes transferring more data than would be
necessary if there were a richer interaction. Another, more
subtle, advantage is that there is no need for the protocol to
provide locking for features such as making checkins atomic with
respect to updates. Any such locking can be handled entirely by
the server. A good server implementation (such as the current CVS
server) will make sure that it does not have any such locks in
place whenever it is waiting for communication with the client;
this prevents one client on a slow or flaky network from
interfering with the work of others.
* It is a general design goal to provide only one way to do a given
operation (where possible). For example, implementations have no
choice about whether to terminate lines with linefeeds or some
other character(s), and request and response names are
case-sensitive. This is to enhance interoperability. If a
protocol allows more than one way to do something, it is all too
easy for some implementations to support only some of them
(perhaps accidentally).
Info Catalog
(cvsclient.info.gz) Introduction
(cvsclient.info.gz) Top
(cvsclient.info.gz) Connection and Authentication
automatically generated byinfo2html