6. Notes on the Protocol

A number of enhancements are possible. Also see the file TODO in the CVS source distribution, which has further ideas concerning various aspects of CVS, some of which impact the protocol. Similarly, the http://www.nongnu.org/cvs/ site, in particular the Development pages.

• The Modified request could be speeded up by sending diffs rather than entire files. The client would need some way to keep the version of the file which was originally checked out; probably requiring the use of "cvs edit" in this case is the most sensible course (the "cvs edit" could be handled by a package like VC for emacs). This would also allow local operation of cvs diff without arguments.
• The fact that pserver requires an extra network turnaround in order to perform authentication would be nice to avoid. This relates to the issue of reporting errors; probably the clean solution is to defer the error until the client has issued a request which expects a response. To some extent this might relate to the next item (in terms of how easy it is to skip a whole bunch of requests until we get to one that expects a response). I know that the kerberos code doesn't wait in this fashion, but that probably can cause network deadlocks and perhaps future problems running over a transport which is more transaction oriented than TCP. On the other hand I'm not sure it is wise to make the client conduct a lengthy upload only to find there is an authentication failure.
• The protocol uses an extra network turnaround for protocol negotiation (valid-requests). It might be nice to avoid this by having the client be able to send requests and tell the server to ignore them if they are unrecognized (different requests could produce a fatal error if unrecognized). To do this there should be a standard syntax for requests. For example, perhaps all future requests should be a single line, with mechanisms analogous to Argumentx, or several requests working together, to provide greater amounts of information. Or there might be a standard mechanism for counted data (analogous to that used by Modified) or continuation lines (like a generalized Argumentx). It would be useful to compare what HTTP is planning in this area; last I looked they were contemplating something called Protocol Extension Protocol but I haven't looked at the relevant IETF documents in any detail. Obviously, we want something as simple as possible (but no simpler).
• The scrambling algorithm in the CVS client and server actually support more characters than those documented in Password scrambling algorithm. Someday we are going to either have to document them all (but this is not as easy as it may look, see below), or (gradually and with adequate process) phase out the support for other characters in the CVS implementation. This business of having the feature partly undocumented isn't a desirable state long-term.

  The problem with documenting other characters is that unless we know what character set is in use, there is no way to make a password portable from one system to another. For example, a with a circle on top might have

  [ < ]

  [ > ]

  [ << ]

  [ Up ]

  [ >> ]

  [Top]

  [Contents]

  [Index]

  [ ? ]

  3. How to Connect to and Authenticate Oneself to the CVS server

  Connection and authentication occurs before the CVS protocol itself is started. There are several ways to connect.

  server

  If the client has a way to execute commands on the server, and provide input to the commands and output from them, then it can connect that way. This could be the usual rsh (port 514) protocol, Kerberos rsh, SSH, or any similar mechanism. The client may allow the user to specify the name of the server program; the default is cvs. It is invoked with one argument, s