Show More
@@ -1,417 +1,773 b'' | |||||
1 | The Mercurial wire protocol is a request-response based protocol |
|
1 | The Mercurial wire protocol is a request-response based protocol | |
2 | with multiple wire representations. |
|
2 | with multiple wire representations. | |
3 |
|
3 | |||
4 | Each request is modeled as a command name, a dictionary of arguments, and |
|
4 | Each request is modeled as a command name, a dictionary of arguments, and | |
5 | optional raw input. Command arguments and their types are intrinsic |
|
5 | optional raw input. Command arguments and their types are intrinsic | |
6 | properties of commands. So is the response type of the command. This means |
|
6 | properties of commands. So is the response type of the command. This means | |
7 | clients can't always send arbitrary arguments to servers and servers can't |
|
7 | clients can't always send arbitrary arguments to servers and servers can't | |
8 | return multiple response types. |
|
8 | return multiple response types. | |
9 |
|
9 | |||
10 | The protocol is synchronous and does not support multiplexing (concurrent |
|
10 | The protocol is synchronous and does not support multiplexing (concurrent | |
11 | commands). |
|
11 | commands). | |
12 |
|
12 | |||
13 | Transport Protocols |
|
13 | Transport Protocols | |
14 | =================== |
|
14 | =================== | |
15 |
|
15 | |||
16 | HTTP Transport |
|
16 | HTTP Transport | |
17 | -------------- |
|
17 | -------------- | |
18 |
|
18 | |||
19 | Commands are issued as HTTP/1.0 or HTTP/1.1 requests. Commands are |
|
19 | Commands are issued as HTTP/1.0 or HTTP/1.1 requests. Commands are | |
20 | sent to the base URL of the repository with the command name sent in |
|
20 | sent to the base URL of the repository with the command name sent in | |
21 | the ``cmd`` query string parameter. e.g. |
|
21 | the ``cmd`` query string parameter. e.g. | |
22 | ``https://example.com/repo?cmd=capabilities``. The HTTP method is ``GET`` |
|
22 | ``https://example.com/repo?cmd=capabilities``. The HTTP method is ``GET`` | |
23 | or ``POST`` depending on the command and whether there is a request |
|
23 | or ``POST`` depending on the command and whether there is a request | |
24 | body. |
|
24 | body. | |
25 |
|
25 | |||
26 | Command arguments can be sent multiple ways. |
|
26 | Command arguments can be sent multiple ways. | |
27 |
|
27 | |||
28 | The simplest is part of the URL query string using ``x-www-form-urlencoded`` |
|
28 | The simplest is part of the URL query string using ``x-www-form-urlencoded`` | |
29 | encoding (see Python's ``urllib.urlencode()``. However, many servers impose |
|
29 | encoding (see Python's ``urllib.urlencode()``. However, many servers impose | |
30 | length limitations on the URL. So this mechanism is typically only used if |
|
30 | length limitations on the URL. So this mechanism is typically only used if | |
31 | the server doesn't support other mechanisms. |
|
31 | the server doesn't support other mechanisms. | |
32 |
|
32 | |||
33 | If the server supports the ``httpheader`` capability, command arguments can |
|
33 | If the server supports the ``httpheader`` capability, command arguments can | |
34 | be sent in HTTP request headers named ``X-HgArg-<N>`` where ``<N>`` is an |
|
34 | be sent in HTTP request headers named ``X-HgArg-<N>`` where ``<N>`` is an | |
35 | integer starting at 1. A ``x-www-form-urlencoded`` representation of the |
|
35 | integer starting at 1. A ``x-www-form-urlencoded`` representation of the | |
36 | arguments is obtained. This full string is then split into chunks and sent |
|
36 | arguments is obtained. This full string is then split into chunks and sent | |
37 | in numbered ``X-HgArg-<N>`` headers. The maximum length of each HTTP header |
|
37 | in numbered ``X-HgArg-<N>`` headers. The maximum length of each HTTP header | |
38 | is defined by the server in the ``httpheader`` capability value, which defaults |
|
38 | is defined by the server in the ``httpheader`` capability value, which defaults | |
39 | to ``1024``. The server reassembles the encoded arguments string by |
|
39 | to ``1024``. The server reassembles the encoded arguments string by | |
40 | concatenating the ``X-HgArg-<N>`` headers then URL decodes them into a |
|
40 | concatenating the ``X-HgArg-<N>`` headers then URL decodes them into a | |
41 | dictionary. |
|
41 | dictionary. | |
42 |
|
42 | |||
43 | The list of ``X-HgArg-<N>`` headers should be added to the ``Vary`` request |
|
43 | The list of ``X-HgArg-<N>`` headers should be added to the ``Vary`` request | |
44 | header to instruct caches to take these headers into consideration when caching |
|
44 | header to instruct caches to take these headers into consideration when caching | |
45 | requests. |
|
45 | requests. | |
46 |
|
46 | |||
47 | If the server supports the ``httppostargs`` capability, the client |
|
47 | If the server supports the ``httppostargs`` capability, the client | |
48 | may send command arguments in the HTTP request body as part of an |
|
48 | may send command arguments in the HTTP request body as part of an | |
49 | HTTP POST request. The command arguments will be URL encoded just like |
|
49 | HTTP POST request. The command arguments will be URL encoded just like | |
50 | they would for sending them via HTTP headers. However, no splitting is |
|
50 | they would for sending them via HTTP headers. However, no splitting is | |
51 | performed: the raw arguments are included in the HTTP request body. |
|
51 | performed: the raw arguments are included in the HTTP request body. | |
52 |
|
52 | |||
53 | The client sends a ``X-HgArgs-Post`` header with the string length of the |
|
53 | The client sends a ``X-HgArgs-Post`` header with the string length of the | |
54 | encoded arguments data. Additional data may be included in the HTTP |
|
54 | encoded arguments data. Additional data may be included in the HTTP | |
55 | request body immediately following the argument data. The offset of the |
|
55 | request body immediately following the argument data. The offset of the | |
56 | non-argument data is defined by the ``X-HgArgs-Post`` header. The |
|
56 | non-argument data is defined by the ``X-HgArgs-Post`` header. The | |
57 | ``X-HgArgs-Post`` header is not required if there is no argument data. |
|
57 | ``X-HgArgs-Post`` header is not required if there is no argument data. | |
58 |
|
58 | |||
59 | Additional command data can be sent as part of the HTTP request body. The |
|
59 | Additional command data can be sent as part of the HTTP request body. The | |
60 | default ``Content-Type`` when sending data is ``application/mercurial-0.1``. |
|
60 | default ``Content-Type`` when sending data is ``application/mercurial-0.1``. | |
61 | A ``Content-Length`` header is currently always sent. |
|
61 | A ``Content-Length`` header is currently always sent. | |
62 |
|
62 | |||
63 | Example HTTP requests:: |
|
63 | Example HTTP requests:: | |
64 |
|
64 | |||
65 | GET /repo?cmd=capabilities |
|
65 | GET /repo?cmd=capabilities | |
66 | X-HgArg-1: foo=bar&baz=hello%20world |
|
66 | X-HgArg-1: foo=bar&baz=hello%20world | |
67 |
|
67 | |||
68 | The ``Content-Type`` HTTP response header identifies the response as coming |
|
68 | The ``Content-Type`` HTTP response header identifies the response as coming | |
69 | from Mercurial and can also be used to signal an error has occurred. |
|
69 | from Mercurial and can also be used to signal an error has occurred. | |
70 |
|
70 | |||
71 | The ``application/mercurial-0.1`` media type indicates a generic Mercurial |
|
71 | The ``application/mercurial-0.1`` media type indicates a generic Mercurial | |
72 | response. It matches the media type sent by the client. |
|
72 | response. It matches the media type sent by the client. | |
73 |
|
73 | |||
74 | The ``application/hg-error`` media type indicates a generic error occurred. |
|
74 | The ``application/hg-error`` media type indicates a generic error occurred. | |
75 | The content of the HTTP response body typically holds text describing the |
|
75 | The content of the HTTP response body typically holds text describing the | |
76 | error. |
|
76 | error. | |
77 |
|
77 | |||
78 | The ``application/hg-changegroup`` media type indicates a changegroup response |
|
78 | The ``application/hg-changegroup`` media type indicates a changegroup response | |
79 | type. |
|
79 | type. | |
80 |
|
80 | |||
81 | Clients also accept the ``text/plain`` media type. All other media |
|
81 | Clients also accept the ``text/plain`` media type. All other media | |
82 | types should cause the client to error. |
|
82 | types should cause the client to error. | |
83 |
|
83 | |||
84 | Clients should issue a ``User-Agent`` request header that identifies the client. |
|
84 | Clients should issue a ``User-Agent`` request header that identifies the client. | |
85 | The server should not use the ``User-Agent`` for feature detection. |
|
85 | The server should not use the ``User-Agent`` for feature detection. | |
86 |
|
86 | |||
87 | A command returning a ``string`` response issues the |
|
87 | A command returning a ``string`` response issues the | |
88 | ``application/mercurial-0.1`` media type and the HTTP response body contains |
|
88 | ``application/mercurial-0.1`` media type and the HTTP response body contains | |
89 | the raw string value. A ``Content-Length`` header is typically issued. |
|
89 | the raw string value. A ``Content-Length`` header is typically issued. | |
90 |
|
90 | |||
91 | A command returning a ``stream`` response issues the |
|
91 | A command returning a ``stream`` response issues the | |
92 | ``application/mercurial-0.1`` media type and the HTTP response is typically |
|
92 | ``application/mercurial-0.1`` media type and the HTTP response is typically | |
93 | using *chunked transfer* (``Transfer-Encoding: chunked``). |
|
93 | using *chunked transfer* (``Transfer-Encoding: chunked``). | |
94 |
|
94 | |||
95 | SSH Transport |
|
95 | SSH Transport | |
96 | ============= |
|
96 | ============= | |
97 |
|
97 | |||
98 | The SSH transport is a custom text-based protocol suitable for use over any |
|
98 | The SSH transport is a custom text-based protocol suitable for use over any | |
99 | bi-directional stream transport. It is most commonly used with SSH. |
|
99 | bi-directional stream transport. It is most commonly used with SSH. | |
100 |
|
100 | |||
101 | A SSH transport server can be started with ``hg serve --stdio``. The stdin, |
|
101 | A SSH transport server can be started with ``hg serve --stdio``. The stdin, | |
102 | stderr, and stdout file descriptors of the started process are used to exchange |
|
102 | stderr, and stdout file descriptors of the started process are used to exchange | |
103 | data. When Mercurial connects to a remote server over SSH, it actually starts |
|
103 | data. When Mercurial connects to a remote server over SSH, it actually starts | |
104 | a ``hg serve --stdio`` process on the remote server. |
|
104 | a ``hg serve --stdio`` process on the remote server. | |
105 |
|
105 | |||
106 | Commands are issued by sending the command name followed by a trailing newline |
|
106 | Commands are issued by sending the command name followed by a trailing newline | |
107 | ``\n`` to the server. e.g. ``capabilities\n``. |
|
107 | ``\n`` to the server. e.g. ``capabilities\n``. | |
108 |
|
108 | |||
109 | Command arguments are sent in the following format:: |
|
109 | Command arguments are sent in the following format:: | |
110 |
|
110 | |||
111 | <argument> <length>\n<value> |
|
111 | <argument> <length>\n<value> | |
112 |
|
112 | |||
113 | That is, the argument string name followed by a space followed by the |
|
113 | That is, the argument string name followed by a space followed by the | |
114 | integer length of the value (expressed as a string) followed by a newline |
|
114 | integer length of the value (expressed as a string) followed by a newline | |
115 | (``\n``) followed by the raw argument value. |
|
115 | (``\n``) followed by the raw argument value. | |
116 |
|
116 | |||
117 | Dictionary arguments are encoded differently:: |
|
117 | Dictionary arguments are encoded differently:: | |
118 |
|
118 | |||
119 | <argument> <# elements>\n |
|
119 | <argument> <# elements>\n | |
120 | <key1> <length1>\n<value1> |
|
120 | <key1> <length1>\n<value1> | |
121 | <key2> <length2>\n<value2> |
|
121 | <key2> <length2>\n<value2> | |
122 | ... |
|
122 | ... | |
123 |
|
123 | |||
124 | Non-argument data is sent immediately after the final argument value. It is |
|
124 | Non-argument data is sent immediately after the final argument value. It is | |
125 | encoded in chunks:: |
|
125 | encoded in chunks:: | |
126 |
|
126 | |||
127 | <length>\n<data> |
|
127 | <length>\n<data> | |
128 |
|
128 | |||
129 | Each command declares a list of supported arguments and their types. If a |
|
129 | Each command declares a list of supported arguments and their types. If a | |
130 | client sends an unknown argument to the server, the server should abort |
|
130 | client sends an unknown argument to the server, the server should abort | |
131 | immediately. The special argument ``*`` in a command's definition indicates |
|
131 | immediately. The special argument ``*`` in a command's definition indicates | |
132 | that all argument names are allowed. |
|
132 | that all argument names are allowed. | |
133 |
|
133 | |||
134 | The definition of supported arguments and types is initially made when a |
|
134 | The definition of supported arguments and types is initially made when a | |
135 | new command is implemented. The client and server must initially independently |
|
135 | new command is implemented. The client and server must initially independently | |
136 | agree on the arguments and their types. This initial set of arguments can be |
|
136 | agree on the arguments and their types. This initial set of arguments can be | |
137 | supplemented through the presence of *capabilities* advertised by the server. |
|
137 | supplemented through the presence of *capabilities* advertised by the server. | |
138 |
|
138 | |||
139 | Each command has a defined expected response type. |
|
139 | Each command has a defined expected response type. | |
140 |
|
140 | |||
141 | A ``string`` response type is a length framed value. The response consists of |
|
141 | A ``string`` response type is a length framed value. The response consists of | |
142 | the string encoded integer length of a value followed by a newline (``\n``) |
|
142 | the string encoded integer length of a value followed by a newline (``\n``) | |
143 | followed by the value. Empty values are allowed (and are represented as |
|
143 | followed by the value. Empty values are allowed (and are represented as | |
144 | ``0\n``). |
|
144 | ``0\n``). | |
145 |
|
145 | |||
146 | A ``stream`` response type consists of raw bytes of data. There is no framing. |
|
146 | A ``stream`` response type consists of raw bytes of data. There is no framing. | |
147 |
|
147 | |||
148 | A generic error response type is also supported. It consists of a an error |
|
148 | A generic error response type is also supported. It consists of a an error | |
149 | message written to ``stderr`` followed by ``\n-\n``. In addition, ``\n`` is |
|
149 | message written to ``stderr`` followed by ``\n-\n``. In addition, ``\n`` is | |
150 | written to ``stdout``. |
|
150 | written to ``stdout``. | |
151 |
|
151 | |||
152 | If the server receives an unknown command, it will send an empty ``string`` |
|
152 | If the server receives an unknown command, it will send an empty ``string`` | |
153 | response. |
|
153 | response. | |
154 |
|
154 | |||
155 | The server terminates if it receives an empty command (a ``\n`` character). |
|
155 | The server terminates if it receives an empty command (a ``\n`` character). | |
156 |
|
156 | |||
157 | Capabilities |
|
157 | Capabilities | |
158 | ============ |
|
158 | ============ | |
159 |
|
159 | |||
160 | Servers advertise supported wire protocol features. This allows clients to |
|
160 | Servers advertise supported wire protocol features. This allows clients to | |
161 | probe for server features before blindly calling a command or passing a |
|
161 | probe for server features before blindly calling a command or passing a | |
162 | specific argument. |
|
162 | specific argument. | |
163 |
|
163 | |||
164 | The server's features are exposed via a *capabilities* string. This is a |
|
164 | The server's features are exposed via a *capabilities* string. This is a | |
165 | space-delimited string of tokens/features. Some features are single words |
|
165 | space-delimited string of tokens/features. Some features are single words | |
166 | like ``lookup`` or ``batch``. Others are complicated key-value pairs |
|
166 | like ``lookup`` or ``batch``. Others are complicated key-value pairs | |
167 | advertising sub-features. e.g. ``httpheader=2048``. When complex, non-word |
|
167 | advertising sub-features. e.g. ``httpheader=2048``. When complex, non-word | |
168 | values are used, each feature name can define its own encoding of sub-values. |
|
168 | values are used, each feature name can define its own encoding of sub-values. | |
169 | Comma-delimited and ``x-www-form-urlencoded`` values are common. |
|
169 | Comma-delimited and ``x-www-form-urlencoded`` values are common. | |
170 |
|
170 | |||
171 | The following document capabilities defined by the canonical Mercurial server |
|
171 | The following document capabilities defined by the canonical Mercurial server | |
172 | implementation. |
|
172 | implementation. | |
173 |
|
173 | |||
174 | batch |
|
174 | batch | |
175 | ----- |
|
175 | ----- | |
176 |
|
176 | |||
177 | Whether the server supports the ``batch`` command. |
|
177 | Whether the server supports the ``batch`` command. | |
178 |
|
178 | |||
179 | This capability/command was introduced in Mercurial 1.9 (released July 2011). |
|
179 | This capability/command was introduced in Mercurial 1.9 (released July 2011). | |
180 |
|
180 | |||
181 | branchmap |
|
181 | branchmap | |
182 | --------- |
|
182 | --------- | |
183 |
|
183 | |||
184 | Whether the server supports the ``branchmap`` command. |
|
184 | Whether the server supports the ``branchmap`` command. | |
185 |
|
185 | |||
186 | This capability/command was introduced in Mercurial 1.3 (released July 2009). |
|
186 | This capability/command was introduced in Mercurial 1.3 (released July 2009). | |
187 |
|
187 | |||
188 | bundle2-exp |
|
188 | bundle2-exp | |
189 | ----------- |
|
189 | ----------- | |
190 |
|
190 | |||
191 | Precursor to ``bundle2`` capability that was used before bundle2 was a |
|
191 | Precursor to ``bundle2`` capability that was used before bundle2 was a | |
192 | stable feature. |
|
192 | stable feature. | |
193 |
|
193 | |||
194 | This capability was introduced in Mercurial 3.0 behind an experimental |
|
194 | This capability was introduced in Mercurial 3.0 behind an experimental | |
195 | flag. This capability should not be observed in the wild. |
|
195 | flag. This capability should not be observed in the wild. | |
196 |
|
196 | |||
197 | bundle2 |
|
197 | bundle2 | |
198 | ------- |
|
198 | ------- | |
199 |
|
199 | |||
200 | Indicates whether the server supports the ``bundle2`` data exchange format. |
|
200 | Indicates whether the server supports the ``bundle2`` data exchange format. | |
201 |
|
201 | |||
202 | The value of the capability is a URL quoted, newline (``\n``) delimited |
|
202 | The value of the capability is a URL quoted, newline (``\n``) delimited | |
203 | list of keys or key-value pairs. |
|
203 | list of keys or key-value pairs. | |
204 |
|
204 | |||
205 | A key is simply a URL encoded string. |
|
205 | A key is simply a URL encoded string. | |
206 |
|
206 | |||
207 | A key-value pair is a URL encoded key separated from a URL encoded value by |
|
207 | A key-value pair is a URL encoded key separated from a URL encoded value by | |
208 | an ``=``. If the value is a list, elements are delimited by a ``,`` after |
|
208 | an ``=``. If the value is a list, elements are delimited by a ``,`` after | |
209 | URL encoding. |
|
209 | URL encoding. | |
210 |
|
210 | |||
211 | For example, say we have the values:: |
|
211 | For example, say we have the values:: | |
212 |
|
212 | |||
213 | {'HG20': [], 'changegroup': ['01', '02'], 'digests': ['sha1', 'sha512']} |
|
213 | {'HG20': [], 'changegroup': ['01', '02'], 'digests': ['sha1', 'sha512']} | |
214 |
|
214 | |||
215 | We would first construct a string:: |
|
215 | We would first construct a string:: | |
216 |
|
216 | |||
217 | HG20\nchangegroup=01,02\ndigests=sha1,sha512 |
|
217 | HG20\nchangegroup=01,02\ndigests=sha1,sha512 | |
218 |
|
218 | |||
219 | We would then URL quote this string:: |
|
219 | We would then URL quote this string:: | |
220 |
|
220 | |||
221 | HG20%0Achangegroup%3D01%2C02%0Adigests%3Dsha1%2Csha512 |
|
221 | HG20%0Achangegroup%3D01%2C02%0Adigests%3Dsha1%2Csha512 | |
222 |
|
222 | |||
223 | This capability was introduced in Mercurial 3.4 (released May 2015). |
|
223 | This capability was introduced in Mercurial 3.4 (released May 2015). | |
224 |
|
224 | |||
225 | changegroupsubset |
|
225 | changegroupsubset | |
226 | ----------------- |
|
226 | ----------------- | |
227 |
|
227 | |||
228 | Whether the server supports the ``changegroupsubset`` command. |
|
228 | Whether the server supports the ``changegroupsubset`` command. | |
229 |
|
229 | |||
230 | This capability was introduced in Mercurial 0.9.2 (released December |
|
230 | This capability was introduced in Mercurial 0.9.2 (released December | |
231 | 2006). |
|
231 | 2006). | |
232 |
|
232 | |||
233 | This capability was introduced at the same time as the ``lookup`` |
|
233 | This capability was introduced at the same time as the ``lookup`` | |
234 | capability/command. |
|
234 | capability/command. | |
235 |
|
235 | |||
236 | getbundle |
|
236 | getbundle | |
237 | --------- |
|
237 | --------- | |
238 |
|
238 | |||
239 | Whether the server supports the ``getbundle`` command. |
|
239 | Whether the server supports the ``getbundle`` command. | |
240 |
|
240 | |||
241 | This capability was introduced in Mercurial 1.9 (released July 2011). |
|
241 | This capability was introduced in Mercurial 1.9 (released July 2011). | |
242 |
|
242 | |||
243 | httpheader |
|
243 | httpheader | |
244 | ---------- |
|
244 | ---------- | |
245 |
|
245 | |||
246 | Whether the server supports receiving command arguments via HTTP request |
|
246 | Whether the server supports receiving command arguments via HTTP request | |
247 | headers. |
|
247 | headers. | |
248 |
|
248 | |||
249 | The value of the capability is an integer describing the max header |
|
249 | The value of the capability is an integer describing the max header | |
250 | length that clients should send. Clients should ignore any content after a |
|
250 | length that clients should send. Clients should ignore any content after a | |
251 | comma in the value, as this is reserved for future use. |
|
251 | comma in the value, as this is reserved for future use. | |
252 |
|
252 | |||
253 | This capability was introduced in Mercurial 1.9 (released July 2011). |
|
253 | This capability was introduced in Mercurial 1.9 (released July 2011). | |
254 |
|
254 | |||
255 | httppostargs |
|
255 | httppostargs | |
256 | ------------ |
|
256 | ------------ | |
257 |
|
257 | |||
258 | **Experimental** |
|
258 | **Experimental** | |
259 |
|
259 | |||
260 | Indicates that the server supports and prefers clients send command arguments |
|
260 | Indicates that the server supports and prefers clients send command arguments | |
261 | via a HTTP POST request as part of the request body. |
|
261 | via a HTTP POST request as part of the request body. | |
262 |
|
262 | |||
263 | This capability was introduced in Mercurial 3.8 (released May 2016). |
|
263 | This capability was introduced in Mercurial 3.8 (released May 2016). | |
264 |
|
264 | |||
265 | known |
|
265 | known | |
266 | ----- |
|
266 | ----- | |
267 |
|
267 | |||
268 | Whether the server supports the ``known`` command. |
|
268 | Whether the server supports the ``known`` command. | |
269 |
|
269 | |||
270 | This capability/command was introduced in Mercurial 1.9 (released July 2011). |
|
270 | This capability/command was introduced in Mercurial 1.9 (released July 2011). | |
271 |
|
271 | |||
272 | lookup |
|
272 | lookup | |
273 | ------ |
|
273 | ------ | |
274 |
|
274 | |||
275 | Whether the server supports the ``lookup`` command. |
|
275 | Whether the server supports the ``lookup`` command. | |
276 |
|
276 | |||
277 | This capability was introduced in Mercurial 0.9.2 (released December |
|
277 | This capability was introduced in Mercurial 0.9.2 (released December | |
278 | 2006). |
|
278 | 2006). | |
279 |
|
279 | |||
280 | This capability was introduced at the same time as the ``changegroupsubset`` |
|
280 | This capability was introduced at the same time as the ``changegroupsubset`` | |
281 | capability/command. |
|
281 | capability/command. | |
282 |
|
282 | |||
283 | pushkey |
|
283 | pushkey | |
284 | ------- |
|
284 | ------- | |
285 |
|
285 | |||
286 | Whether the server supports the ``pushkey`` and ``listkeys`` commands. |
|
286 | Whether the server supports the ``pushkey`` and ``listkeys`` commands. | |
287 |
|
287 | |||
288 | This capability was introduced in Mercurial 1.6 (released July 2010). |
|
288 | This capability was introduced in Mercurial 1.6 (released July 2010). | |
289 |
|
289 | |||
290 | standardbundle |
|
290 | standardbundle | |
291 | -------------- |
|
291 | -------------- | |
292 |
|
292 | |||
293 | **Unsupported** |
|
293 | **Unsupported** | |
294 |
|
294 | |||
295 | This capability was introduced during the Mercurial 0.9.2 development cycle in |
|
295 | This capability was introduced during the Mercurial 0.9.2 development cycle in | |
296 | 2006. It was never present in a release, as it was replaced by the ``unbundle`` |
|
296 | 2006. It was never present in a release, as it was replaced by the ``unbundle`` | |
297 | capability. This capability should not be encountered in the wild. |
|
297 | capability. This capability should not be encountered in the wild. | |
298 |
|
298 | |||
299 | stream-preferred |
|
299 | stream-preferred | |
300 | ---------------- |
|
300 | ---------------- | |
301 |
|
301 | |||
302 | If present the server prefers that clients clone using the streaming clone |
|
302 | If present the server prefers that clients clone using the streaming clone | |
303 | protocol (``hg clone --uncompressed``) rather than the standard |
|
303 | protocol (``hg clone --uncompressed``) rather than the standard | |
304 | changegroup/bundle based protocol. |
|
304 | changegroup/bundle based protocol. | |
305 |
|
305 | |||
306 | This capability was introduced in Mercurial 2.2 (released May 2012). |
|
306 | This capability was introduced in Mercurial 2.2 (released May 2012). | |
307 |
|
307 | |||
308 | streamreqs |
|
308 | streamreqs | |
309 | ---------- |
|
309 | ---------- | |
310 |
|
310 | |||
311 | Indicates whether the server supports *streaming clones* and the *requirements* |
|
311 | Indicates whether the server supports *streaming clones* and the *requirements* | |
312 | that clients must support to receive it. |
|
312 | that clients must support to receive it. | |
313 |
|
313 | |||
314 | If present, the server supports the ``stream_out`` command, which transmits |
|
314 | If present, the server supports the ``stream_out`` command, which transmits | |
315 | raw revlogs from the repository instead of changegroups. This provides a faster |
|
315 | raw revlogs from the repository instead of changegroups. This provides a faster | |
316 | cloning mechanism at the expense of more bandwidth used. |
|
316 | cloning mechanism at the expense of more bandwidth used. | |
317 |
|
317 | |||
318 | The value of this capability is a comma-delimited list of repo format |
|
318 | The value of this capability is a comma-delimited list of repo format | |
319 | *requirements*. These are requirements that impact the reading of data in |
|
319 | *requirements*. These are requirements that impact the reading of data in | |
320 | the ``.hg/store`` directory. An example value is |
|
320 | the ``.hg/store`` directory. An example value is | |
321 | ``streamreqs=generaldelta,revlogv1`` indicating the server repo requires |
|
321 | ``streamreqs=generaldelta,revlogv1`` indicating the server repo requires | |
322 | the ``revlogv1`` and ``generaldelta`` requirements. |
|
322 | the ``revlogv1`` and ``generaldelta`` requirements. | |
323 |
|
323 | |||
324 | If the only format requirement is ``revlogv1``, the server may expose the |
|
324 | If the only format requirement is ``revlogv1``, the server may expose the | |
325 | ``stream`` capability instead of the ``streamreqs`` capability. |
|
325 | ``stream`` capability instead of the ``streamreqs`` capability. | |
326 |
|
326 | |||
327 | This capability was introduced in Mercurial 1.7 (released November 2010). |
|
327 | This capability was introduced in Mercurial 1.7 (released November 2010). | |
328 |
|
328 | |||
329 | stream |
|
329 | stream | |
330 | ------ |
|
330 | ------ | |
331 |
|
331 | |||
332 | Whether the server supports *streaming clones* from ``revlogv1`` repos. |
|
332 | Whether the server supports *streaming clones* from ``revlogv1`` repos. | |
333 |
|
333 | |||
334 | If present, the server supports the ``stream_out`` command, which transmits |
|
334 | If present, the server supports the ``stream_out`` command, which transmits | |
335 | raw revlogs from the repository instead of changegroups. This provides a faster |
|
335 | raw revlogs from the repository instead of changegroups. This provides a faster | |
336 | cloning mechanism at the expense of more bandwidth used. |
|
336 | cloning mechanism at the expense of more bandwidth used. | |
337 |
|
337 | |||
338 | This capability was introduced in Mercurial 0.9.1 (released July 2006). |
|
338 | This capability was introduced in Mercurial 0.9.1 (released July 2006). | |
339 |
|
339 | |||
340 | When initially introduced, the value of the capability was the numeric |
|
340 | When initially introduced, the value of the capability was the numeric | |
341 | revlog revision. e.g. ``stream=1``. This indicates the changegroup is using |
|
341 | revlog revision. e.g. ``stream=1``. This indicates the changegroup is using | |
342 | ``revlogv1``. This simple integer value wasn't powerful enough, so the |
|
342 | ``revlogv1``. This simple integer value wasn't powerful enough, so the | |
343 | ``streamreqs`` capability was invented to handle cases where the repo |
|
343 | ``streamreqs`` capability was invented to handle cases where the repo | |
344 | requirements have more than just ``revlogv1``. Newer servers omit the |
|
344 | requirements have more than just ``revlogv1``. Newer servers omit the | |
345 | ``=1`` since it was the only value supported and the value of ``1`` can |
|
345 | ``=1`` since it was the only value supported and the value of ``1`` can | |
346 | be implied by clients. |
|
346 | be implied by clients. | |
347 |
|
347 | |||
348 | unbundlehash |
|
348 | unbundlehash | |
349 | ------------ |
|
349 | ------------ | |
350 |
|
350 | |||
351 | Whether the ``unbundle`` commands supports receiving a hash of all the |
|
351 | Whether the ``unbundle`` commands supports receiving a hash of all the | |
352 | heads instead of a list. |
|
352 | heads instead of a list. | |
353 |
|
353 | |||
354 | For more, see the documentation for the ``unbundle`` command. |
|
354 | For more, see the documentation for the ``unbundle`` command. | |
355 |
|
355 | |||
356 | This capability was introduced in Mercurial 1.9 (released July 2011). |
|
356 | This capability was introduced in Mercurial 1.9 (released July 2011). | |
357 |
|
357 | |||
358 | unbundle |
|
358 | unbundle | |
359 | -------- |
|
359 | -------- | |
360 |
|
360 | |||
361 | Whether the server supports pushing via the ``unbundle`` command. |
|
361 | Whether the server supports pushing via the ``unbundle`` command. | |
362 |
|
362 | |||
363 | This capability/command has been present since Mercurial 0.9.1 (released |
|
363 | This capability/command has been present since Mercurial 0.9.1 (released | |
364 | July 2006). |
|
364 | July 2006). | |
365 |
|
365 | |||
366 | Mercurial 0.9.2 (released December 2006) added values to the capability |
|
366 | Mercurial 0.9.2 (released December 2006) added values to the capability | |
367 | indicating which bundle types the server supports receiving. This value is a |
|
367 | indicating which bundle types the server supports receiving. This value is a | |
368 | comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values |
|
368 | comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values | |
369 | reflects the priority/preference of that type, where the first value is the |
|
369 | reflects the priority/preference of that type, where the first value is the | |
370 | most preferred type. |
|
370 | most preferred type. | |
371 |
|
371 | |||
372 | Handshake Protocol |
|
372 | Handshake Protocol | |
373 | ================== |
|
373 | ================== | |
374 |
|
374 | |||
375 | While not explicitly required, it is common for clients to perform a |
|
375 | While not explicitly required, it is common for clients to perform a | |
376 | *handshake* when connecting to a server. The handshake accomplishes 2 things: |
|
376 | *handshake* when connecting to a server. The handshake accomplishes 2 things: | |
377 |
|
377 | |||
378 | * Obtaining capabilities and other server features |
|
378 | * Obtaining capabilities and other server features | |
379 | * Flushing extra server output (e.g. SSH servers may print extra text |
|
379 | * Flushing extra server output (e.g. SSH servers may print extra text | |
380 | when connecting that may confuse the wire protocol) |
|
380 | when connecting that may confuse the wire protocol) | |
381 |
|
381 | |||
382 | This isn't a traditional *handshake* as far as network protocols go because |
|
382 | This isn't a traditional *handshake* as far as network protocols go because | |
383 | there is no persistent state as a result of the handshake: the handshake is |
|
383 | there is no persistent state as a result of the handshake: the handshake is | |
384 | simply the issuing of commands and commands are stateless. |
|
384 | simply the issuing of commands and commands are stateless. | |
385 |
|
385 | |||
386 | The canonical clients perform a capabilities lookup at connection establishment |
|
386 | The canonical clients perform a capabilities lookup at connection establishment | |
387 | time. This is because clients must assume a server only supports the features |
|
387 | time. This is because clients must assume a server only supports the features | |
388 | of the original Mercurial server implementation until proven otherwise (from |
|
388 | of the original Mercurial server implementation until proven otherwise (from | |
389 | advertised capabilities). Nearly every server running today supports features |
|
389 | advertised capabilities). Nearly every server running today supports features | |
390 | that weren't present in the original Mercurial server implementation. Rather |
|
390 | that weren't present in the original Mercurial server implementation. Rather | |
391 | than wait for a client to perform functionality that needs to consult |
|
391 | than wait for a client to perform functionality that needs to consult | |
392 | capabilities, it issues the lookup at connection start to avoid any delay later. |
|
392 | capabilities, it issues the lookup at connection start to avoid any delay later. | |
393 |
|
393 | |||
394 | For HTTP servers, the client sends a ``capabilities`` command request as |
|
394 | For HTTP servers, the client sends a ``capabilities`` command request as | |
395 | soon as the connection is established. The server responds with a capabilities |
|
395 | soon as the connection is established. The server responds with a capabilities | |
396 | string, which the client parses. |
|
396 | string, which the client parses. | |
397 |
|
397 | |||
398 | For SSH servers, the client sends the ``hello`` command (no arguments) |
|
398 | For SSH servers, the client sends the ``hello`` command (no arguments) | |
399 | and a ``between`` command with the ``pairs`` argument having the value |
|
399 | and a ``between`` command with the ``pairs`` argument having the value | |
400 | ``0000000000000000000000000000000000000000-0000000000000000000000000000000000000000``. |
|
400 | ``0000000000000000000000000000000000000000-0000000000000000000000000000000000000000``. | |
401 |
|
401 | |||
402 | The ``between`` command has been supported since the original Mercurial |
|
402 | The ``between`` command has been supported since the original Mercurial | |
403 | server. Requesting the empty range will return a ``\n`` string response, |
|
403 | server. Requesting the empty range will return a ``\n`` string response, | |
404 | which will be encoded as ``1\n\n`` (value length of ``1`` followed by a newline |
|
404 | which will be encoded as ``1\n\n`` (value length of ``1`` followed by a newline | |
405 | followed by the value, which happens to be a newline). |
|
405 | followed by the value, which happens to be a newline). | |
406 |
|
406 | |||
407 | The ``hello`` command was later introduced. Servers supporting it will issue |
|
407 | The ``hello`` command was later introduced. Servers supporting it will issue | |
408 | a response to that command before sending the ``1\n\n`` response to the |
|
408 | a response to that command before sending the ``1\n\n`` response to the | |
409 | ``between`` command. Servers not supporting ``hello`` will send an empty |
|
409 | ``between`` command. Servers not supporting ``hello`` will send an empty | |
410 | response (``0\n``). |
|
410 | response (``0\n``). | |
411 |
|
411 | |||
412 | In addition to the expected output from the ``hello`` and ``between`` commands, |
|
412 | In addition to the expected output from the ``hello`` and ``between`` commands, | |
413 | servers may also send other output, such as *message of the day (MOTD)* |
|
413 | servers may also send other output, such as *message of the day (MOTD)* | |
414 | announcements. Clients assume servers will send this output before the |
|
414 | announcements. Clients assume servers will send this output before the | |
415 | Mercurial server replies to the client-issued commands. So any server output |
|
415 | Mercurial server replies to the client-issued commands. So any server output | |
416 | not conforming to the expected command responses is assumed to be not related |
|
416 | not conforming to the expected command responses is assumed to be not related | |
417 | to Mercurial and can be ignored. |
|
417 | to Mercurial and can be ignored. | |
|
418 | ||||
|
419 | Commands | |||
|
420 | ======== | |||
|
421 | ||||
|
422 | This section contains a list of all wire protocol commands implemented by | |||
|
423 | the canonical Mercurial server. | |||
|
424 | ||||
|
425 | batch | |||
|
426 | ----- | |||
|
427 | ||||
|
428 | Issue multiple commands while sending a single command request. The purpose | |||
|
429 | of this command is to allow a client to issue multiple commands while avoiding | |||
|
430 | multiple round trips to the server therefore enabling commands to complete | |||
|
431 | quicker. | |||
|
432 | ||||
|
433 | The command accepts a ``cmds`` argument that contains a list of commands to | |||
|
434 | execute. | |||
|
435 | ||||
|
436 | The value of ``cmds`` is a ``;`` delimited list of strings. Each string has the | |||
|
437 | form ``<command> <arguments>``. That is, the command name followed by a space | |||
|
438 | followed by an argument string. | |||
|
439 | ||||
|
440 | The argument string is a ``,`` delimited list of ``<key>=<value>`` values | |||
|
441 | corresponding to command arguments. Both the argument name and value are | |||
|
442 | escaped using a special substitution map:: | |||
|
443 | ||||
|
444 | : -> :c | |||
|
445 | , -> :o | |||
|
446 | ; -> :s | |||
|
447 | = -> :e | |||
|
448 | ||||
|
449 | The response type for this command is ``string``. The value contains a | |||
|
450 | ``;`` delimited list of responses for each requested command. Each value | |||
|
451 | in this list is escaped using the same substitution map used for arguments. | |||
|
452 | ||||
|
453 | If an error occurs, the generic error response may be sent. | |||
|
454 | ||||
|
455 | between | |||
|
456 | ------- | |||
|
457 | ||||
|
458 | (Legacy command used for discovery in old clients) | |||
|
459 | ||||
|
460 | Obtain nodes between pairs of nodes. | |||
|
461 | ||||
|
462 | The ``pairs`` arguments contains a space-delimited list of ``-`` delimited | |||
|
463 | hex node pairs. e.g.:: | |||
|
464 | ||||
|
465 | a072279d3f7fd3a4aa7ffa1a5af8efc573e1c896-6dc58916e7c070f678682bfe404d2e2d68291a18 | |||
|
466 | ||||
|
467 | Return type is a ``string``. Value consists of lines corresponding to each | |||
|
468 | requested range. Each line contains a space-delimited list of hex nodes. | |||
|
469 | A newline ``\n`` terminates each line, including the last one. | |||
|
470 | ||||
|
471 | branchmap | |||
|
472 | --------- | |||
|
473 | ||||
|
474 | Obtain heads in named branches. | |||
|
475 | ||||
|
476 | Accepts no arguments. Return type is a ``string``. | |||
|
477 | ||||
|
478 | Return value contains lines with URL encoded branch names followed by a space | |||
|
479 | followed by a space-delimited list of hex nodes of heads on that branch. | |||
|
480 | e.g.:: | |||
|
481 | ||||
|
482 | default a072279d3f7fd3a4aa7ffa1a5af8efc573e1c896 6dc58916e7c070f678682bfe404d2e2d68291a18 | |||
|
483 | stable baae3bf31522f41dd5e6d7377d0edd8d1cf3fccc | |||
|
484 | ||||
|
485 | There is no trailing newline. | |||
|
486 | ||||
|
487 | branches | |||
|
488 | -------- | |||
|
489 | ||||
|
490 | Obtain ancestor changesets of specific nodes back to a branch point. | |||
|
491 | ||||
|
492 | Despite the name, this command has nothing to do with Mercurial named branches. | |||
|
493 | Instead, it is related to DAG branches. | |||
|
494 | ||||
|
495 | The command accepts a ``nodes`` argument, which is a string of space-delimited | |||
|
496 | hex nodes. | |||
|
497 | ||||
|
498 | For each node requested, the server will find the first ancestor node that is | |||
|
499 | a DAG root or is a merge. | |||
|
500 | ||||
|
501 | Return type is a ``string``. Return value contains lines with result data for | |||
|
502 | each requested node. Each line contains space-delimited nodes followed by a | |||
|
503 | newline (``\n``). The 4 nodes reported on each line correspond to the requested | |||
|
504 | node, the ancestor node found, and its 2 parent nodes (which may be the null | |||
|
505 | node). | |||
|
506 | ||||
|
507 | capabilities | |||
|
508 | ------------ | |||
|
509 | ||||
|
510 | Obtain the capabilities string for the repo. | |||
|
511 | ||||
|
512 | Unlike the ``hello`` command, the capabilities string is not prefixed. | |||
|
513 | There is no trailing newline. | |||
|
514 | ||||
|
515 | This command does not accept any arguments. Return type is a ``string``. | |||
|
516 | ||||
|
517 | changegroup | |||
|
518 | ----------- | |||
|
519 | ||||
|
520 | (Legacy command: use ``getbundle`` instead) | |||
|
521 | ||||
|
522 | Obtain a changegroup version 1 with data for changesets that are | |||
|
523 | descendants of client-specified changesets. | |||
|
524 | ||||
|
525 | The ``roots`` arguments contains a list of space-delimited hex nodes. | |||
|
526 | ||||
|
527 | The server responds with a changegroup version 1 containing all | |||
|
528 | changesets between the requested root/base nodes and the repo's head nodes | |||
|
529 | at the time of the request. | |||
|
530 | ||||
|
531 | The return type is a ``stream``. | |||
|
532 | ||||
|
533 | changegroupsubset | |||
|
534 | ----------------- | |||
|
535 | ||||
|
536 | (Legacy command: use ``getbundle`` instead) | |||
|
537 | ||||
|
538 | Obtain a changegroup version 1 with data for changesetsets between | |||
|
539 | client specified base and head nodes. | |||
|
540 | ||||
|
541 | The ``bases`` argument contains a list of space-delimited hex nodes. | |||
|
542 | The ``heads`` argument contains a list of space-delimited hex nodes. | |||
|
543 | ||||
|
544 | The server responds with a changegroup version 1 containing all | |||
|
545 | changesets between the requested base and head nodes at the time of the | |||
|
546 | request. | |||
|
547 | ||||
|
548 | The return type is a ``stream``. | |||
|
549 | ||||
|
550 | clonebundles | |||
|
551 | ------------ | |||
|
552 | ||||
|
553 | Obtains a manifest of bundle URLs available to seed clones. | |||
|
554 | ||||
|
555 | Each returned line contains a URL followed by metadata. See the | |||
|
556 | documentation in the ``clonebundles`` extension for more. | |||
|
557 | ||||
|
558 | The return type is a ``string``. | |||
|
559 | ||||
|
560 | getbundle | |||
|
561 | --------- | |||
|
562 | ||||
|
563 | Obtain a bundle containing repository data. | |||
|
564 | ||||
|
565 | This command accepts the following arguments: | |||
|
566 | ||||
|
567 | heads | |||
|
568 | List of space-delimited hex nodes of heads to retrieve. | |||
|
569 | common | |||
|
570 | List of space-delimited hex nodes that the client has in common with the | |||
|
571 | server. | |||
|
572 | obsmarkers | |||
|
573 | Boolean indicating whether to include obsolescence markers as part | |||
|
574 | of the response. Only works with bundle2. | |||
|
575 | bundlecaps | |||
|
576 | Comma-delimited set of strings defining client bundle capabilities. | |||
|
577 | listkeys | |||
|
578 | Comma-delimited list of strings of ``pushkey`` namespaces. For each | |||
|
579 | namespace listed, a bundle2 part will be included with the content of | |||
|
580 | that namespace. | |||
|
581 | cg | |||
|
582 | Boolean indicating whether changegroup data is requested. | |||
|
583 | cbattempted | |||
|
584 | Boolean indicating whether the client attempted to use the *clone bundles* | |||
|
585 | feature before performing this request. | |||
|
586 | ||||
|
587 | The return type on success is a ``stream`` where the value is bundle. | |||
|
588 | On the HTTP transport, the response is zlib compressed. | |||
|
589 | ||||
|
590 | If an error occurs, a generic error response can be sent. | |||
|
591 | ||||
|
592 | Unless the client sends a false value for the ``cg`` argument, the returned | |||
|
593 | bundle contains a changegroup with the nodes between the specified ``common`` | |||
|
594 | and ``heads`` nodes. Depending on the command arguments, the type and content | |||
|
595 | of the returned bundle can vary significantly. | |||
|
596 | ||||
|
597 | The default behavior is for the server to send a raw changegroup version | |||
|
598 | ``01`` response. | |||
|
599 | ||||
|
600 | If the ``bundlecaps`` provided by the client contain a value beginning | |||
|
601 | with ``HG2``, a bundle2 will be returned. The bundle2 data may contain | |||
|
602 | additional repository data, such as ``pushkey`` namespace values. | |||
|
603 | ||||
|
604 | heads | |||
|
605 | ----- | |||
|
606 | ||||
|
607 | Returns a list of space-delimited hex nodes of repository heads followed | |||
|
608 | by a newline. e.g. | |||
|
609 | ``a9eeb3adc7ddb5006c088e9eda61791c777cbf7c 31f91a3da534dc849f0d6bfc00a395a97cf218a1\n`` | |||
|
610 | ||||
|
611 | This command does not accept any arguments. The return type is a ``string``. | |||
|
612 | ||||
|
613 | hello | |||
|
614 | ----- | |||
|
615 | ||||
|
616 | Returns lines describing interesting things about the server in an RFC-822 | |||
|
617 | like format. | |||
|
618 | ||||
|
619 | Currently, the only line defines the server capabilities. It has the form:: | |||
|
620 | ||||
|
621 | capabilities: <value> | |||
|
622 | ||||
|
623 | See above for more about the capabilities string. | |||
|
624 | ||||
|
625 | SSH clients typically issue this command as soon as a connection is | |||
|
626 | established. | |||
|
627 | ||||
|
628 | This command does not accept any arguments. The return type is a ``string``. | |||
|
629 | ||||
|
630 | listkeys | |||
|
631 | -------- | |||
|
632 | ||||
|
633 | List values in a specified ``pushkey`` namespace. | |||
|
634 | ||||
|
635 | The ``namespace`` argument defines the pushkey namespace to operate on. | |||
|
636 | ||||
|
637 | The return type is a ``string``. The value is an encoded dictionary of keys. | |||
|
638 | ||||
|
639 | Key-value pairs are delimited by newlines (``\n``). Within each line, keys and | |||
|
640 | values are separated by a tab (``\t``). Keys and values are both strings. | |||
|
641 | ||||
|
642 | lookup | |||
|
643 | ------ | |||
|
644 | ||||
|
645 | Try to resolve a value to a known repository revision. | |||
|
646 | ||||
|
647 | The ``key`` argument is converted from bytes to an | |||
|
648 | ``encoding.localstr`` instance then passed into | |||
|
649 | ``localrepository.__getitem__`` in an attempt to resolve it. | |||
|
650 | ||||
|
651 | The return type is a ``string``. | |||
|
652 | ||||
|
653 | Upon successful resolution, returns ``1 <hex node>\n``. On failure, | |||
|
654 | returns ``0 <error string>\n``. e.g.:: | |||
|
655 | ||||
|
656 | 1 273ce12ad8f155317b2c078ec75a4eba507f1fba\n | |||
|
657 | ||||
|
658 | 0 unknown revision 'foo'\n | |||
|
659 | ||||
|
660 | known | |||
|
661 | ----- | |||
|
662 | ||||
|
663 | Determine whether multiple nodes are known. | |||
|
664 | ||||
|
665 | The ``nodes`` argument is a list of space-delimited hex nodes to check | |||
|
666 | for existence. | |||
|
667 | ||||
|
668 | The return type is ``string``. | |||
|
669 | ||||
|
670 | Returns a string consisting of ``0``s and ``1``s indicating whether nodes | |||
|
671 | are known. If the Nth node specified in the ``nodes`` argument is known, | |||
|
672 | a ``1`` will be returned at byte offset N. If the node isn't known, ``0`` | |||
|
673 | will be present at byte offset N. | |||
|
674 | ||||
|
675 | There is no trailing newline. | |||
|
676 | ||||
|
677 | pushkey | |||
|
678 | ------- | |||
|
679 | ||||
|
680 | Set a value using the ``pushkey`` protocol. | |||
|
681 | ||||
|
682 | Accepts arguments ``namespace``, ``key``, ``old``, and ``new``, which | |||
|
683 | correspond to the pushkey namespace to operate on, the key within that | |||
|
684 | namespace to change, the old value (which may be empty), and the new value. | |||
|
685 | All arguments are string types. | |||
|
686 | ||||
|
687 | The return type is a ``string``. The value depends on the transport protocol. | |||
|
688 | ||||
|
689 | The SSH transport sends a string encoded integer followed by a newline | |||
|
690 | (``\n``) which indicates operation result. The server may send additional | |||
|
691 | output on the ``stderr`` stream that should be displayed to the user. | |||
|
692 | ||||
|
693 | The HTTP transport sends a string encoded integer followed by a newline | |||
|
694 | followed by additional server output that should be displayed to the user. | |||
|
695 | This may include output from hooks, etc. | |||
|
696 | ||||
|
697 | The integer result varies by namespace. ``0`` means an error has occurred | |||
|
698 | and there should be additional output to display to the user. | |||
|
699 | ||||
|
700 | stream_out | |||
|
701 | ---------- | |||
|
702 | ||||
|
703 | Obtain *streaming clone* data. | |||
|
704 | ||||
|
705 | The return type is either a ``string`` or a ``stream``, depending on | |||
|
706 | whether the request was fulfilled properly. | |||
|
707 | ||||
|
708 | A return value of ``1\n`` indicates the server is not configured to serve | |||
|
709 | this data. If this is seen by the client, they may not have verified the | |||
|
710 | ``stream`` capability is set before making the request. | |||
|
711 | ||||
|
712 | A return value of ``2\n`` indicates the server was unable to lock the | |||
|
713 | repository to generate data. | |||
|
714 | ||||
|
715 | All other responses are a ``stream`` of bytes. The first line of this data | |||
|
716 | contains 2 space-delimited integers corresponding to the path count and | |||
|
717 | payload size, respectively:: | |||
|
718 | ||||
|
719 | <path count> <payload size>\n | |||
|
720 | ||||
|
721 | The ``<payload size>`` is the total size of path data: it does not include | |||
|
722 | the size of the per-path header lines. | |||
|
723 | ||||
|
724 | Following that header are ``<path count>`` entries. Each entry consists of a | |||
|
725 | line with metadata followed by raw revlog data. The line consists of:: | |||
|
726 | ||||
|
727 | <store path>\0<size>\n | |||
|
728 | ||||
|
729 | The ``<store path>`` is the encoded store path of the data that follows. | |||
|
730 | ``<size>`` is the amount of data for this store path/revlog that follows the | |||
|
731 | newline. | |||
|
732 | ||||
|
733 | There is no trailer to indicate end of data. Instead, the client should stop | |||
|
734 | reading after ``<path count>`` entries are consumed. | |||
|
735 | ||||
|
736 | unbundle | |||
|
737 | -------- | |||
|
738 | ||||
|
739 | Send a bundle containing data (usually changegroup data) to the server. | |||
|
740 | ||||
|
741 | Accepts the argument ``heads``, which is a space-delimited list of hex nodes | |||
|
742 | corresponding to server repository heads observed by the client. This is used | |||
|
743 | to detect race conditions and abort push operations before a server performs | |||
|
744 | too much work or a client transfers too much data. | |||
|
745 | ||||
|
746 | The request payload consists of a bundle to be applied to the repository, | |||
|
747 | similarly to as if :hg:`unbundle` were called. | |||
|
748 | ||||
|
749 | In most scenarios, a special ``push response`` type is returned. This type | |||
|
750 | contains an integer describing the change in heads as a result of the | |||
|
751 | operation. A value of ``0`` indicates nothing changed. ``1`` means the number | |||
|
752 | of heads remained the same. Values ``2`` and larger indicate the number of | |||
|
753 | added heads minus 1. e.g. ``3`` means 2 heads were added. Negative values | |||
|
754 | indicate the number of fewer heads, also off by 1. e.g. ``-2`` means there | |||
|
755 | is 1 fewer head. | |||
|
756 | ||||
|
757 | The encoding of the ``push response`` type varies by transport. | |||
|
758 | ||||
|
759 | For the SSH transport, this type is composed of 2 ``string`` responses: an | |||
|
760 | empty response (``0\n``) followed by the integer result value. e.g. | |||
|
761 | ``1\n2``. So the full response might be ``0\n1\n2``. | |||
|
762 | ||||
|
763 | For the HTTP transport, the response is a ``string`` type composed of an | |||
|
764 | integer result value followed by a newline (``\n``) followed by string | |||
|
765 | content holding server output that should be displayed on the client (output | |||
|
766 | hooks, etc). | |||
|
767 | ||||
|
768 | In some cases, the server may respond with a ``bundle2`` bundle. In this | |||
|
769 | case, the response type is ``stream``. For the HTTP transport, the response | |||
|
770 | is zlib compressed. | |||
|
771 | ||||
|
772 | The server may also respond with a generic error type, which contains a string | |||
|
773 | indicating the failure. |
General Comments 0
You need to be logged in to leave comments.
Login now