Kiln » TortoiseHg » TortoiseHg
Clone URL:  
Pushed to one repository · View In Graph Contained in 1.1, 1.1.1, and 1.1.2

doc: Add brief note about enabling the pbranch extension

Changeset 48c36a26ef3c…

Parent 7596b199b1ba…

by Peer Sommerlund

Changes to 2 files · Browse files at 48c36a26ef3c Showing diff from parent 7596b199b1ba Diff from another changeset...

Change 1 of 1 Show Entire File doc/​source/​changelog.txt Stacked
 
50
51
52
 
 
 
53
54
55
 
50
51
52
53
54
55
56
57
58
@@ -50,6 +50,9 @@
  Launch the web server dialog in a separate process   :guilabel:`Shelve`   Launch the shelve tool in a separate process + :guilabel:`Patch Branch` + Toggles the display of the Patch Branch pane. This button is only + visible when the pbranch extension has been enabled by the user.   :guilabel:`Load more`   Load the next N revisions into the graph   :guilabel:`Load all`
Change 1 of 1 Show Changes Only doc/​source/​extensions.txt Stacked
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
 **********  Extensions  **********    .. module:: extensions   :synopsis: Describe extensions bundled with TortoiseHg binary packages    This chapter describes Mercurial extensions that are shipped with  TortoiseHg binary packages for Windows. These external extensions are  included as a convenience to users, so they can be easily enabled as  soon as they are needed.    Hgfold  ======    `hgfold <http://mercurial.selenic.com/wiki/CaseFoldExtension>`_ is a  Mercurial extension that helps Windows users deal with filename case  collisions on VFAT and NTFS.    It adds options to the following Mercurial commands. Type  :command:`hg help <command>` for more information::     up - allows you to update to a revision with filename collisions   merge - allows you to merge with a changeset that would create filename collisions    The extension does not currently do anything to prevent filename  collisions. See discussion on the Mercurial Wiki    **Installation**    To test the use of this plugin, you can specify it on the Mercurial  command line like this::     hg --config "extensions.fold=" status    You may want to add it to your Mercurial.ini or a repository's hgrc like this::     [extensions]   fold=    If you do this, you can omit the --config command-line option.    **Warnings**    Like all merge operations, fold.py has to change the parents of the  working directory. It is still in early testing, so use with caution.    If you get an error about an unknown changeset after running  :command:`hg recover` try  :command:`hg debugsetparents <number of tip revision>`.  You can find the number of the tip revision by running :command:`hg log -l 2`.    Hgcr-gui  ========    `CodeReview <http://bitbucket.org/glimchb/hgcr-gui/wiki/Home>`_ management tool    * This extension allows you to manage reviews for your code in any project you like.  * It helps to keep the review management inside the mercurial.  * One can add files to the review, remove them and notify reviewr that files are ready for review.  * The reviewer can mark the code as 'completed' review cycle and return the message to the developer.  * The project manager can check the review status - which files are reviewd and which are not yet.  * The extension will automatically spot the files that were changed since their last review and notify about that.  * This extension uses GUI from TortoiseHg but also implements command line interface.  * Code review database is stored in .code-review file in your repository root directory as a map of file and revision when review was done.    **Usage**::     hg cr [OPTIONS] [FILES]     Code Review Plugin (requires Mercurial 1.3.x and TortoiseHg 0.9)     options:     -c --complete Mark CR as complete   -a --add Add files to CR list   -r --remove Remove files from CR list   -l --list Print files in CR list     use "hg -v help cr" to show global options    .. note::   To start GUI don't give any options.    **More Details**    * I've implemented the review around files and not changesets, because at the end,   I want to be able to tell for the specific project if all the files went through   code review process or not - the project status.  * Suppose you have some project that you are in charge and many developers do   write code for it. And there is a group of reviewrs that review the developers code.  * Is is very difficult to keep track of changes developers do, but simple to find   out what files have already been reviewd (by reviewers) and what were not.  * Using this extension, Developer can mark his files (when finished development   process) as "Ready for review" and send notice to reviewer.  * Reviewer will pick up the changeset (because changesets are stored in the code   review database) and perform code review (put notes inside the developer's code).  * Afterwards Reviewr will mark the files as "Review Completed" and return the   notice to the developer.  * The project manager can follow every time what is going on with his/her project.    **Installation**    You may want to add it to your Mercurial.ini or a repository's hgrc like this::     [extensions]   hgcr-gui=    Perfarce  ========    `Perfarce <http://www.kingswood-consulting.co.uk/hg/perfarce/>`_ home  page.    This extension modifies the remote repository handling so that repository  paths that resemble::     p4://p4server[:port]/clientname    cause operations on the named p4 client specification on the p4 server.  The client specification must already exist on the server before using  this extension. Making changes to the client specification Views causes  problems when synchronizing the repositories, and should be avoided.    Five built-in Mercurial commands are overridden.    outgoing::     If the destination repository name starts with p4:// then this   reports files affected by the revision(s) that are in the local   repository but not in the p4 depot.    push::     If the destination repository name starts with p4:// then this   exports changes from the local repository to the p4 depot. If no   revision is specified then all changes since the last p4 changelist   are pushed. In either case, all revisions to be pushed are foled   into a single p4 changelist. Optionally the resulting changelist is   submitted to the p4 server, controlled by the --submit option to   push, or by setting **perfarce.submit** to True. If the option   **perfarce.keep** is False then after a successful submit the files   in the p4 workarea will be deleted.    pull::     If the source repository name starts with p4:// then this imports   changes from the p4 depot, automatically creating merges of   changelists submitted by hg push. If the config option   **perfarce.keep** is False then the import does not leave files in   the p4 workarea, otherwise the p4 workarea will be updated with the   new files.    incoming::     If the source repository name starts with p4:// then this   reports changes in the p4 depot that are not yet in the local   repository.    clone::     If the source repository name starts with p4:// then this   creates the destination repository and pulls all changes from   the p4 depot into it.    **TortoiseHg Integration**    When the perfarce extension is enabled, it adds a :guilabel:`start revision`  configurable option to the clone tool, and a :guilabel:`Perforce` menu  to the Repository Explorer. The menu has two items:    identity::     Finds the tip Perforce changelist in your local repository and   selects it in the changelog window.    pending::     Detects pending Perforce changelists that have been "push"ed to your   Perforce client but have not been submitted, or have not been pulled   back. This opens the pending changelist dialog so that you can view   these pending changelists and either submit or revert them.    **Installation**    You may want to add it to your Mercurial.ini or a repository's hgrc like this::     [extensions]   perfarce=    HGEOL  =====    The hgeol extension is the eventual successor to the win32text  extension. It tries to resolve the EOLN compatibility problems in a  more complete and robust fashion. Instead of documenting it here, we  will link to it's online documents which are continually evolving.    * `EOLTranslationPlan <http://mercurial.selenic.com/wiki/EOLTranslationPlan>`_  * `Source code <http://bitbucket.org/mg/hg-eol/>`_    Mercurial-Keyring  =================    * `Mercurial Keyring <http://pypi.python.org/pypi/mercurial_keyring>`_ home page  * `Wiki page <http://mercurial.selenic.com/wiki/KeyringExtension>`_    Keyring extension uses services of the keyring library to securely save  authentication passwords (HTTP/HTTPS and SMTP) using system specific  password database (Gnome Keyring, KDE KWallet, OSXKeyChain, dedicated  solutions for Win32 and command line).    **What it does**    The extension prompts for the HTTP password on the first pull/push  to/from given remote repository (just like it is done by default), but  saves the password (keyed by the combination of username and remote  repository url) in the password database. On the next run it checks for  the username in .hg/hgrc, then for suitable password in the password  database, and uses those credentials if found.    Similarly, while sending emails via SMTP server which requires  authorization, it prompts for the password on first use of given server,  then saves it in the password database and reuses on successive runs.    In case password turns out incorrect (either because it was invalid, or  because it was changed on the server) it just prompts the user again.    **Installation**    First, the extension must be enabled in your Mercurial.ini file as::     [extensions]   mercurial_keyring=    **Password backend configuration**    The most appropriate password backend should usually be picked automatically,  without configuration. Still, if necessary, it can be configured using  ~/keyringrc.cfg file (keyringrc.cfg in the home directory of the current user).  Refer to `keyring docs <http://pypi.python.org/pypi/keyring>`_  for more details.    .. note::   On Windows XP and above, your encrypted passwords are stored in the   credentials subsystem using   `CredRead <http://msdn.microsoft.com/en-us/library/aa374804%28VS.85%29.aspx>`_ and `CredWrite <http://msdn.microsoft.com/en-us/library/aa375187%28VS.85%29.aspx>`_    .. note::   On Windows 2K, the encrypted passwords are stored in the system   registry under HKCU\\Software\\Mercurial\\Keyring.    **Repository configuration (HTTP)**    Edit repository-local .hg/hgrc and save there the remote repository path and  the username, but do not save the password. For example::     [paths]   myremote = https://my.server.com/hgrepo/someproject     [auth]   myremote.schemes = http https   myremote.prefix = my.server.com/hgrepo   myremote.username = mekk    Simpler form with url-embedded name can also be used::     [paths]   bitbucket = https://User@bitbucket.org/User/project_name/    .. note::   If both username and password are given in .hg/hgrc, extension will   use them without using the password database. If username is not   given, extension will prompt for credentials every time, also   without saving the password. So, in both cases, it is effectively   reverting to the default behaviour.    Consult `[auth] <http://www.selenic.com/mercurial/hgrc.5.html#auth>`_  section documentation for more details.    **Repository configuration (SMTP)**    Edit either repository-local .hg/hgrc, or ~/.hgrc (the latter is usually  preferable) and set there all standard email and smtp properties, including  smtp username, but without smtp password. For example::     [email]   method = smtp   from = Joe Doe <Joe.Doe@remote.com>     [smtp]   host = smtp.gmail.com   port = 587   username = JoeDoe@gmail.com   tls = true    Just as in case of HTTP, you must set username, but must not set password here  to use the extension, in other cases it will revert to the default behaviour.    **Usage**    Configure the repository as above, then just pull and push (or email) You  should be asked for the password only once (per every username +  remote_repository_url combination).    .. vim: noet ts=4 + +pbranch +======= + +Patch Branches (`pbranch <http://mercurial.selenic.com/wiki/PatchBranchExtension>`_) +is a way to develop a series of patches for submission into a main +repo. It is based on topic branches, one per patch, and is thus highly +suitable for collaborative and/or long-term patch development and +maintenance. + +'A detailed manual <http://arrenbrecht.ch/mercurial/pbranch/>'_ can be found online. + +It adds a number of commands which can be listed with +:command:`hg help pbranch`:: + + pbackout - backs out the current patch branch (undoes all its changes) + pdiff - prints the final diff for the current or given patch branch + peditmessage - edit the patch message + pemail - send patches by email + pexport - exports patches + pextdiff - combines pdiff and extdiff + pgraph - print an ASCII art rendering of the patch dependency graph + pmerge - merge pending heads from dependencies into patch branches + pmessage - print the patch message(s) + pnew - start a new patch branch + pstatus - print status of current (or given) patch branch + reapply - reverts the working copy of all files touched by REV to REV + +**Installation** + +To test the use of this plugin, you can specify it on the Mercurial +command line like this:: + + hg --config "extensions.pbranch=" pstatus + +You may want to add it to your Mercurial.ini or a repository's hgrc like this:: + + [extensions] + pbranch= + +If you do this, you can omit the --config command-line option.