Mercurial > hg
view mercurial/help/internals/bundle2.txt @ 43110:1fcf79e9943a
tests: use range() in generate-churning-module.py
This is a test-only script. Performance on Python 2 for creating a
full list instead of a generator doesn't matter.
With this change, test-check-pyflakes.t passes on Python 3!
Differential Revision: https://phab.mercurial-scm.org/D7019
| author | Gregory Szorc <gregory.szorc@gmail.com> |
|---|---|
| date | Mon, 07 Oct 2019 10:34:21 -0400 |
| parents | 8c8b6d13949a |
| children |
line wrap: on
line source
Bundle2 refers to a data format that is used for both on-disk storage and over-the-wire transfer of repository data and state. The data format allows the capture of multiple components of repository data. Contrast with the initial bundle format, which only captured *changegroup* data (and couldn't store bookmarks, phases, etc). Bundle2 is used for: * Transferring data from a repository (e.g. as part of an ``hg clone`` or ``hg pull`` operation). * Transferring data to a repository (e.g. as part of an ``hg push`` operation). * Storing data on disk (e.g. the result of an ``hg bundle`` operation). * Transferring the results of a repository operation (e.g. the reply to an ``hg push`` operation). At its highest level, a bundle2 payload is a stream that begins with some metadata and consists of a series of *parts*, with each part describing repository data or state or the result of an operation. New bundle2 parts are introduced over time when there is a need to capture a new form of data. A *capabilities* mechanism exists to allow peers to understand which bundle2 parts the other understands. Stream Format ============= A bundle2 payload consists of a magic string (``HG20``) followed by stream level parameters, followed by any number of payload *parts*. It may help to think of the stream level parameters as *headers* and the payload parts as the *body*. Stream Level Parameters ----------------------- Following the magic string is data that defines parameters applicable to the entire payload. Stream level parameters begin with a 32-bit unsigned big-endian integer. The value of this integer defines the number of bytes of stream level parameters that follow. The *N* bytes of raw data contains a space separated list of parameters. Each parameter consists of a required name and an optional value. Parameters have the form ``<name>`` or ``<name>=<value>``. Both the parameter name and value are URL quoted. Names MUST start with a letter. If the first letter is lower case, the parameter is advisory and can safely be ignored. If the first letter is upper case, the parameter is mandatory and the handler MUST stop if it is unable to process it. Stream level parameters apply to the entire bundle2 payload. Lower-level options should go into a bundle2 part instead. The following stream level parameters are defined: Compression Compression format of payload data. ``GZ`` denotes zlib. ``BZ`` denotes bzip2. ``ZS`` denotes zstandard. When defined, all bytes after the stream level parameters are compressed using the compression format defined by this parameter. If this parameter isn't present, data is raw/uncompressed. This parameter MUST be mandatory because attempting to consume streams without knowing how to decode the underlying bytes will result in errors. Payload Part ------------ Following the stream level parameters are 0 or more payload parts. Each payload part consists of a header and a body. The payload part header consists of a 32-bit unsigned big-endian integer defining the number of bytes in the header that follow. The special value ``0`` indicates the end of the bundle2 stream. The binary format of the part header is as follows: * 8-bit unsigned size of the part name * N-bytes alphanumeric part name * 32-bit unsigned big-endian part ID * N bytes part parameter data The *part name* identifies the type of the part. A part name with an UPPERCASE letter is mandatory. Otherwise, the part is advisory. A consumer should abort if it encounters a mandatory part it doesn't know how to process. See the sections below for each defined part type. The *part ID* is a unique identifier within the bundle used to refer to a specific part. It should be unique within the bundle2 payload. Part parameter data consists of: * 1 byte number of mandatory parameters * 1 byte number of advisory parameters * 2 * N bytes of sizes of parameter key and values * N * M blobs of values for parameter key and values Following the 2 bytes of mandatory and advisory parameter counts are 2-tuples of bytes of the sizes of each parameter. e.g. (<key size>, <value size>). Following that are the raw values, without padding. Mandatory parameters come first, followed by advisory parameters. Each parameter's key MUST be unique within the part. Following the part parameter data is the part payload. The part payload consists of a series of framed chunks. The frame header is a 32-bit big-endian integer defining the size of the chunk. The N bytes of raw payload data follows. The part payload consists of 0 or more chunks. A chunk with size ``0`` denotes the end of the part payload. Therefore, there will always be at least 1 32-bit integer following the payload part header. A chunk size of ``-1`` is used to signal an *interrupt*. If such a chunk size is seen, the stream processor should process the next bytes as a new payload part. After this payload part, processing of the original, interrupted part should resume. Capabilities ============ Bundle2 is a dynamic format that can evolve over time. For example, when a new repository data concept is invented, a new bundle2 part is typically invented to hold that data. In addition, parts performing similar functionality may come into existence if there is a better mechanism for performing certain functionality. Because the bundle2 format evolves over time, peers need to understand what bundle2 features the other can understand. The *capabilities* mechanism is how those features are expressed. Bundle2 capabilities are logically expressed as a dictionary of string key-value pairs where the keys are strings and the values are lists of strings. Capabilities are encoded for exchange between peers. The encoded capabilities blob consists of a newline (``\n``) delimited list of entries. Each entry has the form ``<key>`` or ``<key>=<value>``, depending if the capability has a value. The capability name is URL quoted (``%XX`` encoding of URL unsafe characters). The value, if present, is formed by URL quoting each value in the capability list and concatenating the result with a comma (``,``). For example, the capabilities ``novaluekey`` and ``listvaluekey`` with values ``value 1`` and ``value 2``. This would be encoded as: listvaluekey=value%201,value%202\nnovaluekey The sections below detail the defined bundle2 capabilities. HG20 ---- Denotes that the peer supports the bundle2 data format. bookmarks --------- Denotes that the peer supports the ``bookmarks`` part. Peers should not issue mandatory ``bookmarks`` parts unless this capability is present. changegroup ----------- Denotes which versions of the *changegroup* format the peer can receive. Values include ``01``, ``02``, and ``03``. The peer should not generate changegroup data for a version not specified by this capability. checkheads ---------- Denotes which forms of heads checking the peer supports. If ``related`` is in the value, then the peer supports the ``check:heads`` part and the peer is capable of detecting race conditions when applying changelog data. digests ------- Denotes which hashing formats the peer supports. Values are names of hashing function. Values include ``md5``, ``sha1``, and ``sha512``. error ----- Denotes which ``error:`` parts the peer supports. Value is a list of strings of ``error:`` part names. Valid values include ``abort``, ``unsupportecontent``, ``pushraced``, and ``pushkey``. Peers should not issue an ``error:`` part unless the type of that part is listed as supported by this capability. listkeys -------- Denotes that the peer supports the ``listkeys`` part. hgtagsfnodes ------------ Denotes that the peer supports the ``hgtagsfnodes`` part. obsmarkers ---------- Denotes that the peer supports the ``obsmarker`` part and which versions of the obsolescence data format it can receive. Values are strings like ``V<N>``. e.g. ``V1``. phases ------ Denotes that the peer supports the ``phases`` part. pushback -------- Denotes that the peer supports sending/receiving bundle2 data in response to a bundle2 request. This capability is typically used by servers that employ server-side rewriting of pushed repository data. For example, a server may wish to automatically rebase pushed changesets. When this capability is present, the server can send a bundle2 response containing the rewritten changeset data and the client will apply it. pushkey ------- Denotes that the peer supports the ``puskey`` part. remote-changegroup ------------------ Denotes that the peer supports the ``remote-changegroup`` part and which protocols it can use to fetch remote changegroup data. Values are protocol names. e.g. ``http`` and ``https``. stream ------ Denotes that the peer supports ``stream*`` parts in order to support *stream clone*. Values are which ``stream*`` parts the peer supports. ``v2`` denotes support for the ``stream2`` part. Bundle2 Part Types ================== The sections below detail the various bundle2 part types. bookmarks --------- The ``bookmarks`` part holds bookmarks information. This part has no parameters. The payload consists of entries defining bookmarks. Each entry consists of: * 20 bytes binary changeset node. * 2 bytes big endian short defining bookmark name length. * N bytes defining bookmark name. Receivers typically update bookmarks to match the state specified in this part. changegroup ----------- The ``changegroup`` part contains *changegroup* data (changelog, manifestlog, and filelog revision data). The following part parameters are defined for this part. version Changegroup version string. e.g. ``01``, ``02``, and ``03``. This parameter determines how to interpret the changegroup data within the part. nbchanges The number of changesets in this changegroup. This parameter can be used to aid in the display of progress bars, etc during part application. treemanifest Whether the changegroup contains tree manifests. targetphase The target phase of changesets in this part. Value is an integer of the target phase. The payload of this part is raw changegroup data. See :hg:`help internals.changegroups` for the format of changegroup data. check:bookmarks --------------- The ``check:bookmarks`` part is inserted into a bundle as a means for the receiver to validate that the sender's known state of bookmarks matches the receiver's. This part has no parameters. The payload is a binary stream of bookmark data. Each entry in the stream consists of: * 20 bytes binary node that bookmark is associated with * 2 bytes unsigned short defining length of bookmark name * N bytes containing the bookmark name If all bits in the node value are ``1``, then this signifies a missing bookmark. When the receiver encounters this part, for each bookmark in the part payload, it should validate that the current bookmark state matches the specified state. If it doesn't, then the receiver should take appropriate action. (In the case of pushes, this mismatch signifies a race condition and the receiver should consider rejecting the push.) check:heads ----------- The ``check:heads`` part is a means to validate that the sender's state of DAG heads matches the receiver's. This part has no parameters. The body of this part is an array of 20 byte binary nodes representing changeset heads. Receivers should compare the set of heads defined in this part to the current set of repo heads and take action if there is a mismatch in that set. Note that this part applies to *all* heads in the repo. check:phases ------------ The ``check:phases`` part validates that the sender's state of phase boundaries matches the receiver's. This part has no parameters. The payload consists of an array of 24 byte entries. Each entry is a big endian 32-bit integer defining the phase integer and 20 byte binary node value. For each changeset defined in this part, the receiver should validate that its current phase matches the phase defined in this part. The receiver should take appropriate action if a mismatch occurs. check:updated-heads ------------------- The ``check:updated-heads`` part validates that the sender's state of DAG heads updated by this bundle matches the receiver's. This type is nearly identical to ``check:heads`` except the heads in the payload are only a subset of heads in the repository. The receiver should validate that all nodes specified by the sender are branch heads and take appropriate action if not. error:abort ----------- The ``error:abort`` part conveys a fatal error. The following part parameters are defined: message The string content of the error message. hint Supplemental string giving a hint on how to fix the problem. error:pushkey ------------- The ``error:pushkey`` part conveys an error in the *pushkey* protocol. The following part parameters are defined: namespace The pushkey domain that exhibited the error. key The key whose update failed. new The value we tried to set the key to. old The old value of the key (as supplied by the client). ret The integer result code for the pushkey request. in-reply-to Part ID that triggered this error. This part is generated if there was an error applying *pushkey* data. Pushkey data includes bookmarks, phases, and obsolescence markers. error:pushraced --------------- The ``error:pushraced`` part conveys that an error occurred and the likely cause is losing a race with another pusher. The following part parameters are defined: message String error message. This part is typically emitted when a receiver examining ``check:*`` parts encountered inconsistency between incoming state and local state. The likely cause of that inconsistency is another repository change operation (often another client performing an ``hg push``). error:unsupportedcontent ------------------------ The ``error:unsupportedcontent`` part conveys that a bundle2 receiver encountered a part or content it was not able to handle. The following part parameters are defined: parttype The name of the part that triggered this error. params ``\0`` delimited list of parameters. hgtagsfnodes ------------ The ``hgtagsfnodes`` type defines file nodes for the ``.hgtags`` file for various changesets. This part has no parameters. The payload is an array of pairs of 20 byte binary nodes. The first node is a changeset node. The second node is the ``.hgtags`` file node. Resolving tags requires resolving the ``.hgtags`` file node for changesets. On large repositories, this can be expensive. Repositories cache the mapping of changeset to ``.hgtags`` file node on disk as a performance optimization. This part allows that cached data to be transferred alongside changeset data. Receivers should update their ``.hgtags`` cache file node mappings with the incoming data. listkeys -------- The ``listkeys`` part holds content for a *pushkey* namespace. The following part parameters are defined: namespace The pushkey domain this data belongs to. The part payload contains a newline (``\n``) delimited list of tab (``\t``) delimited key-value pairs defining entries in this pushkey namespace. obsmarkers ---------- The ``obsmarkers`` part defines obsolescence markers. This part has no parameters. The payload consists of obsolescence markers using the on-disk markers format. The first byte defines the version format. The receiver should apply the obsolescence markers defined in this part. A ``reply:obsmarkers`` part should be sent to the sender, if possible. output ------ The ``output`` part is used to display output on the receiver. This part has no parameters. The payload consists of raw data to be printed on the receiver. phase-heads ----------- The ``phase-heads`` part defines phase boundaries. This part has no parameters. The payload consists of an array of 24 byte entries. Each entry is a big endian 32-bit integer defining the phase integer and 20 byte binary node value. pushkey ------- The ``pushkey`` part communicates an intent to perform a ``pushkey`` request. The following part parameters are defined: namespace The pushkey domain to operate on. key The key within the pushkey namespace that is being changed. old The old value for the key being changed. new The new value for the key being changed. This part has no payload. The receiver should perform a pushkey operation as described by this part's parameters. If the pushey operation fails, a ``reply:pushkey`` part should be sent back to the sender, if possible. The ``in-reply-to`` part parameter should reference the source part. pushvars -------- The ``pushvars`` part defines environment variables that should be set when processing this bundle2 payload. The part's advisory parameters define environment variables. There is no part payload. When received, part parameters are prefixed with ``USERVAR_`` and the resulting variables are defined in the hooks context for the current bundle2 application. This part provides a mechanism for senders to inject extra state into the hook execution environment on the receiver. remote-changegroup ------------------ The ``remote-changegroup`` part defines an external location of a bundle to apply. This part can be used by servers to serve pre-generated bundles hosted at arbitrary URLs. The following part parameters are defined: url The URL of the remote bundle. size The size in bytes of the remote bundle. digests A space separated list of the digest types provided in additional part parameters. digest:<type> The hexadecimal representation of the digest (hash) of the remote bundle. There is no payload for this part type. When encountered, clients should attempt to fetch the URL being advertised and read and apply it as a bundle. The ``size`` and ``digest:<type>`` parameters should be used to validate that the downloaded bundle matches what was advertised. If a mismatch occurs, the client should abort. reply:changegroup ----------------- The ``reply:changegroup`` part conveys the results of application of a ``changegroup`` part. The following part parameters are defined: return Integer return code from changegroup application. in-reply-to Part ID of part this reply is in response to. reply:obsmarkers ---------------- The ``reply:obsmarkers`` part conveys the results of applying an ``obsmarkers`` part. The following part parameters are defined: new The integer number of new markers that were applied. in-reply-to The part ID that this part is in reply to. reply:pushkey ------------- The ``reply:pushkey`` part conveys the result of a *pushkey* operation. The following part parameters are defined: return Integer result code from pushkey operation. in-reply-to Part ID that triggered this pushkey operation. This part has no payload. replycaps --------- The ``replycaps`` part notifies the receiver that a reply bundle should be created. This part has no parameters. The payload consists of a bundle2 capabilities blob. stream2 ------- The ``stream2`` part contains *streaming clone* version 2 data. The following part parameters are defined: requirements URL quoted repository requirements string. Requirements are delimited by a command (``,``). filecount The total number of files being transferred in the payload. bytecount The total size of file content being transferred in the payload. The payload consists of raw stream clone version 2 data. The ``filecount`` and ``bytecount`` parameters can be used for progress and reporting purposes. The values may not be exact.