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
|
*******
Extenze
*******
.. module:: extensions
:synopsis: Describe extensions bundled with TortoiseHg binary packages
Tato kapitola popisuje extenze Mercurialu, které jsou pro Windows dodávána s binárními balíčky TortoiseHg. Tato rozšíření jsou připojena pro pohodlí uživatelů, kteří si je mohou zpřístupnit, jakmile je potřebuji.
Hgfold
======
`hgfol <http://mercurial.selenic.com/wiki/CaseFoldExtension>`_ je rozšíření Mercurialu, které pomůže uživatelům Windows s kolizemi jmen souborů v VFAT a NTFS.
Přidá možnosti k následujícím příkazům Mercurialu. Více info viz :command:`hg help <command>`::
up - dovolí aktualizovat k revizi s kolizemi jmen souborů
merge - dovolí sloučení s changesetem, který by vytvořil kolizi jmen souborů
Extenze v současné době neumí kolizi zabránit. Viz wiki Mercurialu.
**Instalace**
Abycom si vyzkoušeli použití tohot pluginu, zadáme příkaz z příkazového řádku::
hg --config "extensions.fold=" status
Můžeme jej zaké zapsat do konfiguračního souboru Mercurial.ini nebo do souboru hgrc v repozitáři::
[extensions]
fold=
**Varování**
Jako u všech slučovacích operací musí soubor fold.py změnit rodiče pracovního adresáře. To se stále ještě zkouší a proto používat opatrně.
Dostaneme-li po běhu příkazu :command:`hg recover` chybové hlášení, vyzkoušíme příkaz :command:`hg debugsetparents <číslo revize 'tip'>`. Toto číslo zjistíme příkazem :command:`hg log`.
Hgcr-gui
========
Nástroj správy kontrol `CodeReview <http://bitbucket.org/glimchb/hgcr-gui/wiki/Home>`_
* Tato extenze umožňuje správu kontrol našeho kódu v libovolném projektu.
* Pomáhá udržet správu kontrol uvnitř Mercurialu
* Do kontrolovaného přehledu lze přidávat i odebírat soubory
* Kontrolor může označit kód jako kompletně zkontrolvaný a vrátit zprávu vývojáři.
* Projektový manažer může zkontrolat stav kontroly - které soubory jsou zkontrolované a které nikoliv.
* Extenze okamžitě zjistí soubory změněné po kontrole a podá o tom zprávu.
* Tato extenze používá GUI z TortoiseHg ale také využívá rozhranní příkazového řádku.
* Databáze kontroly kódu je po kontrole uložena v souboru .code-review v kořenovém adresáři repozitáře.
**Použití**::
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::
Pro spuštění GUI nezadáváme žádné možnosti.
**Další podrobnosti**
* 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.
**Instalace**
Chceme-li tuto extenzi použít, doplníme konfigurační soubory
/mercurial.ini meb /hgrc like takto::
[extensions]
hgcr-gui=
Perfarce
========
`Perfarce <http://www.kingswood-consulting.co.uk/hg/perfarce/>`_ home
page.
Tato extenze je dokumentována `jinde <nonhg.html#perfarce>`_.
HGEOL
=====
Extenze hgeol je případným nástupce extenze win32text. Pokouší se řešit kompabilitní problémy EOLN kompletnějším a robustnějším způsobem. Místo popisu na tomto místě uvedeme odkazy na onlinovou dokumentaci, která se neustále vyvíjí.
* `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
* `Keyring Extension <http://mercurial.selenic.com/wiki/KeyringExtension>`_ wiki page
Extenze keyring používají své knihovny pro bezpečné uložení hesel (HTTP/HTTPS a SMTP) s použitím určité databáze (Gnome Keyring, KDE KWallet, OSXKeyChain, zaměřená řešení pro Win32 a příkazový řádek).
**Co se provádí**
Při první akci pull/push do/z daného vzdáleného repozitáře požádá extenze o heslo HTTP a uloží jej (zadané v kombinaci jména uživatele a URL vzdáleného repozitáře) do databáze hesel. Při další akci hledá jméno uživatele v .hg/hgrc a heslo v databázi a tyto důvěrné údaje použje, pokud je nalezne.
Podobně při posílání e-mailu přes SMTP server, který vyžaduje autorizaci, požádá o zadání hesla při prvním použití serveru, uloží jej do databáze a při dalších použitích jej opět použije.
Stane-li se heslo nesprávné (protože bylo neplatné, nebo že bylo změněno), je uživatel požádán o zadání hesla znovu.
**Instalace**
Nejprve musí být umožněna extenze v souboru Mercurial.ini::
[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.
.. vim: noet ts=4
|
