diff mercurial/help/internals/wireprotocolv2.txt @ 39630:9c2c77c73f23

wireprotov2: define and implement "changesetdata" command

This commit introduces the "changesetdata" wire protocol command.
The role of the command is to expose data associated with changelog
revisions, including the raw revision data itself.

This command is the first piece of a new clone/pull strategy that
is built on top of domain-specific commands for data retrieval.
Instead of a monolithic "getbundle" command that transfers all of the
things, we'll be introducing commands for fetching specific pieces
of data.

Since the changeset is the fundamental unit from which we derive
pointers to other data (manifests, file nodes, etc), it makes sense
to start reimplementing pull with this data.

The command accepts as arguments a set of root and head revisions
defining the changesets that should be fetched as well as an explicit
list of nodes. By default, the command returns only the node values:
the client must explicitly request additional fields be added to the
response. Current supported fields are the list of parent nodes and
the revision fulltext.

My plan is to eventually add support for transferring other data
associated with changesets, including phases, bookmarks, obsolescence
markers, etc. Since the response format is CBOR, we'll be able to add
this data into the response object relatively easily (it should be
as simple as adding a key in a map).

The documentation captures a number of TODO items. Some of these may
require BC breaking changes. That's fine: wire protocol v2 is still
highly experimental.

Differential Revision: https://phab.mercurial-scm.org/D4481

--- a/mercurial/help/internals/wireprotocolv2.txt	Wed Sep 12 09:58:23 2018 -0700
+++ b/mercurial/help/internals/wireprotocolv2.txt	Wed Sep 12 10:01:16 2018 -0700
@@ -87,6 +87,90 @@
    requirements can be used to determine whether a client can read a
    *raw* copy of file data available.
 
+changesetdata
+-------------
+
+Obtain various data related to changesets.
+
+The command accepts the following arguments:
+
+noderange
+   (array of arrays of bytestrings) An array of 2 elements, each being an
+   array of node bytestrings. The first array denotes the changelog revisions
+   that are already known to the client. The second array denotes the changelog
+   revision DAG heads to fetch. The argument essentially defines a DAG range
+   bounded by root and head nodes to fetch.
+
+   The roots array may be empty. The heads array must be defined.
+
+nodes
+   (array of bytestrings) Changelog revisions to request explicitly.
+
+fields
+   (set of bytestring) Which data associated with changelog revisions to
+   fetch. The following values are recognized:
+
+   parents
+      Parent revisions.
+
+   revision
+      The raw, revision data for the changelog entry. The hash of this data
+      will match the revision's node value.
+
+The server resolves the set of revisions relevant to the request by taking
+the union of the ``noderange`` and ``nodes`` arguments. At least one of these
+arguments must be defined.
+
+The response bytestream starts with a CBOR map describing the data that follows.
+This map has the following bytestring keys:
+
+totalitems
+   (unsigned integer) Total number of changelog revisions whose data is being
+   transferred.
+
+Following the map header is a series of 0 or more CBOR values. If values
+are present, the first value will always be a map describing a single changeset
+revision. If revision data is requested, the raw revision data (encoded as
+a CBOR bytestring) will follow the map describing it. Otherwise, another CBOR
+map describing the next changeset revision will occur.
+
+Each map has the following bytestring keys:
+
+node
+   (bytestring) The node value for this revision. This is the SHA-1 hash of
+   the raw revision data.
+
+parents (optional)
+   (array of bytestrings) The nodes representing the parent revisions of this
+   revision. Only present if ``parents`` data is being requested.
+
+revisionsize (optional)
+   (unsigned integer) Indicates the size of raw revision data that follows this
+   map. The following data contains a serialized form of the changeset data,
+   including the author, date, commit message, set of changed files, manifest
+   node, and other metadata.
+
+   Only present if ``revision`` data was requested and the data follows this
+   map.
+
+If nodes are requested via ``noderange``, they will be emitted in DAG order,
+parents always before children.
+
+If nodes are requested via ``nodes``, they will be emitted in requested order.
+
+Nodes from ``nodes`` are emitted before nodes from ``noderange``.
+
+TODO support different revision selection mechanisms (e.g. non-public, specific
+revisions)
+TODO support different hash "namespaces" for revisions (e.g. sha-1 versus other)
+TODO support emitting phases data
+TODO support emitting bookmarks data
+TODO support emitting obsolescence data
+TODO support filtering based on relevant paths (narrow clone)
+TODO support depth limiting
+TODO support hgtagsfnodes cache / tags data
+TODO support branch heads cache
+
 heads
 -----