##// END OF EJS Templates
help: fix typo familar -> familiar
Javi Merino -
r25900:d14590f9 stable
parent child Browse files
Show More
@@ -1,174 +1,174 b''
1 1 It is common for machines (as opposed to humans) to consume Mercurial.
2 2 This help topic describes some of the considerations for interfacing
3 3 machines with Mercurial.
4 4
5 5 Choosing an Interface
6 6 =====================
7 7
8 8 Machines have a choice of several methods to interface with Mercurial.
9 9 These include:
10 10
11 11 - Executing the ``hg`` process
12 12 - Querying a HTTP server
13 13 - Calling out to a command server
14 14
15 15 Executing ``hg`` processes is very similar to how humans interact with
16 Mercurial in the shell. It should already be familar to you.
16 Mercurial in the shell. It should already be familiar to you.
17 17
18 18 :hg:`serve` can be used to start a server. By default, this will start
19 19 a "hgweb" HTTP server. This HTTP server has support for machine-readable
20 20 output, such as JSON. For more, see :hg:`help hgweb`.
21 21
22 22 :hg:`serve` can also start a "command server." Clients can connect
23 23 to this server and issue Mercurial commands over a special protocol.
24 24 For more details on the command server, including links to client
25 25 libraries, see https://mercurial.selenic.com/wiki/CommandServer.
26 26
27 27 :hg:`serve` based interfaces (the hgweb and command servers) have the
28 28 advantage over simple ``hg`` process invocations in that they are
29 29 likely more efficient. This is because there is significant overhead
30 30 to spawn new Python processes.
31 31
32 32 .. tip::
33 33
34 34 If you need to invoke several ``hg`` processes in short order and/or
35 35 performance is important to you, use of a server-based interface
36 36 is highly recommended.
37 37
38 38 Environment Variables
39 39 =====================
40 40
41 41 As documented in :hg:`help environment`, various environment variables
42 42 influence the operation of Mercurial. The following are particularly
43 43 relevant for machines consuming Mercurial:
44 44
45 45 HGPLAIN
46 46 If not set, Mercurial's output could be influenced by configuration
47 47 settings that impact its encoding, verbose mode, localization, etc.
48 48
49 49 It is highly recommended for machines to set this variable when
50 50 invoking ``hg`` processes.
51 51
52 52 HGENCODING
53 53 If not set, the locale used by Mercurial will be detected from the
54 54 environment. If the determined locale does not support display of
55 55 certain characters, Mercurial may render these character sequences
56 56 incorrectly (often by using "?" as a placeholder for invalid
57 57 characters in the current locale).
58 58
59 59 Explcitly setting this environment variable is a good practice to
60 60 guarantee consistent results. "utf-8" is a good choice on UNIX-like
61 61 environments.
62 62
63 63 HGRCPATH
64 64 If not set, Mercurial will inherit config options from config files
65 65 using the process described in :hg:`help config`. This includes
66 66 inheriting user or system-wide config files.
67 67
68 68 When utmost control over the Mercurial configuration is desired, the
69 69 value of ``HGRCPATH`` can be set to an explicit file with known good
70 70 configs. In rare cases, the value can be set to an empty file or the
71 71 null device (often ``/dev/null``) to bypass loading of any user or
72 72 system config files. Note that these approaches can have unintended
73 73 consequences, as the user and system config files often define things
74 74 like the username and extensions that may be required to interface
75 75 with a repository.
76 76
77 77 Consuming Command Output
78 78 ========================
79 79
80 80 It is common for machines to need to parse the output of Mercurial
81 81 commands for relevant data. This section describes the various
82 82 techniques for doing so.
83 83
84 84 Parsing Raw Command Output
85 85 --------------------------
86 86
87 87 Likely the simplest and most effective solution for consuming command
88 88 output is to simply invoke ``hg`` commands as you would as a user and
89 89 parse their output.
90 90
91 91 The output of many commands can easily be parsed with tools like
92 92 ``grep``, ``sed``, and ``awk``.
93 93
94 94 A potential downside with parsing command output is that the output
95 95 of commands can change when Mercurial is upgraded. While Mercurial
96 96 does generally strive for strong backwards compatibility, command
97 97 output does occasionally change. Having tests for your automated
98 98 interactions with ``hg`` commands is generally recommended, but is
99 99 even more important when raw command output parsing is involved.
100 100
101 101 Using Templates to Control Output
102 102 ---------------------------------
103 103
104 104 Many ``hg`` commands support templatized output via the
105 105 ``-T/--template`` argument. For more, see :hg:`help templates`.
106 106
107 107 Templates are useful for explicitly controlling output so that
108 108 you get exactly the data you want formatted how you want it. For
109 109 example, ``log -T {node}\n`` can be used to print a newline
110 110 delimited list of changeset nodes instead of a human-tailored
111 111 output containing authors, dates, descriptions, etc.
112 112
113 113 .. tip::
114 114
115 115 If parsing raw command output is too complicated, consider
116 116 using templates to make your life easier.
117 117
118 118 The ``-T/--template`` argument allows specifying pre-defined styles.
119 119 Mercurial ships with the machine-readable styles ``json`` and ``xml``,
120 120 which provide JSON and XML output, respectively. These are useful for
121 121 producing output that is machine readable as-is.
122 122
123 123 .. important::
124 124
125 125 The ``json`` and ``xml`` styles are considered experimental. While
126 126 they may be attractive to use for easily obtaining machine-readable
127 127 output, their behavior may change in subsequent versions.
128 128
129 129 These styles may also exhibit unexpected results when dealing with
130 130 certain encodings. Mercurial treats things like filenames as a
131 131 series of bytes and normalizing certain byte sequences to JSON
132 132 or XML with certain encoding settings can lead to surprises.
133 133
134 134 Command Server Output
135 135 ---------------------
136 136
137 137 If using the command server to interact with Mercurial, you are likely
138 138 using an existing library/API that abstracts implementation details of
139 139 the command server. If so, this interface layer may perform parsing for
140 140 you, saving you the work of implementing it yourself.
141 141
142 142 Output Verbosity
143 143 ----------------
144 144
145 145 Commands often have varying output verbosity, even when machine
146 146 readable styles are being used (e.g. ``-T json``). Adding
147 147 ``-v/--verbose`` and ``--debug`` to the command's arguments can
148 148 increase the amount of data exposed by Mercurial.
149 149
150 150 An alternate way to get the data you need is by explicitly specifying
151 151 a template.
152 152
153 153 Other Topics
154 154 ============
155 155
156 156 revsets
157 157 Revisions sets is a functional query language for selecting a set
158 158 of revisions. Think of it as SQL for Mercurial repositories. Revsets
159 159 are useful for querying repositories for specific data.
160 160
161 161 See :hg:`help revsets` for more.
162 162
163 163 share extension
164 164 The ``share`` extension provides functionality for sharing
165 165 repository data across several working copies. It can even
166 166 automatically "pool" storage for logically related repositories when
167 167 cloning.
168 168
169 169 Configuring the ``share`` extension can lead to significant resource
170 170 utilization reduction, particularly around disk space and the
171 171 network. This is especially true for continuous integration (CI)
172 172 environments.
173 173
174 174 See :hg:`help -e share` for more.
General Comments 0
You need to be logged in to leave comments. Login now