Table of Contents
In the following, \n refers to a linefeed and \t refers to a horizontal tab; requests are what the client sends and responses are what the server sends. In general, the connection is governed by the client--the server does not send responses without first receiving requests to do so; see the section called “Introduction to Responses ” for more details of this convention.
It is typical, early in the connection, for the client to transmit a Valid-responses request, containing all the responses it supports, followed by a valid-requests request, which elicits from the server a Valid-requests response containing all the requests it understands. In this way, the client and server each find out what the other supports before exchanging large amounts of data (such as file contents).
Entries lines are transmitted as:
/ name / version / conflict or timestamp / options / tag_or_date
tag_or_date is either T tag or D date or empty. If it is followed by a slash, anything after the slash shall be silently ignored.
version can be empty, or start with 0 or -, for no user file, new user file, or user file to be removed, respectively.
conflict, if it starts with +, indicates that the file had conflicts in it. The rest of conflict is = if the timestamp matches the file, or anything else if it doesn't. If conflict does not start with a +, it is silently ignored.
options signifies the keyword expansion options (for example -ko). In an Entry request, this indicates the options that were specified with the file from the previous file updating response (the section called “Introduction to Responses ”, for a list of file updating responses); if the client is specifying the -k or -A option to update, then it is the server which figures out what overrides what. The client can optionally also send the timestamp if there is no conflict, and this is used (along with the value from Checkin-time) for timestamp comparison on the server.