Mercurial > public > mercurial-scm > hg-stable

diff mercurial/help/internals/wireprotocolv2.txt @ 39655:0e03e6a44dee

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
wireprotov2: define and implement "filedata" command Continuing our trend of implementing *data commands for retrieving information about specific repository data primitives, this commit implements a command for retrieving data about an individual tracked file. The command is very similar to "manifestdata." The only significant difference is that we have a standalone function for obtaining storage for a tracked file. This is to provide a monkeypatch point for extensions to implement path-based access control. With this API available, wire protocol version 2 now exposes all data primitives necessary to implement a full clone. Of course, since "filedata" can only resolve data for a single path at a time, clients would need to issue N commands to perform a full clone. On the Firefox repository, this would be ~461k commands. We'll likely need to implement a file data retrieval command that supports multiple paths. But that can be implemented later. Differential Revision: https://phab.mercurial-scm.org/D4490
author Gregory Szorc <gregory.szorc@gmail.com>
date Wed, 05 Sep 2018 09:10:17 -0700
parents c7a7c7e844e5
children aa7e312375cf
line wrap: on
line diff
--- a/mercurial/help/internals/wireprotocolv2.txt	Wed Sep 05 09:09:57 2018 -0700
+++ b/mercurial/help/internals/wireprotocolv2.txt	Wed Sep 05 09:10:17 2018 -0700
@@ -196,6 +196,79 @@
 TODO support hgtagsfnodes cache / tags data
 TODO support branch heads cache
 
+filedata
+--------
+
+Obtain various data related to an individual tracked file.
+
+The command accepts the following arguments:
+
+fields
+   (set of bytestring) Which data associated with a file to fetch.
+   The following values are recognized:
+
+   parents
+      Parent nodes for the revision.
+
+   revision
+      The raw revision data for a file.
+
+nodes
+   (array of bytestrings) File nodes whose data to retrieve.
+
+path
+   (bytestring) Path of the tracked file whose data to retrieve.
+
+TODO allow specifying revisions via alternate means (such as from
+changeset revisions or ranges)
+
+The response bytestream starts with a CBOR map describing the data that
+follows. It has the following bytestream keys:
+
+totalitems
+   (unsigned integer) Total number of file revisions whose data is
+   being returned.
+
+Following the header map is a series of 0 or more CBOR values. The first
+value is always a map describing a file revision. If this map has the
+``deltasize`` or ``revisionsize`` keys, a bytestring containing the delta
+or revision, respectively, will immediately follow the map. Otherwise
+the next value will be a map describing the next file revision.
+
+Each map has the following bytestring keys:
+
+node
+   (bytestring) The node of the file revision whose data is represented.
+
+deltabasenode
+   (bytestring) Node of the file revision the following delta is against.
+
+   Only present if the ``revision`` field is requested and delta data
+   follows this map.
+
+deltasize
+   (unsigned integer) The size of the delta data that follows this map.
+
+   Only present if the ``revision`` field is requested and delta data
+   follows this map.
+
+parents
+   (array of bytestring) The nodes of the parents of this file revision.
+
+   Only present if the ``parents`` field is requested.
+
+revisionsize
+   (unsigned integer) The size of the fulltext revision data that follows
+   this map.
+
+   Only present if the ``revision`` field is requested and fulltext revision
+   data follows this map.
+
+When ``revision`` data is requested, the server chooses to emit either fulltext
+revision data or a delta. What the server decides can be inferred by looking
+for the presence of the ``deltasize`` or ``revisionsize`` keys in the map.
+Servers MUST NOT define both keys.
+
 heads
 -----