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.