| rev |
line source |
|
igor@440
|
1 \chapter{Añadir funcionalidad con extensiones}
|
|
jerojasro@336
|
2 \label{chap:hgext}
|
|
jerojasro@336
|
3
|
|
igor@451
|
4 A pesar de que el corazón de Mercurial es muy completo desde el punto
|
|
igor@451
|
5 de vista de funcionalidad, carece de características rimbombantes
|
|
igor@451
|
6 deliberadamente. Esta aproximación de preservar la simplicidad
|
|
igor@451
|
7 mantiene el programa sencillo tanto para mantenedores como para
|
|
igor@451
|
8 usuarios.
|
|
igor@451
|
9
|
|
igor@451
|
10 Si embargo Mercurial no le cierra las posibilidades a un conjunto
|
|
igor@451
|
11 inflexible de órdenes: usted puede añadir características como
|
|
igor@451
|
12 \emph{extensiones} (aveces llamadas \emph{añadidos}\ndt{plugins}). Ya
|
|
igor@451
|
13 hemos discutido algunas de estas extensiones en capítulos anteriores:
|
|
jerojasro@336
|
14 \begin{itemize}
|
|
igor@451
|
15 \item La sección~\ref{sec:tour-merge:fetch} cubre la extensión
|
|
igor@451
|
16 \hgext{fetch}; que combina jalar cambios y fusionarlos con los
|
|
igor@451
|
17 cambios locales en una sola orden: \hgxcmd{fetch}{fetch}.
|
|
igor@451
|
18 \item En el capítulo~\ref{chap:hook}, cubrimos muchas extensiones que
|
|
igor@451
|
19 son útiles en funcionalidades relacionadas con ganchos: Los
|
|
igor@451
|
20 \hgext{acl} añaden listas de control de acceso; \hgext{bugzilla}
|
|
igor@451
|
21 añade integración con el sistema de seguimiento de fallos Bugzilla; y
|
|
igor@451
|
22 \hgext{notify} envía notificaciones por correo de nuevos cambios.
|
|
igor@451
|
23 \item La extensión de administración de parches MQ es tan invaluable
|
|
igor@451
|
24 que amerita dos capítulos y un apéndice por sí misma.
|
|
igor@451
|
25 El capítulo~\ref{chap:mq} cubre lo básico; el
|
|
igor@451
|
26 capítulo~\ref{chap:mq-collab} discute temas avanzados; y el
|
|
igor@451
|
27 apéndice~\ref{chap:mqref} muestra en detalle cada orden.
|
|
jerojasro@336
|
28 \end{itemize}
|
|
jerojasro@336
|
29
|
|
igor@451
|
30 En este capítulo cubriremos algunas extensiones adicionales
|
|
igor@451
|
31 disponibles para Mercurial, y daremos un vistazo a la maquinaria que
|
|
igor@451
|
32 necesita conocer en caso de que desee escribir una extensión.
|
|
jerojasro@336
|
33 \begin{itemize}
|
|
igor@451
|
34 \item En la sección~\ref{sec:hgext:inotify}, discutiremos la
|
|
igor@451
|
35 posibilidad de mejorar el desempeño \emph{en gran medida} con la extensión
|
|
igor@451
|
36 \hgext{inotify}.
|
|
jerojasro@336
|
37 \end{itemize}
|
|
jerojasro@336
|
38
|
|
igor@451
|
39 \section{Mejorar el desempeño con la extensión \hgext{inotify}}
|
|
jerojasro@336
|
40 \label{sec:hgext:inotify}
|
|
jerojasro@336
|
41
|
|
igor@451
|
42 ¿Desea lograr que las operaciones más comunmente usadas de Mercurial se
|
|
igor@451
|
43 ejecuten centenas de veces más rápido? ¡A leer!
|
|
igor@451
|
44
|
|
igor@451
|
45 Mercurial tiene gran desempeño bajo circunstancias normales. Por
|
|
igor@451
|
46 ejemplo, cuando ejecuta la orden \hgcmd{status}, Mercurial tiene que
|
|
igor@451
|
47 revisar casi todos los ficheros y directorios en su repositorio de
|
|
igor@451
|
48 forma que pueda desplegar el estado de los ficheros. Muchas otras
|
|
igor@451
|
49 órdenes tienen que hacer tal trabajo tras bambalinas; por ejemplo la
|
|
igor@451
|
50 orden \hgcmd{diff} usa la maquinaria de estado para evitar hacer
|
|
igor@451
|
51 operaciones de comparación costosas en ficheros que obviamente no han
|
|
igor@451
|
52 cambiado.
|
|
igor@451
|
53
|
|
igor@451
|
54 Dado que obtener el estado de los ficheros es crucial para obtener
|
|
igor@451
|
55 buen desempeño, los autores de Mercurial han optimizado este código en
|
|
igor@451
|
56 la medida de lo posible. Sin embargo, no puede obviarse el hecho de
|
|
igor@451
|
57 que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo
|
|
igor@451
|
58 menos una costosa llamada al sistema por cada archivo administrado
|
|
igor@451
|
59 para determinar si ha cambiado desde la última vez que se consignó.
|
|
igor@451
|
60 Para un repositorio suficientemente grande, puede tardar bastante
|
|
igor@451
|
61 tiempo.
|
|
igor@451
|
62
|
|
igor@451
|
63 Para mostrar en números la magnitud de este efect, creé un repositorio
|
|
igor@451
|
64 que contenía 150.000 archivos administrador. Tardó diez segundos para
|
|
igor@451
|
65 ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros
|
|
igor@451
|
66 había sido modificado.
|
|
igor@451
|
67
|
|
igor@451
|
68 Muchos sistemas operativos modernos contienen una facilidad de
|
|
igor@451
|
69 notificación de archivos. Si un programa se registra con un servicio
|
|
igor@451
|
70 apropiado, el sistema operativo le notificará siempre que un fichero
|
|
igor@451
|
71 de interés haya sido creado, modificado o borrado. En sistemas Linux,
|
|
igor@451
|
72 el componente del núcleo que lo hace se llama \texttt{inotify}.
|
|
igor@451
|
73
|
|
igor@451
|
74 La extensión \hgext{inotify} habla con el componente \texttt{inotify}
|
|
igor@451
|
75 del núcleo para optimizar las órdenes de \hgcmd{status}. La extensión
|
|
igor@451
|
76 tiene dos componentes. Un daemonio está en el fondo recibiendo
|
|
igor@451
|
77 notificaciones del subsistema \texttt{inotify}. También escucha
|
|
igor@451
|
78 conexiones de una orden regular de Mercurial. La extensión modifica
|
|
igor@451
|
79 el comportamiento de Mercurial de tal forma que, en lugar de revisar
|
|
igor@451
|
80 el sistema de ficheros, le pregunta al daemonio. Dado que el daemonio
|
|
igor@451
|
81 tiene información perfecta acerca del estado del repositorio, puede
|
|
igor@451
|
82 responder instantáneamente con el resultado, evitando la necesidad de
|
|
igor@451
|
83 revisar cada directorio y fichero del repositorio.
|
|
igor@451
|
84
|
|
igor@451
|
85 Retomando los diez segundos que medí al ejecutar la orden
|
|
igor@451
|
86 \hgcmd{status} de Mercurial sobre un repositorio de 150.000
|
|
igor@451
|
87 ficheros. Con la extensión \hgext{inotify} habilitada, el tiempo se
|
|
igor@451
|
88 disipó a 0.1~seconds, un factor \emph{cien veces} más rápido.
|
|
igor@451
|
89
|
|
igor@451
|
90 Antes de continuar, tenga en cuenta algunos detalles:
|
|
jerojasro@336
|
91 \begin{itemize}
|
|
igor@451
|
92 \item La extensión \hgext{inotify} es específica de Linux. Porque se
|
|
igor@451
|
93 enlaza directamente con el subsistema \texttt{inotify} del núcleo
|
|
igor@451
|
94 Linux, no funciona en otros sistemas operativos.
|
|
igor@451
|
95 \item Debería funcionar en cualquier distribución Linux a partir de
|
|
igor@451
|
96 comienzos del 2005. Las distribuciones más antiguas deben tener un
|
|
igor@451
|
97 kernel sin \texttt{inotify}, o una versión de \texttt{glibc} que no
|
|
igor@451
|
98 tiene necesariamente el soporte para la interfaz.
|
|
igor@451
|
99 \item No todos los sistemas de ficheros pueden usarse con la extensión
|
|
igor@451
|
100 \hgext{inotify}. Los sistemas de ficheros tales como NFS no lo
|
|
igor@451
|
101 soportan, por ejemplo, si está corriendo Mercurial en vaios
|
|
igor@451
|
102 sistemas, montados todos sobre el mismo sistema de ficheros en red.
|
|
igor@451
|
103 El sistema \texttt{inotify} del kernel no tiene forma de saber
|
|
igor@451
|
104 acerca de los cambios hechos en otro sistema. La mayoría de
|
|
igor@451
|
105 sistemas de ficheros locales (p.e.~ext3, XFS, ReiserFS) deberían
|
|
igor@451
|
106 funcionar bien.
|
|
jerojasro@336
|
107 \end{itemize}
|
|
jerojasro@336
|
108
|
|
igor@451
|
109 Hacia mayo de 2007 la extensión \hgext{inotify} no venía de forma
|
|
igor@451
|
110 predeterminada en Mercurial\ndt{Desde el 2008 para kernels 2.6 viene
|
|
igor@451
|
111 en Mercurial, pero no está activada de forma predeterminada}, y es
|
|
igor@451
|
112 un poco más compleja de activar que otras extensiones. Pero la mejora
|
|
igor@451
|
113 en el desempeño bien vale la pena!
|
|
igor@451
|
114
|
|
igor@451
|
115 La extensión venía en dos partes: un conjunto de parches al código
|
|
igor@451
|
116 fuente de Mercurial, y una librería de interfaces de Python hacia el
|
|
igor@451
|
117 subsistema \texttt{inotify}.
|
|
jerojasro@336
|
118 \begin{note}
|
|
igor@451
|
119 Hay \emph{dos} librerías de enlace de Python hacia \texttt{inotify}.
|
|
igor@451
|
120 Una de ellas se llama \texttt{pyinotify}, y en algunas
|
|
igor@451
|
121 distribuciones de Linux se encuentra como \texttt{python-inotify}.
|
|
igor@451
|
122 Esta es la que \emph{no} necesita, puesto que tiene muchos fallos,
|
|
igor@451
|
123 y es ineficiente para ser práctica.
|
|
jerojasro@336
|
124 \end{note}
|
|
igor@451
|
125 Para comenzar, es mejor tener una copia de Mercurial funcional
|
|
igor@451
|
126 instalada:
|
|
jerojasro@336
|
127 \begin{note}
|
|
igor@451
|
128 Si sigue las instrucciones a continuación, estará
|
|
igor@451
|
129 \emph{reemplazando} y sobreescribiendo cualquier instalación previa
|
|
igor@451
|
130 de Mercurial que pudiera tener, con el código de Mercurial ``más
|
|
igor@451
|
131 reciente y peligrosa''. No diga que no se le advirtio!
|
|
jerojasro@336
|
132 \end{note}
|
|
jerojasro@336
|
133 \begin{enumerate}
|
|
igor@451
|
134 \item Clone el repositorio de interfaz entre Python e
|
|
igor@451
|
135 \texttt{inotify}. Ármelo e instálelo:
|
|
jerojasro@336
|
136 \begin{codesample4}
|
|
jerojasro@336
|
137 hg clone http://hg.kublai.com/python/inotify
|
|
jerojasro@336
|
138 cd inotify
|
|
jerojasro@336
|
139 python setup.py build --force
|
|
jerojasro@336
|
140 sudo python setup.py install --skip-build
|
|
jerojasro@336
|
141 \end{codesample4}
|
|
igor@451
|
142 \item Clone el repositorio \dirname{crew} de Mercurial. Clone el
|
|
igor@451
|
143 repositorio de parches de \hgext{inotify} de forma tal que las colas
|
|
igor@451
|
144 de Mercurial puedan aplicar los parches sobre el repositorio \dirname{crew}.
|
|
jerojasro@336
|
145 \begin{codesample4}
|
|
jerojasro@336
|
146 hg clone http://hg.intevation.org/mercurial/crew
|
|
jerojasro@336
|
147 hg clone crew inotify
|
|
jerojasro@336
|
148 hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
|
|
jerojasro@336
|
149 \end{codesample4}
|
|
igor@451
|
150 \item Asegúrese de instalar la extensión Colas de Mercurial
|
|
igor@451
|
151 \hgext{mq} y que estén habilitadas. Si nunca ha usado MQ, lea la
|
|
igor@451
|
152 sección~\ref{sec:mq:start} para poder comenzar rápidamente.
|
|
igor@451
|
153 \item Vaya al repositorio de \dirname{inotify} y aplique todos los
|
|
igor@451
|
154 parches de \hgext{inotify} con la opción \hgxopt{mq}{qpush}{-a} de
|
|
igor@451
|
155 la orden \hgxcmd{mq}{qpush}.
|
|
jerojasro@336
|
156 \begin{codesample4}
|
|
jerojasro@336
|
157 cd inotify
|
|
jerojasro@336
|
158 hg qpush -a
|
|
jerojasro@336
|
159 \end{codesample4}
|
|
igor@451
|
160 Si obtiene un mensaje de error de \hgxcmd{mq}{qpush}, no debería
|
|
igor@451
|
161 continuar. Mejor pida ayuda.
|
|
igor@451
|
162 \item Arme e instale la versión parchada de Mercurial.
|
|
jerojasro@336
|
163 \begin{codesample4}
|
|
jerojasro@336
|
164 python setup.py build --force
|
|
jerojasro@336
|
165 sudo python setup.py install --skip-build
|
|
jerojasro@336
|
166 \end{codesample4}
|
|
jerojasro@336
|
167 \end{enumerate}
|
|
igor@451
|
168 Una vez que haya armado una versión funcional parchada de Mercurial,
|
|
igor@451
|
169 todo lo que necesita es habilitar la extensión \hgext{inotify}
|
|
igor@451
|
170 colocando una entrada en su \hgrc.
|
|
jerojasro@336
|
171 \begin{codesample2}
|
|
jerojasro@336
|
172 [extensions]
|
|
jerojasro@336
|
173 inotify =
|
|
jerojasro@336
|
174 \end{codesample2}
|
|
igor@451
|
175 Cuando la extensión \hgext{inotify} esté habilitada, Mercurial
|
|
igor@451
|
176 iniciará transparente y automáticamente el daemonio de estado la
|
|
igor@451
|
177 primera vez que ejecute un comando que requiera estado del
|
|
igor@451
|
178 repositorio. Ejecuta un daemoniot de estado por repositorio.
|
|
igor@451
|
179
|
|
igor@451
|
180 El daemonio de estado se inicia silenciosamente y se ejecuta en el
|
|
igor@451
|
181 fondo. Si mira a la lista de procesos en ejecución después de
|
|
igor@451
|
182 habilitar la extensión \hgext{inotify} y ejecuta unos pocos comandos
|
|
igor@451
|
183 en diferentes repositorios, verá que hay algunos procesos de
|
|
igor@451
|
184 \texttt{hg} por ahí, esperando actualizaciones del kernel y
|
|
igor@451
|
185 solicitudes de Mercurial.
|
|
igor@451
|
186
|
|
igor@451
|
187 La primera vez que ejecuta un comando de Mercurial en un repositorio
|
|
igor@451
|
188 cuando tiene la extensión \hgext{inotify} habilitada, correrá casi con
|
|
igor@451
|
189 el mismo desempeño que una orden usual de Mercurial. Esto es debido a
|
|
igor@451
|
190 que el estado del daemonio necesita aplicar una búsqueda normal sobre
|
|
igor@451
|
191 el estado para poder tener una línea de partida frente a la cual
|
|
igor@451
|
192 aplicar posteriormente actualizaciones del núcleo. De todas formas,
|
|
igor@451
|
193 \emph{todo} comando posterior que haga cualquier clase de revisión del
|
|
igor@451
|
194 estado debería ser notablemente más rápido en repositorios con incluso
|
|
igor@451
|
195 un tamaño modesto. Aún mejor, a medida que su repositorio sea más
|
|
igor@451
|
196 grande, mejor desempeño verá. El daemonio \hgext{inotify} hace
|
|
igor@451
|
197 operaciones de estado de forma casi instantánea en repositorios de
|
|
igor@451
|
198 todos los tamaños!
|
|
igor@451
|
199
|
|
igor@451
|
200 Si lo desea, puede iniciar manualmente un daemonio de estado con la orden
|
|
igor@451
|
201 \hgxcmd{inotify}{inserve}. Esto le da un control un poco más fino
|
|
igor@451
|
202 acerca de cómo debería ejecutarse el daemonio. Esta orden solamente
|
|
igor@451
|
203 estará disponible cuando haya habilitado la extensión \hgext{inotify}.
|
|
igor@451
|
204
|
|
igor@451
|
205 Cuando esté usando la extensión \hgext{inotify},
|
|
igor@451
|
206 \emph{no debería ver diferencia} en el comportamiento de Mercurial,
|
|
igor@451
|
207 con la única excepción de que los comandos relacionados con el estado
|
|
igor@451
|
208 deberían ejectuarse mucho más rápido que como solían hacerlo. Debería
|
|
igor@451
|
209 esperar específicamente que las órdenes no deberían ofrecer salidas
|
|
igor@451
|
210 distintas; ni ofrecer resultados diferentes. Si alguna de estas
|
|
igor@451
|
211 situaciones ocurre, por favor reporte el fallo.
|
|
igor@451
|
212
|
|
igor@451
|
213 \section{Soporte flexible de diff con la extensión \hgext{extdiff}}
|
|
jerojasro@336
|
214 \label{sec:hgext:extdiff}
|
|
jerojasro@336
|
215
|
|
igor@451
|
216 La orden predeterminada \hgcmd{diff} de Mercurial despliega diffs en
|
|
igor@451
|
217 texto plano unificadas.
|
|
jerojasro@336
|
218 \interaction{extdiff.diff}
|
|
igor@451
|
219 Si dese emplear una herramienta externa para desplegar las
|
|
igor@451
|
220 modificaciones, querrá usar la extensión \hgext{extdiff}. Esta le
|
|
igor@451
|
221 permitirá usar por ejemplo una herramienta gráfica de diff.
|
|
igor@451
|
222
|
|
igor@451
|
223 La extensión \hgext{extdiff} viene con Mercurial, y es fácil
|
|
igor@451
|
224 configurarl. En la sección \rcsection{extensions} de su \hgrc,
|
|
igor@451
|
225 basta con añadir una entrada de una línea para habilitar la extensión.
|
|
jerojasro@336
|
226 \begin{codesample2}
|
|
jerojasro@336
|
227 [extensions]
|
|
jerojasro@336
|
228 extdiff =
|
|
jerojasro@336
|
229 \end{codesample2}
|
|
igor@451
|
230 Esto introduce una orden llamada \hgxcmd{extdiff}{extdiff}, que de
|
|
igor@451
|
231 forma predeterminada usa su orden del sistema \command{diff} para
|
|
igor@451
|
232 generar un diff unificado de la misma forma que lo hace el comando
|
|
igor@451
|
233 predeterminado \hgcmd{diff}.
|
|
jerojasro@336
|
234 \interaction{extdiff.extdiff}
|
|
igor@451
|
235 El resultado no será exactamente el mismo que con la orden interna
|
|
igor@451
|
236 \hgcmd{diff}, puesto que la salida de \command{diff} varía de un
|
|
igor@451
|
237 sistema a otro, incluso pasando las mismas opciones.
|
|
jerojasro@336
|
238
|
|
igor@453
|
239 Como lo indican las líneas``\texttt{making snapshot}'', la orden
|
|
igor@453
|
240 \hgxcmd{extdiff}{extdiff} funciona creando dos instantáneas de su
|
|
igor@453
|
241 árbol de fuentes. La primera instantánea es la revisión fuente; la
|
|
igor@453
|
242 segunda es la revisión objetivo del directorio de trabajo. La orden
|
|
igor@453
|
243 \hgxcmd{extdiff}{extdiff} genera estas instantáneas en un directorio
|
|
igor@453
|
244 temporal, pasa el nombre de cada directorio a un visor de diffs
|
|
igor@453
|
245 temporal y borra los directorios temporales. Por cuestiones de
|
|
igor@453
|
246 eficiencia solamente genera instantáneas de los directorios y ficheros
|
|
igor@453
|
247 que han cambiado entre dos revisiones.
|
|
igor@453
|
248
|
|
igor@453
|
249 Los nombres de los directorios de instantáneas tienen los mismos
|
|
igor@453
|
250 nombres base de su repositorio. Si su repositorio tiene por ruta
|
|
igor@453
|
251 \dirname{/quux/bar/foo}, \dirname{foo} será el nombre de cada
|
|
igor@453
|
252 instantánea de directorio. Cada instantánea de directorio tiene sus
|
|
igor@453
|
253 identificadores de conjuntos de cambios al final del nombre en caso de
|
|
igor@453
|
254 que sea apropiado. Si una instantánea viene de la revisión
|
|
igor@453
|
255 \texttt{a631aca1083f}, el directorio se llamará
|
|
igor@453
|
256 \dirname{foo.a631aca1083f}. Una instantánea del directorio de trabajo
|
|
igor@453
|
257 no tendrá el identificador del conjunto de cambios, y por lo tanto
|
|
igor@453
|
258 será solamente \dirname{foo} en este ejemplo. Para ver cómo luce en
|
|
igor@453
|
259 la práctica, veamos de nuevo el ejemplo \hgxcmd{extdiff}{extdiff}
|
|
igor@453
|
260 antes mencionado. Tenga en cuenta que los diffs tienen los nombres de
|
|
igor@453
|
261 las instantáneas de directorio dentro de su encabezado.
|
|
igor@453
|
262
|
|
igor@453
|
263 La orden \hgxcmd{extdiff}{extdiff} acepta dos opciones importantes.
|
|
igor@453
|
264 La opción \hgxopt{extdiff}{extdiff}{-p} le permite elegir un programa
|
|
igor@453
|
265 para ver las diferencias, en lugar de \command{diff}. Con la opción
|
|
igor@453
|
266 \hgxopt{extdiff}{extdiff}{-o} puede cambiar las opciones que
|
|
igor@453
|
267 \hgxcmd{extdiff}{extdiff} pasa a tal programa(de forma predeterminada
|
|
igor@453
|
268 las opciones son``\texttt{-Npru}'', que tienen sentido únicamente si
|
|
igor@453
|
269 está usando \command{diff}). En otros aspectos, la orden
|
|
igor@453
|
270 \hgxcmd{extdiff}{extdiff} actúa de forma similar a como lo hace la
|
|
igor@453
|
271 orden \hgcmd{diff} de Mercurial: usted usa los mismos nombres de
|
|
igor@453
|
272 opciones, sintaxis y argumentos para especificar las revisiones y los
|
|
igor@453
|
273 ficheros que quiere, y así sucesivamente.
|
|
igor@453
|
274
|
|
igor@453
|
275 Por ejemplo, para ejecutar la orden usual del sistema \command{diff},
|
|
igor@453
|
276 para lograr que se generen diferencias de contexto (con la opción
|
|
igor@453
|
277 \cmdopt{diff}{-c}) en lugar de diferencias unificadas, y cinco líneas
|
|
igor@453
|
278 de contexto en lugar de las tres predeterminadas(pasando \texttt{5}
|
|
igor@453
|
279 como argumento a la opción \cmdopt{diff}{-C}).
|
|
jerojasro@336
|
280 \interaction{extdiff.extdiff-ctx}
|
|
jerojasro@336
|
281
|
|
igor@453
|
282 Es sencillo lanzar unas herramienta usual de diferencias. Para lanzar
|
|
igor@453
|
283 el visor \command{kdiff3}:
|
|
jerojasro@336
|
284 \begin{codesample2}
|
|
jerojasro@336
|
285 hg extdiff -p kdiff3 -o ''
|
|
jerojasro@336
|
286 \end{codesample2}
|
|
jerojasro@336
|
287
|
|
igor@453
|
288 Si su orden para visualizar diferencias no puede tratar con
|
|
igor@453
|
289 directorios, puede usar un poco de scripting para lograrlo. Un
|
|
igor@453
|
290 ejemplo de un script con la extensión \hgext{mq} junto con la orden
|
|
igor@453
|
291 \command{interdiff} está en la sección~\ref{mq-collab:tips:interdiff}.
|
|
igor@453
|
292
|
|
igor@453
|
293 \subsection{Definición de alias de comandos}
|
|
jerojasro@336
|
294
|
|
igor@454
|
295 Acordarse de todas las opciones de las órdenes
|
|
igor@454
|
296 \hgxcmd{extdiff}{extdiff} y el visor de diferencias de su preferencia
|
|
igor@454
|
297 puede ser dispendioso, y por lo tanto la extensión \hgext{extdiff} le
|
|
igor@454
|
298 permite definir \emph{nuevas} órdenes que invocarán su visor de
|
|
igor@454
|
299 diferencias con las opciones exactas.
|
|
igor@454
|
300
|
|
igor@454
|
301 Basta con editar su fichero \hgrc, y añadir una sección llamada
|
|
igor@454
|
302 \rcsection{extdiff}. Dentro de esta sección puede definir varias
|
|
igor@454
|
303 órdenes. Mostraremos como añadir la orden \texttt{kdiff3}. Después de
|
|
igor@454
|
304 definido, puede teclear ``\texttt{hg kdiff3}'' y la extensión a
|
|
igor@454
|
305 \hgext{extdiff} ejecutará la orden \command{kdiff3}.
|
|
jerojasro@336
|
306 \begin{codesample2}
|
|
jerojasro@336
|
307 [extdiff]
|
|
jerojasro@336
|
308 cmd.kdiff3 =
|
|
jerojasro@336
|
309 \end{codesample2}
|
|
igor@454
|
310 Si deja vacía la porción derecha de la definición, como en el ejemplo,
|
|
igor@454
|
311 la extensión \hgext{extdiff} usa el nombre de la orden se definirá
|
|
igor@454
|
312 como el nombre del programa externo a ejecutar. Pero tales nombres no
|
|
igor@454
|
313 tienen por qué ser iguales. Definimos ahora la orden llamada
|
|
igor@454
|
314 ``\texttt{hg wibble}'', que ejecuta \command{kdiff3}.
|
|
jerojasro@336
|
315 \begin{codesample2}
|
|
jerojasro@336
|
316 [extdiff]
|
|
jerojasro@336
|
317 cmd.wibble = kdiff3
|
|
jerojasro@336
|
318 \end{codesample2}
|
|
jerojasro@336
|
319
|
|
igor@454
|
320 También puede especificar las opciones predeterminadas con las cuales
|
|
igor@454
|
321 desea invocar el visor de diferencias. Se usa el prefijo ``\texttt{opts.}'',
|
|
igor@454
|
322 seguido por el nombre de la orden a la cual se aplican las opciones.
|
|
igor@454
|
323 En este ejemplos se define la orden ``\texttt{hg vimdiff}'' que
|
|
igor@454
|
324 ejecuta la extensión \texttt{DirDiff} del editor \command{vim}.
|
|
jerojasro@336
|
325 \begin{codesample2}
|
|
jerojasro@336
|
326 [extdiff]
|
|
jerojasro@336
|
327 cmd.vimdiff = vim
|
|
jerojasro@336
|
328 opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
|
|
jerojasro@336
|
329 \end{codesample2}
|
|
jerojasro@336
|
330
|
|
igor@454
|
331 \section{Uso de la extensión \hgext{transplant} para seleccionar}
|
|
jerojasro@336
|
332 \label{sec:hgext:transplant}
|
|
jerojasro@336
|
333
|
|
jerojasro@336
|
334 Need to have a long chat with Brendan about this.
|
|
jerojasro@336
|
335
|
|
igor@454
|
336 \section{Enviar cambios vía correo electrónico con la extensión \hgext{patchbomb}}
|
|
jerojasro@336
|
337 \label{sec:hgext:patchbomb}
|
|
jerojasro@336
|
338
|
|
igor@454
|
339 Varios proyectos tienen la cultura de ``revisión de cambios'', en la
|
|
igor@454
|
340 cual la gente envía sus modificaciones a una lista de correo para que
|
|
igor@454
|
341 otros las lean y comenten antes de consignar la versión final a un
|
|
igor@454
|
342 repositorio compartido. Algunos proyectos tienen personas que actúan
|
|
igor@454
|
343 como cancerberos; ellos aplican los cambios de otras personas a un
|
|
igor@454
|
344 repositorio para aquellos que no tienen acceso.
|
|
igor@454
|
345
|
|
igor@454
|
346 Mercurial facilita enviar cambios por correo para revisión o
|
|
igor@454
|
347 aplicación gracias a su extensión \hgext{patchbomb}. La extensión es
|
|
igor@454
|
348 tan popular porque los cambios se formatean como parches y es usual
|
|
igor@454
|
349 que se envía un conjunto de cambios por cada correo. Enviar una gran
|
|
igor@454
|
350 cantidad de cambios por correos se llama por tanto ``bombardear'' el
|
|
igor@454
|
351 buzón de entrada del destinatario, de ahí su nombre ``bombardeo de
|
|
igor@454
|
352 parches''.
|
|
jerojasro@336
|
353
|
|
jerojasro@336
|
354 As usual, the basic configuration of the \hgext{patchbomb} extension
|
|
jerojasro@336
|
355 takes just one or two lines in your \hgrc.
|
|
jerojasro@336
|
356 \begin{codesample2}
|
|
jerojasro@336
|
357 [extensions]
|
|
jerojasro@336
|
358 patchbomb =
|
|
jerojasro@336
|
359 \end{codesample2}
|
|
jerojasro@336
|
360 Once you've enabled the extension, you will have a new command
|
|
jerojasro@336
|
361 available, named \hgxcmd{patchbomb}{email}.
|
|
jerojasro@336
|
362
|
|
jerojasro@336
|
363 The safest and best way to invoke the \hgxcmd{patchbomb}{email}
|
|
jerojasro@336
|
364 command is to \emph{always} run it first with the
|
|
jerojasro@336
|
365 \hgxopt{patchbomb}{email}{-n} option. This will show you what the
|
|
jerojasro@336
|
366 command \emph{would} send, without actually sending anything. Once
|
|
jerojasro@336
|
367 you've had a quick glance over the changes and verified that you are
|
|
jerojasro@336
|
368 sending the right ones, you can rerun the same command, with the
|
|
jerojasro@336
|
369 \hgxopt{patchbomb}{email}{-n} option removed.
|
|
jerojasro@336
|
370
|
|
jerojasro@336
|
371 The \hgxcmd{patchbomb}{email} command accepts the same kind of
|
|
jerojasro@336
|
372 revision syntax as every other Mercurial command. For example, this
|
|
jerojasro@336
|
373 command will send every revision between 7 and \texttt{tip},
|
|
jerojasro@336
|
374 inclusive.
|
|
jerojasro@336
|
375 \begin{codesample2}
|
|
jerojasro@336
|
376 hg email -n 7:tip
|
|
jerojasro@336
|
377 \end{codesample2}
|
|
jerojasro@336
|
378 You can also specify a \emph{repository} to compare with. If you
|
|
jerojasro@336
|
379 provide a repository but no revisions, the \hgxcmd{patchbomb}{email}
|
|
jerojasro@336
|
380 command will send all revisions in the local repository that are not
|
|
jerojasro@336
|
381 present in the remote repository. If you additionally specify
|
|
jerojasro@336
|
382 revisions or a branch name (the latter using the
|
|
jerojasro@336
|
383 \hgxopt{patchbomb}{email}{-b} option), this will constrain the
|
|
jerojasro@336
|
384 revisions sent.
|
|
jerojasro@336
|
385
|
|
jerojasro@336
|
386 It's perfectly safe to run the \hgxcmd{patchbomb}{email} command
|
|
jerojasro@336
|
387 without the names of the people you want to send to: if you do this,
|
|
jerojasro@336
|
388 it will just prompt you for those values interactively. (If you're
|
|
jerojasro@336
|
389 using a Linux or Unix-like system, you should have enhanced
|
|
jerojasro@336
|
390 \texttt{readline}-style editing capabilities when entering those
|
|
jerojasro@336
|
391 headers, too, which is useful.)
|
|
jerojasro@336
|
392
|
|
jerojasro@336
|
393 When you are sending just one revision, the \hgxcmd{patchbomb}{email}
|
|
jerojasro@336
|
394 command will by default use the first line of the changeset
|
|
jerojasro@336
|
395 description as the subject of the single email message it sends.
|
|
jerojasro@336
|
396
|
|
jerojasro@336
|
397 If you send multiple revisions, the \hgxcmd{patchbomb}{email} command
|
|
jerojasro@336
|
398 will usually send one message per changeset. It will preface the
|
|
jerojasro@336
|
399 series with an introductory message, in which you should describe the
|
|
jerojasro@336
|
400 purpose of the series of changes you're sending.
|
|
jerojasro@336
|
401
|
|
jerojasro@336
|
402 \subsection{Changing the behaviour of patchbombs}
|
|
jerojasro@336
|
403
|
|
jerojasro@336
|
404 Not every project has exactly the same conventions for sending changes
|
|
jerojasro@336
|
405 in email; the \hgext{patchbomb} extension tries to accommodate a
|
|
jerojasro@336
|
406 number of variations through command line options.
|
|
jerojasro@336
|
407 \begin{itemize}
|
|
jerojasro@336
|
408 \item You can write a subject for the introductory message on the
|
|
jerojasro@336
|
409 command line using the \hgxopt{patchbomb}{email}{-s} option. This
|
|
jerojasro@336
|
410 takes one argument, the text of the subject to use.
|
|
jerojasro@336
|
411 \item To change the email address from which the messages originate,
|
|
jerojasro@336
|
412 use the \hgxopt{patchbomb}{email}{-f} option. This takes one
|
|
jerojasro@336
|
413 argument, the email address to use.
|
|
jerojasro@336
|
414 \item The default behaviour is to send unified diffs (see
|
|
jerojasro@336
|
415 section~\ref{sec:mq:patch} for a description of the format), one per
|
|
jerojasro@336
|
416 message. You can send a binary bundle instead with the
|
|
jerojasro@336
|
417 \hgxopt{patchbomb}{email}{-b} option.
|
|
jerojasro@336
|
418 \item Unified diffs are normally prefaced with a metadata header. You
|
|
jerojasro@336
|
419 can omit this, and send unadorned diffs, with the
|
|
jerojasro@336
|
420 \hgxopt{patchbomb}{email}{--plain} option.
|
|
jerojasro@336
|
421 \item Diffs are normally sent ``inline'', in the same body part as the
|
|
jerojasro@336
|
422 description of a patch. This makes it easiest for the largest
|
|
jerojasro@336
|
423 number of readers to quote and respond to parts of a diff, as some
|
|
jerojasro@336
|
424 mail clients will only quote the first MIME body part in a message.
|
|
jerojasro@336
|
425 If you'd prefer to send the description and the diff in separate
|
|
jerojasro@336
|
426 body parts, use the \hgxopt{patchbomb}{email}{-a} option.
|
|
jerojasro@336
|
427 \item Instead of sending mail messages, you can write them to an
|
|
jerojasro@336
|
428 \texttt{mbox}-format mail folder using the
|
|
jerojasro@336
|
429 \hgxopt{patchbomb}{email}{-m} option. That option takes one
|
|
jerojasro@336
|
430 argument, the name of the file to write to.
|
|
jerojasro@336
|
431 \item If you would like to add a \command{diffstat}-format summary to
|
|
jerojasro@336
|
432 each patch, and one to the introductory message, use the
|
|
jerojasro@336
|
433 \hgxopt{patchbomb}{email}{-d} option. The \command{diffstat}
|
|
jerojasro@336
|
434 command displays a table containing the name of each file patched,
|
|
jerojasro@336
|
435 the number of lines affected, and a histogram showing how much each
|
|
jerojasro@336
|
436 file is modified. This gives readers a qualitative glance at how
|
|
jerojasro@336
|
437 complex a patch is.
|
|
jerojasro@336
|
438 \end{itemize}
|
|
jerojasro@336
|
439
|
|
jerojasro@336
|
440 %%% Local Variables:
|
|
jerojasro@336
|
441 %%% mode: latex
|
|
jerojasro@336
|
442 %%% TeX-master: "00book"
|
|
jerojasro@336
|
443 %%% End:
|
