rev |
line source |
igor@440
|
1 \chapter{Administración de cambios con Colas de Mercurial}
|
jerojasro@336
|
2 \label{chap:mq}
|
jerojasro@336
|
3
|
igor@440
|
4 \section{El problema de la administración de parches}
|
jerojasro@336
|
5 \label{sec:mq:patch-mgmt}
|
jerojasro@336
|
6
|
igor@443
|
7 Un escenario frecuente: usted necesita instalar un paquete de software
|
igor@443
|
8 desde las fuentes, pero encuentra un fallo que debe arreglar antes de
|
igor@443
|
9 poder comenzar a usarlo. Hace sus cambios, y se olvida del paquete
|
igor@443
|
10 por un tiempo, unos meses después necesita actualizar a una nueva
|
igor@443
|
11 versión del paquete. Si la nueva versión del paquete todavía tiene el
|
igor@443
|
12 fallo, debe extraer su arreglo del árbol de fuentes anteriores y
|
igor@443
|
13 aplicarlo a la nueva versión. Una tarea tediosa en la cual es fácil
|
igor@443
|
14 equivocarse.
|
igor@443
|
15
|
igor@443
|
16 Este es un caso simple del problema del ``manejo de parches''. Usted
|
igor@443
|
17 tiene un árbol de fuentes del ``mantenedor principal'' que no puede
|
igor@443
|
18 cambiar: necesita hacer algunos cambios locales sobre el árbol
|
igor@443
|
19 principal; y desearía poder mantener tales cambios separados, de forma
|
igor@443
|
20 tal que pueda aplicarlos a versiones más nuevas del árbol principal.
|
igor@443
|
21
|
igor@443
|
22 El problema de administración de parches surge en muchas situaciones.
|
igor@443
|
23 Probablemente la más visible es cuando un usuario de un proyecto de
|
igor@443
|
24 software de fuentes abiertas contribuye con un arreglo de un fallo o
|
igor@443
|
25 una nueva característica a los mantenedores del proyecto en la forma
|
igor@443
|
26 de un parche.
|
igor@443
|
27
|
igor@443
|
28 Aquellos que distribuyen sistemas operativos que incluyen programas
|
igor@443
|
29 abiertos usualmente requieren hacer cambios en los paquetes que
|
igor@443
|
30 distribuyen de tal forma que se armen apropiadamente en sus ambientes.
|
igor@443
|
31
|
igor@443
|
32 Cuando hay pocos cambios por mantener, es muy sencillo administrar un
|
igor@443
|
33 solo parche con los programas estándar \command{diff} y
|
jerojasro@480
|
34 \command{patch} (ver la sección~\ref{sec:mq:patch} para ver cómo
|
igor@443
|
35 emplear tales herramientas). Cuando la cantidad de cambios comienza a
|
igor@443
|
36 crecer, tiene sentido mantener parches como ``porciones de trabajo''
|
igor@443
|
37 individual, de forma que cada cambio contiene solamente un arreglo de
|
jerojasro@480
|
38 un fallo (el parche puede modificar varios ficheros, pero está
|
igor@443
|
39 ``haciendo una sola cosa''), y puede tener cierta cantidad de tales
|
igor@443
|
40 parches para diferentes fallos y cambios locales. En esta situación,
|
igor@443
|
41 si envía un parche que arregla un fallo a los mantenedores principales
|
igor@443
|
42 de un paquete y ellos incluyen su arreglo en una publicación
|
igor@443
|
43 posterior, puede deshacerse de tal parche cuando se actualice a la
|
igor@443
|
44 nueva versión.
|
igor@443
|
45
|
igor@443
|
46 Mantener un solo parche frente a un árbol principal es algo tedioso y
|
igor@443
|
47 es fácil equivocarse, pero no es difícil. Aunque, la complejidad del
|
igor@443
|
48 problema crece rápidamente a medida que la cantidad de parches que
|
igor@443
|
49 tiene que mantener crece. Con más que una pequeña cantidad de
|
igor@443
|
50 cambios, entender cuáles ha aplicado se convierte de algo desordenado
|
igor@443
|
51 a algo avasallante.
|
igor@443
|
52
|
igor@443
|
53 Afortunadamente Mercurial provee una extensión poderos: Colas de
|
jerojasro@480
|
54 Mercurial (o simplemente ``MQ''), que simplifica en gran medida el
|
igor@443
|
55 problema de administración de parches.
|
igor@443
|
56
|
igor@443
|
57 \section{La prehistoria de las Colas de Mercurial}
|
jerojasro@336
|
58 \label{sec:mq:history}
|
jerojasro@336
|
59
|
igor@443
|
60 A finales de los 90s, muchos desarrolladores del núcleo de Linux
|
igor@443
|
61 comenzaron a mantener ``series de parches'' que modificaron el
|
igor@443
|
62 comportamiento del núcleo de Linux. Algunos se enfocaban en
|
igor@443
|
63 estabilidad, otros en aumentar las características, y otros un poco
|
igor@443
|
64 más especulativos.
|
igor@443
|
65
|
igor@443
|
66 Los tamaños de las series de parches crecieron rápidamente. En el
|
igor@443
|
67 2002, Andrew Morton publicó algunos guiones de línea de órdenes que
|
igor@443
|
68 estuvo usando para automatizar la tarea de administrar su cola de
|
igor@443
|
69 parches. Andrew usó exitósamente tales guiones para administrar
|
jerojasro@480
|
70 centenas (a veces millares) de parches en el núcleo de Linux.
|
igor@443
|
71
|
igor@443
|
72 \subsection{Trabajar parches con quilt}
|
jerojasro@336
|
73 \label{sec:mq:quilt}
|
jerojasro@336
|
74
|
igor@443
|
75 A comienzos del 2003, Andreas Gruenbacher y Martin Quinson tomaron la
|
igor@443
|
76 aproximación de los guiones de Andrew y publicaron una herramienta
|
igor@443
|
77 llamada
|
igor@443
|
78 ``patchwork quilt''~\cite{web:quilt}, o simplemente ``quilt''
|
igor@443
|
79 (ver~\cite{gruenbacher:2005} el paper que lo describe). Dado que
|
igor@443
|
80 quilt automatizaba sustancialmente la administración de parches, fue
|
igor@443
|
81 adoptado en gran medida por desarrolladores de programas abiertos.
|
igor@443
|
82
|
igor@443
|
83 Quilt maneja una \emph{pila de parches} sobre un árbol de directorios.
|
igor@443
|
84 Para comenzar, usted le indica a quilt que administre un árbol de
|
igor@449
|
85 directorios, le indica qué ficheros manejar; Este almacena los nombres
|
igor@449
|
86 y los contenidos de estos ficheros. Para arreglar un fallo, usted
|
jerojasro@480
|
87 crea un nuevo parche (con una sola orden), edita los ficheros que está
|
igor@443
|
88 arreglando y ``refresca'' el parche.
|
igor@443
|
89
|
igor@443
|
90 El paso de refresco hace que quilt revise el árbol de directorios;
|
igor@443
|
91 actualiza el parche con todos los cambios que usted haya hecho. Puede
|
igor@443
|
92 crear otro parche sobre el primero, que hará seguimiento de los
|
igor@443
|
93 cambios requeridos para modificar el árbol desde ``el árbol con un
|
igor@443
|
94 parch aplicado'' a un ``árbol con dos parches aplicados''.
|
igor@443
|
95
|
igor@443
|
96 Usted puede \emph{elegir} qué cambios desea aplicar al árbol. Si
|
igor@443
|
97 ``pop''\ndt{saca} un parche, los cambios hechos por tal parchve
|
igor@443
|
98 desapareceŕan del árbol de directorios. Quilt recuerda qué parches ha
|
igor@443
|
99 sacado, para que pueda ``introducirlos''\ndt{push} posteriormente, así el
|
igor@443
|
100 árbol de directorios se restaurará con las modificaciones que vienen
|
igor@443
|
101 del parche. Lo más importante es que puede ejecutar la orden
|
igor@443
|
102 ``refresh'' en cualquier momento, y el último parche será
|
igor@443
|
103 actualizado. Esto significa que puede, en cualquier momento, cambiar
|
igor@443
|
104 qué parches serán aplicados y qué modificaciones hacen ellos.
|
igor@443
|
105
|
igor@443
|
106 Quilt no tiene nada que ver con herramientas de control de versiones,
|
igor@443
|
107 y puede trabajar bien sobre un conjunto de fuentes que viene de un
|
igor@449
|
108 fichero comprimido y empaquetado o una copia de trabajo de Subversion.
|
igor@443
|
109
|
igor@443
|
110 \subsection{Pasar de trabajo con parches con Quilt hacia Colas de Mercurial}
|
jerojasro@336
|
111 \label{sec:mq:quilt-mq}
|
jerojasro@336
|
112
|
igor@443
|
113 A mediados de 2005, Chris Mason tomó las características de quilt y
|
igor@443
|
114 escribió una extensión que llamó Colas de Mercurial\ndt{Mercurial
|
igor@443
|
115 Queues}, que proporcionó un comportamiento a Mercurial al estilo
|
igor@443
|
116 quilt.
|
igor@443
|
117
|
igor@443
|
118 La diferencia clave entre quilt y MQ es que quilt no sabe nada acerca
|
igor@443
|
119 del sistema de control de revisiones, mientras que MQ está
|
igor@443
|
120 \emph{integrado} con Mercurial. Cada parche que usted introduce se
|
igor@443
|
121 representa como un conjunto de cambios en Mercurial. Si sustrae un
|
igor@443
|
122 parche, el conjunto de cambios desaparece.\ndt{introduce originalmente es
|
igor@443
|
123 push y pop es sustraer en este contexto, usaremos el original en inglés
|
igor@443
|
124 cuando encontremos que facilita la comprensión}
|
igor@443
|
125
|
igor@443
|
126 Dado que quilt no se preocupa por las herramientas de control de
|
igor@443
|
127 revisiones, continúa siendo una porción de software tremendamente útil
|
igor@443
|
128 para aquellas situaciones en las cuales no puede usar Mercurial y MQ.
|
igor@443
|
129
|
igor@443
|
130 \section{La gran ventaja de MQ}
|
igor@443
|
131
|
igor@443
|
132 No puedo sobreestimar el valor que MQ ofrece en la unificación de
|
igor@443
|
133 parches y el control de revisiones.
|
igor@443
|
134
|
igor@443
|
135 La principal razón por la cual los parches han persistido en el mundo
|
igor@443
|
136 del software libre y de fuentes abiertas--a pesar de la creciente
|
igor@443
|
137 disponibilidad de herramientas poderosas de control de revisiones-- es
|
igor@443
|
138 la \emph{agilidad} que ofrecen.
|
igor@443
|
139
|
igor@443
|
140 Las herramientas tradicionales de control de revisiones llevan un
|
igor@443
|
141 registro permanente e irreversible de todo lo que usted hace. A pesar
|
igor@443
|
142 de que esto tiene gran valor, también es bastante sutil. Si requiere
|
igor@443
|
143 realizar un experimento ((((wild-eyed)))), debe ser cuidadoso en cómo
|
igor@443
|
144 lo hace, o puede dejar trazas innecesarias--o peor aún,
|
igor@443
|
145 desconcertantes o desestabilizantes--- de los pasos y errores en el
|
igor@443
|
146 registro de revisiones de forma permanente.
|
igor@443
|
147
|
igor@443
|
148 En contraste, con la cohesión de MQ con el control de revisiones
|
igor@443
|
149 distribuidos y los parches, resulta más sencillo aislar su trabajo.
|
jerojasro@517
|
150 Sus parches viven encima del historial de revisiones normales, y
|
igor@443
|
151 puede hacer que ellos desaparezcan o reaparezcan cuando lo desee. Si
|
igor@443
|
152 no le gusta un parche, puede desecharlo. Si un parche no satisface
|
igor@443
|
153 todo lo que usted desea, puede arreglarlo---tantas veces como lo
|
igor@443
|
154 requiera, hasta que lo haya refinado lo suficiente hacia sus
|
igor@443
|
155 expectativas.
|
igor@443
|
156
|
igor@443
|
157 Por ejemplo, la integración de parches con el control de revisiones
|
igor@443
|
158 hace que el entender los parches y revisar sus efectos---y sus
|
igor@443
|
159 interacciones con el código en el cuál están enlazados--- sea
|
igor@443
|
160 \emph{mucho} más sencillo. Dado que todo parche que se aplique tiene
|
igor@443
|
161 un conjunto de cambios asociado, puede usar
|
igor@443
|
162 \hgcmdargs{log}{\emph{filename}} para ver qué conjuntos de cambios y
|
igor@443
|
163 parches afectaron un fichero. Puede usar la orden \hgext{bisect} para
|
igor@443
|
164 hacer una búsqueda binaria sobre todos los conjuntos de cambios y
|
igor@443
|
165 parches aplicados para ver dónde se introdujo un fallo o dónde fue
|
igor@443
|
166 arreglado. Puede usar la orden \hgcmd{annotate} para ver qué
|
igor@443
|
167 conjuntos de cambios o parches modificaron una línea particular de un
|
igor@449
|
168 fichero fuente. Y mucho más.
|
igor@443
|
169
|
igor@443
|
170 \section{Entender los parches}
|
jerojasro@336
|
171 \label{sec:mq:patch}
|
jerojasro@336
|
172
|
igor@443
|
173 Dado que MQ no esconde su naturaleza parche-céntrica, es muy útil para
|
igor@443
|
174 entender de qué se tratan los parches, y un poco acerca de las
|
igor@443
|
175 herramientas que trabajan con ellos.
|
igor@443
|
176
|
igor@443
|
177 La orden de Unix tradicional \command{diff} compara dos ficheros, e
|
igor@443
|
178 imprime una lista de diferencias de sus líneas. La orden
|
igor@443
|
179 \command{patch} entiende esas diferencias como \emph{modificaciones}
|
igor@443
|
180 para construir un fichero. Vea en la figura~\ref{ex:mq:diff} un
|
igor@443
|
181 ejemplo sencillo de tales órdenes en acción.
|
jerojasro@336
|
182
|
jerojasro@336
|
183 \begin{figure}[ht]
|
jerojasro@336
|
184 \interaction{mq.dodiff.diff}
|
igor@443
|
185 \caption{Uso sencillo de las órdenes \command{diff} y \command{patch}}
|
jerojasro@336
|
186 \label{ex:mq:diff}
|
jerojasro@336
|
187 \end{figure}
|
jerojasro@336
|
188
|
igor@443
|
189 El tipo de fichero que \command{diff} genera (y que \command{patch}
|
igor@443
|
190 toma como entrada) se llama un ``parche'' o un ``diff''; no hay
|
igor@443
|
191 diferencia entre un parche y un diff. (Usaremos el término ``parche'',
|
igor@443
|
192 dado que es el que más comunmente se usa.)
|
igor@443
|
193
|
igor@443
|
194 Un parche puede comenzar con un texto arbitrario; la orden \command{patch}
|
igor@443
|
195 ignora este texto, pero MQ lo usa como el mensaje de consignación
|
igor@443
|
196 cuando se crean conjuntos de cambios. Para encontrar el inicio del
|
igor@443
|
197 contenido de un parche, la orden \command{patch} busca la primera
|
igor@443
|
198 línea que comience con la cadena ``\texttt{diff~-}''.
|
igor@443
|
199
|
igor@443
|
200 MQ trabaja con diffs \emph{unificados} (\command{patch} acepta varios
|
igor@443
|
201 formatos de diff adicionales, pero MQ no). Un diff unificado contiene
|
igor@443
|
202 dos clases de encabezados. El \emph{encabezado de fichero} describe
|
igor@443
|
203 el fichero que se está modificando; contiene el nombre del fichero a
|
igor@443
|
204 modificar. Cuando \command{patch} ve un nuevo encabezado de fichero,
|
igor@443
|
205 busca un fichero con ese nombre para modificarlo.
|
igor@443
|
206
|
igor@443
|
207 Después del encabezaado vienen varios \emph{trozos}. Cada trozo
|
igor@443
|
208 comienza con un encabezado; que identifica el rango de líneas del
|
igor@443
|
209 fichero que el trozo debe modificar. Después del encabezado, un trozo
|
jerojasro@480
|
210 comienza y termina con unas pocas líneas (usualmente tres) de texto del
|
igor@443
|
211 fichero que no han sido modificadas; las cuales llamamos el
|
igor@443
|
212 \emph{contexto} del trozo. Si solamente hay una pequeña cantidad de
|
igor@443
|
213 contexto entre trozos sucesivos, \command{diff} no imprime un nuevo
|
igor@443
|
214 encabezado para el trozo, continua integrando los trozos, con unas
|
igor@443
|
215 líneas de contexto entre las modificaciones.
|
igor@443
|
216
|
igor@443
|
217 Cada línea de contexto comienza con un caracter de espacio. En el
|
igor@443
|
218 trozo, si una línea comienza con ``\texttt{-}'' significa ``elimine
|
igor@443
|
219 esta línea'', si la línea comienza con un ``\texttt{+}'' significa
|
igor@443
|
220 ``inserte esta línea''. Por ejemplo, una línea que se modifica se
|
igor@443
|
221 representa con una línea eliminada y una línea insertada.
|
igor@443
|
222
|
jerojasro@480
|
223 Retomaremos aspectos más sutiles acerca de parches posteriormente (en
|
igor@443
|
224 la sección~\ref{sec:mq:adv-patch}), pero en el momento usted ya
|
igor@443
|
225 debería tener suficiente información para usar MQ.
|
igor@443
|
226
|
igor@443
|
227 \section{Comenzar a usar Colas de Mercurial}
|
jerojasro@336
|
228 \label{sec:mq:start}
|
jerojasro@336
|
229
|
igor@443
|
230 Dado que MQ está implementado como una extensión, debe habilitarla
|
igor@443
|
231 explícitamente antes de comenzar a usarla. (No necesita descargar
|
igor@443
|
232 nada; MQ viene con la distribución estándar de Mercurial.) Para
|
igor@443
|
233 habilitar MQ, edite su fichero \tildefile{.hgrc}, y añada las líneas
|
igor@443
|
234 de la figura~\ref{ex:mq:config}.
|
jerojasro@336
|
235
|
jerojasro@336
|
236 \begin{figure}[ht]
|
jerojasro@336
|
237 \begin{codesample4}
|
jerojasro@336
|
238 [extensions]
|
jerojasro@336
|
239 hgext.mq =
|
jerojasro@336
|
240 \end{codesample4}
|
jerojasro@336
|
241 \label{ex:mq:config}
|
igor@443
|
242 \caption{Líneas a añadir en \tildefile{.hgrc} para habilitar la extensión MQ}
|
igor@443
|
243 \end{figure}
|
igor@443
|
244
|
igor@443
|
245 Cuando la extensión esté habilitada, aparecerán varios comandos. Para
|
igor@443
|
246 verificar que la extensión está trabajando, puede usar \hgcmd{help}
|
igor@443
|
247 para ver si la orden \hgxcmd{mq}{qinit} está disponible; vea un
|
igor@443
|
248 ejemplo en la figura~\ref{ex:mq:enabled}.
|
jerojasro@336
|
249
|
jerojasro@336
|
250 \begin{figure}[ht]
|
jerojasro@336
|
251 \interaction{mq.qinit-help.help}
|
igor@443
|
252 \caption{Cómo verificar que MQ está habilitado}
|
jerojasro@336
|
253 \label{ex:mq:enabled}
|
jerojasro@336
|
254 \end{figure}
|
jerojasro@336
|
255
|
igor@443
|
256 Puede usar MQ en \emph{cualquier} repositorio de Mercurial, y sus
|
igor@443
|
257 comandos solamente operarán con tal repositorio. Para comenzar, basta
|
jerojasro@480
|
258 con preparar el repositorio con la orden \hgxcmd{mq}{qinit} (ver la
|
igor@443
|
259 figura~\ref{ex:mq:qinit}). Esta orden crea un directorio vacío
|
igor@443
|
260 llamado \sdirname{.hg/patches}, donde MQ mantendrá sus metadatos. Como
|
igor@443
|
261 otras ordenes de Mercurial, la orden \hgxcmd{mq}{qinit} no imprime
|
igor@443
|
262 nada cuando es exitosa.
|
jerojasro@336
|
263
|
jerojasro@336
|
264 \begin{figure}[ht]
|
jerojasro@336
|
265 \interaction{mq.tutorial.qinit}
|
igor@443
|
266 \caption{Preparar un repositorio para usar MQ}
|
jerojasro@336
|
267 \label{ex:mq:qinit}
|
jerojasro@336
|
268 \end{figure}
|
jerojasro@336
|
269
|
jerojasro@336
|
270 \begin{figure}[ht]
|
jerojasro@336
|
271 \interaction{mq.tutorial.qnew}
|
igor@443
|
272 \caption{Crear un nuevo parche}
|
jerojasro@336
|
273 \label{ex:mq:qnew}
|
jerojasro@336
|
274 \end{figure}
|
jerojasro@336
|
275
|
igor@443
|
276 \subsection{Crear un nuevo parche}
|
igor@443
|
277
|
igor@443
|
278 Para comenzar a trabajar en un nuevo parche use la orden
|
igor@443
|
279 \hgxcmd{mq}{qnew}. Esta orden recibe un argumento, el nombre del
|
igor@443
|
280 parche a crear. MQ lo usará como el nombre del fichero en el
|
igor@443
|
281 directorio \sdirname{.hg/patches}, como puede apreciarlo en la
|
igor@443
|
282 figura~\ref{ex:mq:qnew}.
|
igor@443
|
283
|
igor@443
|
284 También hay otros dos nuevos ficheros en el directorio
|
igor@443
|
285 \sdirname{.hg/patches}: \sfilename{series} y \sfilename{status}. El
|
igor@443
|
286 fichero \sfilename{series} lista todos los parches de los cuales MQ
|
igor@443
|
287 tiene noticia para este repositorio, con un parche por línea.
|
igor@443
|
288 Mercurial usa el fichero \sfilename{status} para mantener registros
|
igor@443
|
289 interns; da seguimiento a todos los parches que MQ ha \emph{aplicado}
|
igor@443
|
290 en el repositorio.
|
jerojasro@336
|
291
|
jerojasro@336
|
292 \begin{note}
|
igor@443
|
293 En ciertas ocasiones usted querrá editar el fichero
|
igor@443
|
294 \sfilename{series} a mano; por ejemplo, cambiar el orden en que se
|
igor@443
|
295 aplican ciertos parches. A pesar de esto, es una mala idea editar
|
igor@443
|
296 manualmente el fichero \sfilename{status}, dado que es fácil
|
igor@443
|
297 desorientar a MQ acerca de lo que está pasando.
|
jerojasro@336
|
298 \end{note}
|
jerojasro@336
|
299
|
igor@443
|
300 Una vez que haya creado un nuevo parche, puede editar los ficheros en
|
igor@443
|
301 el directorio de trabajo, como lo haría usualmente. Toda las órdenes
|
igor@443
|
302 que de a Mercurial, tales como \hgcmd{diff} y \hgcmd{annotate},
|
igor@443
|
303 trabajarán de la misma forma como lo han hecho antes.
|
igor@443
|
304
|
igor@443
|
305 \subsection{Refrescar un parche}
|
igor@443
|
306
|
igor@443
|
307 Cuando usted llega a un punto en el cual desea guardar su trabajo, use
|
jerojasro@480
|
308 la orden \hgxcmd{mq}{qrefresh} (figura~\ref{ex:mq:qnew}) para
|
igor@443
|
309 actualizar el parche en el cual está trabajando. Esta orden almacena
|
igor@443
|
310 los cambios que haya hecho al directorio actual de trabajo en su
|
igor@443
|
311 parche, y almacena el conjunto de cambios correspondiente que contiene
|
igor@443
|
312 los cambios.
|
jerojasro@336
|
313
|
jerojasro@336
|
314 \begin{figure}[ht]
|
jerojasro@336
|
315 \interaction{mq.tutorial.qrefresh}
|
igor@443
|
316 \caption{Refrescar un parche}
|
jerojasro@336
|
317 \label{ex:mq:qrefresh}
|
jerojasro@336
|
318 \end{figure}
|
jerojasro@336
|
319
|
igor@443
|
320 Puede ejecutar la orden \hgxcmd{mq}{qrefresh} tan seguido como quiera,
|
igor@443
|
321 y es una buena forma de ``colocar marcas'' a su trabajo. Refresque su
|
igor@443
|
322 parche en momentos oportunos; intente un experimento; si el
|
igor@443
|
323 experimento no funciona, Use \hgcmd{revert} sobre sus modificaciones
|
igor@443
|
324 para volver al refresco anterior.
|
jerojasro@336
|
325
|
jerojasro@336
|
326 \begin{figure}[ht]
|
jerojasro@336
|
327 \interaction{mq.tutorial.qrefresh2}
|
igor@443
|
328 \caption{Refrescar un parche muchas veces para acumular cambios}
|
jerojasro@336
|
329 \label{ex:mq:qrefresh2}
|
jerojasro@336
|
330 \end{figure}
|
jerojasro@336
|
331
|
igor@443
|
332 \subsection{Aplicar un parche tras otro y dar seguimiento}
|
igor@443
|
333
|
igor@443
|
334 Cuando haya terminado de trabajar en un parche, o necesite trabajar en
|
igor@443
|
335 otro, puede usar la orden \hgxcmd{mq}{qnew} para crear un nuevo
|
igor@443
|
336 parche. Mercurial aplicará este parche sobre su parche anterior.
|
igor@443
|
337 Para un ejemplo, ver la figura~\ref{ex:mq:qnew2}. Note que el parche
|
igor@443
|
338 contiene los cambios en nuestro parche anterior como parte de su
|
jerojasro@480
|
339 contexto (lo verá más claramente en la salida de \hgcmd{annotate}).
|
jerojasro@336
|
340
|
jerojasro@336
|
341 \begin{figure}[ht]
|
jerojasro@336
|
342 \interaction{mq.tutorial.qnew2}
|
igor@443
|
343 \caption{Aplicar un parche después del primero}
|
jerojasro@336
|
344 \label{ex:mq:qnew2}
|
jerojasro@336
|
345 \end{figure}
|
jerojasro@336
|
346
|
igor@443
|
347 Hasta ahora, con excepción de \hgxcmd{mq}{qnew} y
|
igor@443
|
348 \hgxcmd{mq}{qrefresh}, hemos sido cuidadosos para aplicar únicamente
|
igor@443
|
349 órdenes usuaales de Mercurial. De todas maneras, MQ ofrece muchos
|
igor@443
|
350 comandos que son más sencillos de usar cuando esté pensando acerca de
|
igor@443
|
351 parches, como se puede ver en la figura~\ref{ex:mq:qseries}:
|
jerojasro@336
|
352
|
jerojasro@336
|
353 \begin{itemize}
|
igor@443
|
354 \item La orden \hgxcmd{mq}{qseries} lista cada parche del cual MQ
|
igor@443
|
355 tiene noticia en este repositorio, desde el más antiguo hasta el más
|
jerojasro@480
|
356 nuevo (El último \emph{creado}).
|
igor@443
|
357 \item La orden \hgxcmd{mq}{qapplied} lista cada parche que MQ haya
|
igor@443
|
358 \emph{aplicado} en este repositorio, de nuevo, desde el más antiguo
|
igor@443
|
359 hasta el más nuevo (El aplicado más recientemente).
|
jerojasro@336
|
360 \end{itemize}
|
jerojasro@336
|
361
|
jerojasro@336
|
362 \begin{figure}[ht]
|
jerojasro@336
|
363 \interaction{mq.tutorial.qseries}
|
igor@443
|
364 \caption{Entender la pila de parches con \hgxcmd{mq}{qseries} y
|
jerojasro@336
|
365 \hgxcmd{mq}{qapplied}}
|
jerojasro@336
|
366 \label{ex:mq:qseries}
|
jerojasro@336
|
367 \end{figure}
|
jerojasro@336
|
368
|
igor@443
|
369 \subsection{Manipular la pila de parches}
|
igor@443
|
370
|
igor@443
|
371 La discusión previa indicó que debe haber una diferencia entre los
|
igor@443
|
372 parches ``conocidos'' y ``aplicados'', y efectivamente la hay. MQ
|
igor@443
|
373 puede manejar un parche sin que este haya sido aplicado al
|
igor@443
|
374 repositorio.
|
igor@443
|
375
|
igor@443
|
376 Un parche \emph{aplicado} tiene su correspondiente conjunto de cambios
|
igor@443
|
377 en el repositorio, y los efectos del parche y el conjunto de cambios
|
igor@443
|
378 son visibles en el directorio de trabajo. Puede deshacer la
|
igor@443
|
379 aplicación de un parche con la orden \hgxcmd{mq}{qpop}. MQ
|
igor@443
|
380 \emph{sabe acerca de}, o maneja un parche sustraído, pero el parche ya
|
igor@443
|
381 no tendrá un conjunto de cambios correspondientes en el repositorio, y
|
igor@443
|
382 el directorio de trabajo no contendrá los cambios hechos por el
|
igor@443
|
383 parche. La figura~\ref{fig:mq:stack} ilustra la diferencia entre
|
igor@443
|
384 parches aplicados y seguidos.
|
jerojasro@336
|
385
|
jerojasro@336
|
386 \begin{figure}[ht]
|
jerojasro@336
|
387 \centering
|
jerojasro@336
|
388 \grafix{mq-stack}
|
igor@443
|
389 \caption{Parches aplicados y no aplicados en la pila de parches de MQ}
|
jerojasro@336
|
390 \label{fig:mq:stack}
|
jerojasro@336
|
391 \end{figure}
|
jerojasro@336
|
392
|
igor@443
|
393 Puede reaplicar un parche no aplicado o sustraído con la orden
|
igor@443
|
394 \hgxcmd{mq}{qpush}. Esto crea un nuevo conjunto de cambios
|
igor@443
|
395 correspondiente al parche, y los cambios del parche estarán presentes
|
igor@443
|
396 de nuevo en el directorio de trabajo. Vea ejemplos de
|
igor@443
|
397 \hgxcmd{mq}{qpop} y \hgxcmd{mq}{qpush} en acción en la
|
igor@443
|
398 figura~\ref{ex:mq:qpop}. Vea que hemos sustraído uno o dos parches,
|
igor@443
|
399 la salida de\hgxcmd{mq}{qseries} continúa igual, mientras que
|
igor@443
|
400 \hgxcmd{mq}{qapplied} ha cambiado.
|
jerojasro@336
|
401
|
jerojasro@336
|
402 \begin{figure}[ht]
|
jerojasro@336
|
403 \interaction{mq.tutorial.qpop}
|
igor@443
|
404 \caption{Modificar la pila de parches aplicados}
|
jerojasro@336
|
405 \label{ex:mq:qpop}
|
jerojasro@336
|
406 \end{figure}
|
jerojasro@336
|
407
|
igor@443
|
408 \subsection{Introducir y sustraer muchos parches}
|
igor@443
|
409
|
igor@443
|
410 Mientras que \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} operan sobre un
|
igor@443
|
411 único parche cada vez, puede introducir y sustraer varios parches de
|
igor@443
|
412 una vez. La opción \hgxopt{mq}{qpush}{-a} de \hgxcmd{mq}{qpush}
|
igor@443
|
413 introduce todos los cambios que no hayan sido aplicados, mientras que
|
igor@443
|
414 la opción \hgxopt{mq}{qpop}{-a} de \hgxcmd{mq}{qpop} sustrae todos los
|
igor@443
|
415 cambios aplicados. (Vea la sección~\ref{sec:mq:perf} más adelante
|
igor@443
|
416 en la cual se explican otras formas de de introducir y sustraer varios
|
igor@443
|
417 cambios.)
|
jerojasro@336
|
418
|
jerojasro@336
|
419 \begin{figure}[ht]
|
jerojasro@336
|
420 \interaction{mq.tutorial.qpush-a}
|
jerojasro@336
|
421 \caption{Pushing all unapplied patches}
|
jerojasro@336
|
422 \label{ex:mq:qpush-a}
|
jerojasro@336
|
423 \end{figure}
|
jerojasro@336
|
424
|
igor@443
|
425 \subsection{Medidas de seguridad y cómo saltarlas}
|
igor@443
|
426
|
igor@443
|
427 Muchas órdenes MQ revisan el directorio de trabajo antes de hacer
|
igor@443
|
428 cualquier cosa, y fallan si encuentran alguna modificación. Lo hacen
|
igor@443
|
429 para garantizar que usted no pierda cambio alguno de los que haya
|
igor@443
|
430 hecho, pero que no hayan sido incorporados en algún parche. La
|
igor@443
|
431 figura~\ref{ex:mq:add} ilusta esto; la orden \hgxcmd{mq}{qnew} no
|
igor@443
|
432 creará un nuevo parche si hay cambios notorios, causados en este caso
|
igor@443
|
433 por aplicado la orden \hgcmd{add} a \filename{file3}.
|
jerojasro@336
|
434
|
jerojasro@336
|
435 \begin{figure}[ht]
|
jerojasro@336
|
436 \interaction{mq.tutorial.add}
|
igor@443
|
437 \caption{Crear un parche a la fuerza}
|
jerojasro@336
|
438 \label{ex:mq:add}
|
jerojasro@336
|
439 \end{figure}
|
jerojasro@336
|
440
|
igor@443
|
441 Las órdenes que revisan el directorio actual cuentan con una opción
|
igor@443
|
442 ``Se lo que estoy haciendo'', que siempre está nombrada como
|
igor@443
|
443 \option{-f}. El significado exacto de \option{-f} depende de la
|
igor@443
|
444 orden. Por ejemplo, \hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}}
|
igor@443
|
445 incorporarán cualquier cambio notorio en el nuevo parche que crea pero
|
igor@443
|
446 \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} revertirá las modificaciones a
|
igor@443
|
447 cualquier fichero que haya sido afectado por el parche que está siendo
|
igor@443
|
448 sustraído. ¡Asegúrese de leer la documentación de la opción \option{-f}
|
igor@443
|
449 de cada comando antes de usarla!
|
igor@443
|
450
|
igor@443
|
451 \subsection{Trabajar con varios parches a la vez}
|
igor@443
|
452
|
igor@443
|
453 La orden \hgxcmd{mq}{qrefresh} siempre refresca el \emph{último}
|
igor@443
|
454 parche aplicado. Esto significa que usted puede suspender su trabajo
|
igor@443
|
455 en un parche (refrescándolo), sustraerlo o introducirlo para lograr
|
igor@443
|
456 que otro parche esté de último y trabajar en \emph{ese} parche por un
|
igor@443
|
457 rato.
|
igor@443
|
458
|
igor@443
|
459 A continuación un ejemplo que ilustra cómo puede usar esta habilidad.
|
igor@443
|
460 Digamos que está desarrollando una nueva característica en dos
|
igor@443
|
461 parches. El primero es un cambio en la parte fundamental de su
|
igor@443
|
462 programa, y el segundo--sobre el primero---cambia la interfaz de
|
igor@443
|
463 usuario para usar el código que ha añadido a la parte fundamental. Si
|
igor@443
|
464 ve que hay un fallo en la parte fundamental mientras está trabajando
|
igor@443
|
465 en el parche de UI\ndt{Interfaz de Usuario, User Interface en inglés}, es fácil arreglar la parte fundamental.
|
igor@443
|
466 Simplemente use \hgxcmd{mq}{qrefresh} sobre el parche de la UI para
|
igor@443
|
467 guardar los cambios de su trabajo en progreso, y use \hgxcmd{mq}{qpop}
|
igor@443
|
468 para sacar sustraer el parche de la parte fundamental. Arregla el
|
igor@443
|
469 fallo sobre la parte fundamental, aplique \hgxcmd{mq}{qrefresh} sobre
|
igor@443
|
470 el parche fundamental, y aplique \hgxcmd{mq}{qpush} sobre el parche de
|
igor@443
|
471 UI para continuar donde había quedado.
|
jerojasro@336
|
472
|
igor@444
|
473 \section{Más acerca de parches}
|
jerojasro@336
|
474 \label{sec:mq:adv-patch}
|
jerojasro@336
|
475
|
igor@444
|
476 MQ usa la orden GNU \command{patch} para aplicar los parches, por lo
|
igor@444
|
477 tanto es útil conocer ciertos detalles de cómo trabaja
|
igor@444
|
478 \command{patch}, y también acerca de los parches.
|
igor@444
|
479
|
igor@444
|
480 \subsection{La cantidad de franjas}
|
igor@444
|
481
|
igor@449
|
482 Si ve el encabezado de un parche, notará que la ruta al fichero tiene
|
igor@444
|
483 un componente adicional al principio, que no está presente en la
|
igor@444
|
484 ruta. Esta es una traza de cómo generaba anteriormente los parches la
|
jerojasro@480
|
485 gente (algunos aún lo hacen, pero es raro con las herramientas de
|
igor@444
|
486 control de revisiones del actuales).
|
igor@444
|
487
|
igor@449
|
488 Alicia desempaquetaría un comprimido, editaría sus ficheros, y querría
|
igor@444
|
489 crear un parche. Por lo tanto ella renombraría su directorio de
|
jerojasro@520
|
490 trabajo, desempacaría el comprimido de nuevo (para lo cual necesitó el
|
igor@444
|
491 renombramiento), y usaría las opciones \cmdopt{diff}{-r} y
|
igor@444
|
492 \cmdopt{diff}{-N} de \command{diff} para generar recursivamente un
|
igor@444
|
493 parche entre el directorio original y el modificado. El resultado
|
igor@444
|
494 sería que el nombre del directorio original estaría al principio de
|
igor@444
|
495 toda ruta en cada encabezado de fichero, y el nombre del directorio
|
igor@444
|
496 modificado estaría al frente de la porción derecha de la ruta del
|
igor@449
|
497 fichero.
|
jerojasro@336
|
498
|
igor@446
|
499 Como alguien que reciba un parche de Alicia en la red podría obtener
|
igor@446
|
500 dos directorios, uno original y el otro modificado con exactamente los
|
igor@446
|
501 mismos nombres, la orden \command{patch} tiene la opción
|
igor@446
|
502 \cmdopt{patch}{-p} que indica la cantidad de componentes de la ruta
|
igor@446
|
503 a eliminar cuando se vaya a aplicar el parche. Este número se
|
igor@446
|
504 llama la \emph{cantidad de eliminaciones}.
|
igor@446
|
505
|
igor@446
|
506 La opción con ``\texttt{-p1}'' significa ``elimine uno''. Si
|
igor@446
|
507 \command{patch} ve un nombre de fichero \filename{foo/bar/baz} en el
|
igor@446
|
508 encabezado del fichero, eliminará \filename{foo} y tratará de parchar
|
igor@446
|
509 un fichero llamado \filename{bar/baz}. (Hablando estrictamente, la
|
igor@446
|
510 cantidad de eliminaciones se refiere a la cantidad de \emph{separadores de
|
igor@446
|
511 ruta} (y los componentes que vayan con ellos) a eliminar. Si el
|
igor@446
|
512 contador es uno volverá \filename{foo/bar} en \filename{bar}, pero
|
igor@446
|
513 \filename{/foo/bar} (note la barra extra) en \filename{foo/bar}.)
|
igor@446
|
514
|
igor@446
|
515 La cantidad a eliminar``estándar'' para parches es uno; casi todos los
|
igor@446
|
516 parches contienen un componente inicial de la ruta que necesita ser
|
igor@446
|
517 eliminado. La orden \hgcmd{diff} de Mercurial genera nombres de ruta
|
igor@446
|
518 de esta forma, y la orden \hgcmd{import} y MQ esperan parches que
|
igor@446
|
519 tengan a uno como cuenta de eliminaciones.
|
igor@446
|
520
|
igor@446
|
521 Si recibe un parche de alguien de quien desea adicionar adicionar a su
|
igor@446
|
522 cola de parches, y el parche necesita una cuenta de eliminación que no
|
igor@446
|
523 sea uno, no podrá aplicar \hgxcmd{mq}{qimport} en primera medida,
|
igor@446
|
524 porque \hgxcmd{mq}{qimport} no tiene todavía una opción \texttt{-p}
|
igor@446
|
525 option (ver~\bug{311}). Lo mejor que puede hacer es aplicar
|
igor@446
|
526 \hgxcmd{mq}{qnew} por su cuenta, y después usar \cmdargs{patch}{-p\emph{N}}
|
igor@446
|
527 para aplicar tal parche, seguido de \hgcmd{addremove} para tener en
|
igor@446
|
528 cuenta cualquier fichero adicionado o eliminado por el parche, seguido
|
igor@446
|
529 de \hgxcmd{mq}{qrefresh}. Esta complejidad puede ser innecesaria;
|
igor@446
|
530 consulte~\bug{311} para más información.
|
igor@446
|
531
|
igor@446
|
532 \subsection{Estrategias para aplicar parches}
|
igor@446
|
533
|
igor@446
|
534 Cuando \command{patch} aplica un trozo, intenta varias estrategias
|
igor@446
|
535 sucesivas que decrecen en precisión para intentar aplicarlo. Esta
|
igor@446
|
536 técnica de pruebas y error aveces permite que un parche que fue
|
igor@446
|
537 generado contra una versión anterior de un fichero, sea aplicada sobre
|
igor@446
|
538 una versión más nueva del mismo.
|
igor@446
|
539
|
igor@446
|
540 Primero \command{patch} intenta una correspondencia perfecta donde los
|
igor@446
|
541 números de línea, el contexto y el texto a modificar deben coincidir
|
igor@446
|
542 perfectamente. Si no lo logra, intenta encontrar una correspondencia
|
igor@446
|
543 exacta del contexto, sin tener en cuenta el número de línea. Si es
|
igor@446
|
544 exitoso, imprime una línea indicando que el trozo fue aplicado, pero a
|
igor@446
|
545 un \emph{corrimiento} del número de línea original.
|
igor@446
|
546
|
igor@446
|
547 Si falla la correspondencia por contexto, \command{patch} elimina la
|
igor@446
|
548 primera y la última línea del contexto, e intenta una correspondencia
|
igor@446
|
549 \emph{reducida} del contexto. Si el trozo con contexto reducido es
|
igor@446
|
550 exitoso, imprime un mensaje indicando que aplicó el trozo con un
|
igor@446
|
551 \emph{factor difuso} (el número después del factor difuso indica
|
igor@446
|
552 cuántas líneas de contexto \command{patch} tuvo que eliminar antes de
|
igor@446
|
553 aplicar el parche).
|
igor@446
|
554
|
igor@446
|
555 Cuando ninguna de estas técnicas funciona, \command{patch} imprime un
|
igor@446
|
556 mensaje indicando que el trozo en cuestión se desechó. Almacena los
|
jerojasro@480
|
557 trozos desechados (también llamados ``descartados'') en un fichero con
|
igor@446
|
558 el mismo nombre, y la extensión \sfilename{.rej} añadida. También
|
igor@446
|
559 almacena una copia igual al fichero original con la extensión
|
igor@446
|
560 \sfilename{.orig}; la copia del fichero sin extensión contendrá
|
igor@446
|
561 cualquier cambio hecho por los trozos que \emph{sí} se aplicaron sin
|
igor@446
|
562 problema. Si usted tiene un parche que modifica \filename{foo} con
|
igor@446
|
563 seis trozos, y uno de ellos falla al aplicarse, tendrá : un fichero
|
igor@446
|
564 original \filename{foo.orig}, un fichero \filename{foo.rej} que
|
igor@446
|
565 contiene el trozo, y \filename{foo}, que contiene los cambios que se
|
igor@446
|
566 aplicaron por los cinco trozos exitosos.
|
igor@446
|
567
|
igor@446
|
568 \subsection{Algunos detalles de la representación de parches}
|
igor@446
|
569
|
igor@446
|
570 Hay ciertas cosas útiles por saber acerca de cómo trabaja
|
igor@446
|
571 \command{patch} con los ficheros:
|
jerojasro@336
|
572 \begin{itemize}
|
igor@446
|
573 \item Debería ser obvio que \command{patch} no puede manipular
|
igor@446
|
574 ficheros binarios.
|
igor@446
|
575 \item No se preocupa por el bit ejecutable; crea ficheros nuevos en
|
igor@446
|
576 modo lectura, pero no ejecutable.
|
igor@446
|
577 \item \command{patch} intenta eliminar un fichero como una diferencia
|
igor@446
|
578 entre el fichero a eliminar y un fichero vacío. Y por lo tanto su
|
igor@446
|
579 idea de ``Borré este fichero'' debería pensarse como ``toda línea de
|
igor@446
|
580 este fichero fue eliminada'' en un parche.
|
igor@446
|
581 \item Trata la adición de un fichero como un diff entre un fichero
|
igor@446
|
582 vacío y el fichero a ser adicionado. Por lo tanto en un parche su
|
igor@446
|
583 idea de ``Añadí este fichero'' se vería como ``toda línea de este
|
igor@446
|
584 fichero fue añadida''.
|
igor@446
|
585 \item Trata el renombramiento de un fichero como la eliminación del
|
igor@446
|
586 nombre anterior y la adición del nuevo nombre. Esto significa que
|
igor@446
|
587 los ficheros renombrados dejan un rastro grande en los parches.
|
igor@446
|
588 (Tenga en cuenta que Mercurial no trata de inferir cuando los
|
igor@449
|
589 ficheros han sido renombrados o copiados en un parche en este
|
igor@446
|
590 momento.)
|
igor@446
|
591 \item \command{patch} no puede representar ficheros vacíos, por lo
|
igor@446
|
592 tanto no puede usar un parche para representar la noción ``Añadí
|
igor@446
|
593 este fichero vacío al árbol''.
|
jerojasro@336
|
594 \end{itemize}
|
igor@446
|
595 \subsection{Cuidado con los difusos}
|
jerojasro@336
|
596
|
igor@447
|
597 Cuando aplique un trozo con un corrimiento, o con un factor difuso,
|
igor@447
|
598 aveces será taotalmente exitoso, tales técnicas inexactas dejan
|
igor@449
|
599 claramente la posibilidad de corromper el fichero parchado. Los casos
|
igor@447
|
600 más típicos involucran aplicar un parche dos veces o en un sitio
|
igor@447
|
601 incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan
|
igor@447
|
602 a mencionar un corrimiento o un factor difuso, debería asegurarse que
|
igor@447
|
603 los ficheros modificados estén correctos después del suceso.
|
igor@447
|
604
|
igor@447
|
605 Casi siempre es buena idea refrescar un parche que fue aplicado con un
|
igor@447
|
606 corrimiento o un factor difuso; refrescar el parche genera nueva
|
igor@447
|
607 información de contexto que permitirá aplicarlo limpiamente. Digo
|
igor@447
|
608 ``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones
|
igor@447
|
609 refrescar un parche lo hará fallar frente a una revisión diferente del
|
igor@447
|
610 fichero. En algunos casos, como por ejemplo, cuando usted está
|
igor@447
|
611 manteniendo un parche que debe estar encima de múltiples revisiones de
|
igor@447
|
612 un árbol de fuentes, es aceptable tener un parche aplicado algo
|
igor@447
|
613 difuso, siempre que haya verificado los resultados del proceso de
|
igor@447
|
614 parchar.
|
igor@447
|
615
|
igor@447
|
616 \subsection{Manejo de descartes}
|
igor@447
|
617
|
igor@447
|
618 Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de
|
igor@447
|
619 error y saldrá. Si ha dejado ficheros \sfilename{.rej}, es mejor
|
igor@447
|
620 arreglar los trozos descartados antes de introducir parches
|
igor@447
|
621 adicionales o hacer cualquier otra cosa.
|
igor@447
|
622
|
igor@447
|
623 Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace
|
igor@447
|
624 porque ha cambiado código subyacente en el cual se basa su parche, las
|
igor@447
|
625 Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}.
|
igor@447
|
626
|
igor@447
|
627 Desafortunadamente, no hay grandes técnicas para tratar los trozos
|
igor@447
|
628 descartados. Casi siempre deberá consultar el fichero
|
igor@447
|
629 \sfilename{.rej} y editar el fichero objetivo, aplicando los trozos
|
igor@447
|
630 descartados a mano.
|
igor@447
|
631
|
igor@447
|
632 Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una
|
igor@447
|
633 herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más
|
igor@447
|
634 vigorosa que \command{patch} en su intento de hacer que se aplique un
|
igor@447
|
635 parche.
|
igor@447
|
636
|
igor@447
|
637 Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de
|
igor@447
|
638 Mercurial), escribió una herramienta similar llamada
|
igor@447
|
639 \command{mpatch}~\cite{web:mpatch}, que sigue una aproximación
|
igor@447
|
640 sencilla para automatizar la aplicación de trozos descartados por
|
igor@447
|
641 \command{patch}. La orden \command{mpatch} puede ayudar con cuatro
|
igor@447
|
642 razones comunes por las cuales un parche ha sido descartado:
|
jerojasro@336
|
643
|
jerojasro@336
|
644 \begin{itemize}
|
igor@447
|
645 \item El contexto en la mitad de un trozo ha cambiado.
|
igor@447
|
646 \item Un trozo ha perdido cierto contexto al principio o al final.
|
igor@447
|
647 \item Un trozo largo podría aplicarse mejor---por completo o una
|
igor@447
|
648 parte---si estaba cortado en trozos más pequeños.
|
igor@447
|
649 \item Un trozo remueve líneas con contenido ligeramente diferente que
|
igor@447
|
650 aquellas que están presentes en el fichero.
|
jerojasro@336
|
651 \end{itemize}
|
jerojasro@336
|
652
|
igor@447
|
653 Si usted usa \command{wiggle} o \command{mpatch}, debería ser
|
igor@447
|
654 doblemente cuidadoso al revisar sus resultados cuando haya terminado.
|
igor@447
|
655 De hecho, \command{mpatch} refuerza este método de revisar por partida
|
igor@447
|
656 doble su salida, dejándolo a usted en un programa de fusión cuando la
|
igor@447
|
657 herramienta haya terminado su trabajo, de tal forma que usted pueda
|
igor@447
|
658 verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión
|
igor@447
|
659 faltante.
|
igor@447
|
660
|
igor@449
|
661 \section{maximizar el rendimiento de MQ}
|
jerojasro@336
|
662 \label{sec:mq:perf}
|
jerojasro@336
|
663
|
igor@447
|
664 MQ es muy eficiente al tratar con una gran cantidad de parches. Corrí
|
igor@447
|
665 unos experimentos de desempeño a mediados del 2006 para una charla que
|
igor@447
|
666 dí en la conferencia EuroPython 2006~\cite{web:europython}. Empleé la
|
igor@447
|
667 serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738
|
igor@447
|
668 parches. Los apliqué sobre un repositorio del núcleo de Linux con
|
igor@447
|
669 todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17.
|
igor@447
|
670
|
igor@448
|
671 En mi portátil antiguo y lento, logré aplicar
|
igor@447
|
672 \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5
|
igor@447
|
673 minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos.
|
igor@447
|
674 (En un portátil más nuevo, el tiempo para introducir todos los
|
igor@447
|
675 parches, se logró en menos de dos minutos.) Apliqué
|
jerojasro@480
|
676 \hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes (que hizo
|
igor@447
|
677 22.779 líneas de cambios en 287 ficheros) en 6,6 segundos.
|
igor@447
|
678
|
igor@447
|
679 Claramente, MQ funciona adecuadamente en árboles grandes, y además hay
|
igor@447
|
680 unos trucos que pueden emplearse para obtener el máximo desempeño.
|
igor@447
|
681
|
igor@447
|
682 En primer lugar, trate de hacer ``en lote'' las operaciones. Cada vez
|
igor@447
|
683 que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes
|
igor@447
|
684 revisan el directorio de trabajo para asegurarse de que usted no ha
|
igor@447
|
685 hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}. En un
|
igor@447
|
686 árbol pequeño, el tiempo de esta revisión puede ser mínimo, Pero en
|
jerojasro@480
|
687 un árbol mediano (con decenas de miles de ficheros), puede tomar un
|
igor@447
|
688 segundo o más.
|
igor@447
|
689
|
igor@447
|
690 Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten
|
igor@447
|
691 introducir o sustraer varios parches en una operación. Puede
|
igor@447
|
692 identificar el ``parche destino'' que desee. Cuando aplique
|
igor@447
|
693 \hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea
|
igor@447
|
694 necesario hasta que el especificado esté en el tope de la pila.
|
igor@447
|
695 Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches
|
igor@447
|
696 hasta que el parche destino esté en el tope.
|
igor@447
|
697
|
igor@447
|
698 Puede identificar un parche destino con el nombre del parche o con el
|
igor@447
|
699 número. Si se refiere al número, los parches se contarán desde cero;
|
igor@447
|
700 esto significa que el primer parche es cero, el segundo es uno y así
|
igor@447
|
701 sucesivamente.
|
jerojasro@336
|
702
|
igor@448
|
703 \section{Actualiar los parches cuando el código cambia}
|
jerojasro@336
|
704 \label{sec:mq:merge}
|
jerojasro@336
|
705
|
igor@448
|
706 Es común contar con una pila de parches sobre un repositorio que usted
|
igor@448
|
707 no modifica directamente. Si está trabajando en cambios de código de
|
igor@448
|
708 otros, o en una característica que tarda bastante en desarrollarse
|
igor@448
|
709 comparada con la tasa de cambio del código sobre la cual se está
|
igor@448
|
710 trabajando, necesitará sincronizarse con el código, y ajustar
|
igor@448
|
711 cualquier trozo en sus parches que ya no estén al día. A esto se le
|
igor@448
|
712 llama hacer \emph{rebase} a su serie de parches.
|
igor@448
|
713
|
igor@448
|
714 La vía más sencilla de hacerlo es con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}}
|
igor@448
|
715 sobre sus parches, después hacer \hgcmd{pull} de los cambios en el
|
igor@448
|
716 repositorio, y finalmente hacer
|
igor@448
|
717 \hgcmdargs{qpush}{\hgxopt{mq}{qpop}{-a}} con sus parches de nuevo. MQ
|
igor@448
|
718 dejará de de introducir parches siempre que llegue a un parche que no se pueda
|
igor@448
|
719 aplicar debido a un conflicto, permitiéndole a usted arreglarlo,
|
igor@448
|
720 aplicar \hgxcmd{mq}{qrefresh} al parche afectado y continuar
|
igor@448
|
721 introduciendo hasta que haya arreglado la pila completa.
|
igor@448
|
722
|
igor@448
|
723 Esta aproximación es sencilla y funciona bien si no espera cambios en
|
igor@448
|
724 el código original que afecte en gran medida los parches que usted
|
igor@448
|
725 esté aplicando. Si su pila de parches toca código que es modificado
|
igor@448
|
726 frecuentemente o de forma invasiva sobre el código subyacente,
|
igor@448
|
727 arreglar trozos manualmente se vuelve desgastante.
|
igor@448
|
728
|
igor@448
|
729 Es posible automatizar de forma parcial el proceso de rebase. Si sus
|
igor@448
|
730 parches se aplican limpiamente sobre algunas revisiones del
|
igor@448
|
731 repositorio subyacente, MQ puede usar esta información para ayudarle a
|
igor@448
|
732 a resolver conflictos entre sus parches y una revisión distinta.
|
igor@448
|
733
|
igor@448
|
734 El proceso resulta un poco complejo:
|
jerojasro@336
|
735 \begin{enumerate}
|
igor@448
|
736 \item Para comenzar, haga \hgcmdargs{qpush}{-a} sobre todos los
|
igor@448
|
737 parches que usted sepa se aplican limpiamente.
|
igor@448
|
738 \item Guarde una copia de seguridad de su directorio de parches con
|
igor@448
|
739 \hgcmdargs{qsave}{\hgxopt{mq}{qsave}{-e} \hgxopt{mq}{qsave}{-c}}.
|
igor@448
|
740 Esto imprime el nombre del directorio en el cual se han guardado los
|
igor@448
|
741 parches. Guardará los parches en un directorio llamado
|
igor@448
|
742 \sdirname{.hg/patches.\emph{N}}, donde \texttt{\emph{N}} es un
|
igor@448
|
743 entero pequeño. También consigna un ``conjunto de cambios de
|
igor@448
|
744 seguridad'' sobre sus parches aplicados; esto es para mantener el
|
igor@448
|
745 histórico, y guarda los estados de los ficheros \sfilename{series}
|
igor@448
|
746 y \sfilename{status}.
|
igor@448
|
747 \item Use \hgcmd{pull} para traer los nuevos cambios en el repositorio
|
igor@448
|
748 subyacente. (No ejecute \hgcmdargs{pull}{-u}; vea más adelante por qué.)
|
igor@448
|
749 \item Actualice a la nueva revisión punta con
|
igor@448
|
750 \hgcmdargs{update}{\hgopt{update}{-C}} para sobreescribir los
|
igor@448
|
751 parches que haya introducido.
|
igor@448
|
752 \item Fusione todos los parches con \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}
|
igor@448
|
753 \hgxopt{mq}{qpush}{-a}}. La opción \hgxopt{mq}{qpush}{-m} de \hgxcmd{mq}{qpush}
|
igor@448
|
754 le indica a MQ que haga una fusión que involucra tres fuentes si el
|
igor@448
|
755 parche falla al aplicarse.
|
jerojasro@336
|
756 \end{enumerate}
|
jerojasro@336
|
757
|
igor@448
|
758 Durante el \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}}, cada parche en
|
igor@448
|
759 el fichero \sfilename{series} se aplica normalmente. Si un parche se
|
igor@448
|
760 aplica difusamente o se niea a aplicarse, MQ consulta la cola que
|
igor@448
|
761 usted guardó con \hgxcmd{mq}{qsave}, y aplica una fusión de tres con
|
igor@448
|
762 el correspondiente conjunto de cambios. Esta fusión usa la maquinaria
|
igor@448
|
763 de Mercurial, por lo tanto puede mostrar una herramienta de fusión GUI
|
igor@448
|
764 para ayudarle a resolver los problemas.
|
igor@448
|
765
|
igor@448
|
766 Cuando termine de resolver los efectos de un parche, MQ refrescará su
|
igor@448
|
767 parche basado en el resultado de la fusión.
|
igor@448
|
768
|
igor@448
|
769 Al final de este proceso, su repositorio tendrá una cabeza extra de la
|
igor@448
|
770 antigua cola de parches, y una copia de la cola de parches anterio
|
igor@448
|
771 estará en \sdirname{.hg/patches.\emph{N}}. Puede eliminar la cabeza
|
igor@448
|
772 extra con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a} \hgxopt{mq}{qpop}{-n} patches.\emph{N}}
|
igor@448
|
773 o \hgcmd{strip}. Puede eliminar \sdirname{.hg/patches.\emph{N}} una
|
igor@448
|
774 vez que esté seguro de que no lo necesita más como copia de seguridad.
|
igor@448
|
775
|
igor@448
|
776 \section{Identificar parches}
|
igor@448
|
777
|
igor@448
|
778 Las órdenes de MQ le permiten trabajar refiriéndose al nombre del
|
igor@448
|
779 parche o al número. Es obvio hacerlo por el nombre; por ejemplo se
|
igor@448
|
780 pasa el nombre \filename{foo.patch} a \hgxcmd{mq}{qpush}, que
|
igor@448
|
781 introducirá los parches hasta que \filename{foo.patch} se aplique.
|
igor@448
|
782
|
igor@448
|
783 Para hacerlo más corto, puede referirse a un parche con un nombre y un
|
igor@448
|
784 corrimiento de número; por ejemplo, \texttt{foo.patch-2} significa
|
igor@448
|
785 ``dos parches antes de \texttt{foo.patch}'', mientras que
|
igor@448
|
786 \texttt{bar.patch+4} significa ``cuatro parches después de \texttt{bar.patch}''.
|
igor@448
|
787
|
igor@448
|
788 Referirse a un parche por su índice no es muy diferente. El primer
|
igor@448
|
789 parche que se imprime en la salida de \hgxcmd{mq}{qseries} es el
|
jerojasro@480
|
790 parche cero (si, es el primero en los sistemas que comienzan su conteo
|
igor@448
|
791 en cero); el segundo parche es uno y así sucesivamente.
|
igor@448
|
792
|
igor@448
|
793 MQ facilita el trabajo cuando está usando órdenes normales de
|
igor@448
|
794 Mercurial. Cada comando que acepte Identificadores de conjuntos de
|
igor@448
|
795 cambios también aceptará el nombre de un parche aplicado. MQ aumenta
|
jerojasro@519
|
796 las etiquetas normalmente en el repositorio con un distintivo para cada
|
jerojasro@519
|
797 parche aplicado. Adicionalmente, las etiquetas especiales \index{tags!special tag
|
igor@448
|
798 names!\texttt{qbase}}\texttt{qbase} y \index{tags!special tag
|
igor@448
|
799 names!\texttt{qtip}}\texttt{qtip} identifican los parches
|
igor@448
|
800 ``primero'' y último, respectivamente.
|
jerojasro@336
|
801
|
igor@449
|
802 Junto con las capacidades de Mercurial para etiquetar, estas adiciones
|
igor@449
|
803 hacen que trabajar con parches sea muy sencillo.
|
jerojasro@336
|
804 \begin{itemize}
|
igor@449
|
805 \item ¿Desea enviar una bomba de parches a una lista de correo con los
|
igor@449
|
806 últimos cambios que ha hecho?
|
jerojasro@336
|
807 \begin{codesample4}
|
jerojasro@336
|
808 hg email qbase:qtip
|
jerojasro@336
|
809 \end{codesample4}
|
igor@449
|
810 (¿No sabe qué es una ``bomba de parches''? Consulte la
|
igor@449
|
811 sección~\ref{sec:hgext:patchbomb}.)
|
igor@449
|
812 \item ¿Desea ver todos los parches desde que se aplicó
|
igor@449
|
813 \texttt{foo.patch} sobre los ficheros de un subdirectorio en su
|
igor@449
|
814 árbol?
|
jerojasro@336
|
815 \begin{codesample4}
|
jerojasro@336
|
816 hg log -r foo.patch:qtip \emph{subdir}
|
jerojasro@336
|
817 \end{codesample4}
|
jerojasro@336
|
818 \end{itemize}
|
jerojasro@336
|
819
|
igor@449
|
820 Dado que MQ nombra los parches disponibles al resto de Mercurial con
|
igor@449
|
821 su maquinaria de etiquetas interna, usted no necesita teclear el
|
igor@449
|
822 nombre completo de un parche cuando desea identificarlo por su nombre.
|
jerojasro@336
|
823
|
jerojasro@336
|
824 \begin{figure}[ht]
|
jerojasro@336
|
825 \interaction{mq.id.output}
|
igor@449
|
826 \caption{Uso de las características de etiquetamiento al trabajar
|
igor@449
|
827 con MQ}
|
jerojasro@336
|
828 \label{ex:mq:id}
|
jerojasro@336
|
829 \end{figure}
|
jerojasro@336
|
830
|
igor@449
|
831 Otra consecuencia deseable al representar los nombres de parches como
|
igor@449
|
832 etiquetas es que cuando ejecute la orden \hgcmd{log}, desplegará el
|
igor@449
|
833 nombre del parche como una etiqueta, usualmente con la salida normal.
|
igor@449
|
834 Esto facilita distinguir visualmente los parches aplicados de las
|
igor@449
|
835 revisiones ``normales''. La figura~\ref{ex:mq:id} muestra algunos
|
igor@449
|
836 comandos usuales de Mercurial al trabajar con parches.
|
igor@449
|
837
|
igor@449
|
838 \section{Otra información útil}
|
igor@449
|
839
|
igor@449
|
840 Hay una cantidad de aspectos que hacen que el uso de MQ no representen
|
igor@449
|
841 secciones en sí mismas, pero de los cuales es bueno estar
|
igor@449
|
842 enterado. Los presentamos en aquí:
|
jerojasro@336
|
843
|
jerojasro@336
|
844 \begin{itemize}
|
igor@449
|
845 \item Usualmente cuando hace \hgxcmd{mq}{qpop} a un parche y vuelve a
|
igor@449
|
846 hacerle \hgxcmd{mq}{qpush}, el conjunto de cambios que representa el
|
igor@449
|
847 parche después de introducir/sustraer tendrá una \emph{identidad
|
igor@449
|
848 distinta} que aquella que representaba el conjunto de cambios
|
igor@449
|
849 anteriormente. Consulte la secctión~\ref{sec:mqref:cmd:qpush} para
|
igor@449
|
850 obtener información del por qué de esto.
|
igor@449
|
851 \item No es una buena idea aplicar \hgcmd{merge} de cambios de otra
|
igor@449
|
852 rama con un conjunto de cambios de parches, por lo menos si desea
|
igor@449
|
853 mantener la ``información de parches'' de ese conjunto de cambios y
|
igor@449
|
854 los conjuntos de cambios que se encuentran por debajo en la pila de
|
igor@449
|
855 parches. Si intenta hacerlo, parecerá que ha sido exitoso, pero MQ
|
igor@449
|
856 se confundirá.
|
jerojasro@336
|
857 \end{itemize}
|
jerojasro@336
|
858
|
igor@449
|
859 \section{Administrar parches en un repositorio}
|
jerojasro@336
|
860 \label{sec:mq:repo}
|
jerojasro@336
|
861
|
igor@449
|
862 Dado que el directorio \sdirname{.hg/patches} de MQ reside fuera del
|
igor@449
|
863 repositorio de trabajo de Mercurial, el repositorio ``subyacente'' de
|
igor@449
|
864 Mercurial no sabe nada acerca de la administración o presencia de
|
igor@449
|
865 parches.
|
igor@449
|
866
|
igor@449
|
867 Esto presenta la interesante posibilidad de administrar los contenidos
|
jerojasro@517
|
868 del directorio de parches como un repositorio de Mercurial por su
|
igor@449
|
869 cuenta. Puede ser una forma útil de trabajar. Por ejemplo, puede
|
igor@449
|
870 trabajar en un parche por un rato, hacerle \hgxcmd{mq}{qrefresh} y
|
igor@449
|
871 después hacer \hgcmd{commit} al estado actual del parche. Esto le
|
igor@449
|
872 permite ``devolverse'' a esa versión del parche posteriormente.
|
igor@449
|
873
|
igor@449
|
874 Puede también compartir diferentes versiones de la misma pila de
|
igor@449
|
875 parches entre varios repositorios subyacentes. Uso esto cuando estoy
|
igor@449
|
876 desarrollando una característica del núcleo Linux. Tengo una copia
|
igor@449
|
877 original de las fuentes del núcleo para varias arquitecturas, y cloné
|
igor@449
|
878 un rpositorio en cada una que contiene los parches en los cuales
|
igor@449
|
879 estoy trabajando. Cuando quiero probar un cambio en una arquitectura
|
igor@449
|
880 diferente, introduzco mis parches actuales al repositorio de parches
|
igor@449
|
881 asociado con el árbol del kernel, sustraigo e introduzco todos mis
|
igor@449
|
882 parches, armo y pruebo el núcleo.
|
igor@449
|
883
|
igor@449
|
884 Llevar los parches en un repositorio permite que varios
|
igor@449
|
885 desarrolladores puedan trabajar en la misma serie de parches sin
|
jerojasro@526
|
886 sobreponerse, todo sobre la fuente base subyacente que pueden o no
|
igor@449
|
887 controlar.
|
igor@449
|
888
|
igor@449
|
889 \subsection{Soporte de MQ para repositorios de parches}
|
igor@449
|
890
|
igor@449
|
891 MQ le ayuda a trabajar con el directorio \sdirname{.hg/patches} como
|
igor@449
|
892 un repositorio; cuando usted prepara un repositorio para trabajar con
|
igor@449
|
893 parches usando \hgxcmd{mq}{qinit}, puede pasarle la opción
|
igor@449
|
894 \hgxopt{mq}{qinit}{-c} para que se cree el directorio
|
igor@449
|
895 \sdirname{.hg/patches} como un repositorio de Mercurial.
|
jerojasro@336
|
896
|
jerojasro@336
|
897 \begin{note}
|
igor@449
|
898 Si olvida usar la opción \hgxopt{mq}{qinit}{-c} option, puede ir al
|
igor@449
|
899 directorio \sdirname{.hg/patches} en cualquier momento y ejecutar
|
igor@449
|
900 \hgcmd{init}. No olvide añadir una entrada en el fichero
|
igor@449
|
901 \sfilename{status} del fichero \sfilename{.hgignore}, a pesar de que
|
igor@449
|
902 (\hgcmdargs{qinit}{\hgxopt{mq}{qinit}{-c}} hace estodo de forma
|
igor@449
|
903 automática para usted); usted \emph{seguro} no quiere administrar el
|
jerojasro@522
|
904 fichero \sfilename{status}.
|
jerojasro@336
|
905 \end{note}
|
jerojasro@336
|
906
|
igor@449
|
907 MQ nota convenientemente que el directorio \dirname{.hg/patches}
|
igor@449
|
908 es un repositorio, hará \hgcmd{add} automáticamente a cada parche que
|
igor@449
|
909 usted cree e importe.
|
igor@449
|
910
|
igor@449
|
911 MQ provee una orden corta, \hgxcmd{mq}{qcommit}, que ejecuta
|
igor@449
|
912 \hgcmd{commit} en el directorio \sdirname{.hg/patches}. Lo que ahorra
|
igor@449
|
913 tecleo recurrente.
|
igor@449
|
914
|
igor@449
|
915 Finalmente, para administrar convenientemente el directorio de
|
igor@449
|
916 parches, puede definir el alias \command{mq} en sistemas Unix. Por
|
igor@449
|
917 ejemplo, en sistemas Linux con el intérprete \command{bash}, puede
|
igor@449
|
918 incluir el siguiente recorte de código\ndt{snippet} en su fichero
|
igor@449
|
919 \tildefile{.bashrc}.
|
jerojasro@336
|
920
|
jerojasro@336
|
921 \begin{codesample2}
|
jerojasro@336
|
922 alias mq=`hg -R \$(hg root)/.hg/patches'
|
jerojasro@336
|
923 \end{codesample2}
|
jerojasro@336
|
924
|
igor@449
|
925 Puede aplicar las órdenes de la forma \cmdargs{mq}{pull} al
|
igor@449
|
926 repositorio principal.
|
igor@449
|
927
|
igor@449
|
928 \subsection{Detalles a tener en cuenta}
|
igor@449
|
929
|
igor@449
|
930 El soporte de MQ para trabajar con un repositorio de parches es
|
igor@449
|
931 limitado en ciertos aspectos:
|
igor@449
|
932
|
igor@449
|
933 MQ no puede detectar automáticamente los cambios que haga al
|
igor@449
|
934 directorio de parches. Si aplica \hgcmd{pull}, edita manualmente, o
|
igor@449
|
935 hace \hgcmd{update} a los parches o el fichero \sfilename{series},
|
igor@449
|
936 tendrá que aplicar \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} y después
|
igor@449
|
937 \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} en el repositorio subyacente
|
igor@449
|
938 para que los cambios se reflejen allí. Si olvida hacerlo, puede
|
igor@449
|
939 confundir a MQ en cuanto a qué parches se han aplicado.
|
igor@449
|
940
|
igor@449
|
941 \section{Otras herramientas para trabajar con parches}
|
jerojasro@336
|
942 \label{sec:mq:tools}
|
jerojasro@336
|
943
|
igor@449
|
944 Cuando haya trabajado por cierto tiempo con parches, deseará
|
igor@449
|
945 herramientas que le ayuden a entender y manipular los parches con los
|
igor@449
|
946 que esté tratando.
|
igor@449
|
947
|
igor@449
|
948 La orden \command{diffstat}~\cite{web:diffstat} genera un histograma
|
igor@449
|
949 de modificaciones hechas a cada fichero en un parche. Provee una
|
igor@449
|
950 interesante forma de ``dar un vistazo'' al parche---qué ficheros
|
igor@449
|
951 afecta, y cuántos cambios introduce a cada fichero y en total. (Me ha
|
igor@449
|
952 parecido interesante usar la opción \cmdopt{diffstat}{-p} de
|
igor@449
|
953 \command{diffstat}, puesto que de otra forma intentará hacer cosas
|
igor@449
|
954 inteligentes con prefijos de ficheros que terminan confundiéndome.)
|
jerojasro@336
|
955
|
jerojasro@336
|
956 \begin{figure}[ht]
|
jerojasro@336
|
957 \interaction{mq.tools.tools}
|
igor@449
|
958 \caption{Las órdenes \command{diffstat}, \command{filterdiff}, y \command{lsdiff}}
|
jerojasro@336
|
959 \label{ex:mq:tools}
|
jerojasro@336
|
960 \end{figure}
|
jerojasro@336
|
961
|
igor@449
|
962 El paquete \package{patchutils}~\cite{web:patchutils} es
|
igor@449
|
963 invaluable. Provee un conjunto de pequeñas utilidades que siguen la
|
igor@449
|
964 ``filosofía Unix''; cada una hace una cosa muy bien hecha a un
|
igor@449
|
965 parche. La orden \package{patchutils} que más uso es
|
igor@449
|
966 \command{filterdiff}, que extrae subconjuntos de un fichero de
|
igor@449
|
967 parche. Por ejemplo, dado un parche que modifica centenas de ficheros
|
igor@449
|
968 en docenas de directorios, una única invocación de
|
igor@449
|
969 \command{filterdiff} puede generear un parche más pequeño que
|
igor@449
|
970 solamente toca aquellos ficheros con un patrón. Puede ver otro
|
igor@449
|
971 ejemplo en la sección~\ref{mq-collab:tips:interdiff}.
|
igor@449
|
972
|
igor@449
|
973 \section{Buenas prácticas de trabajo con parches}
|
igor@449
|
974
|
igor@449
|
975 En caso de que esté trabajando en una serie de parches para enviar a
|
igor@449
|
976 un proyecto de software libre o de fuentes abiertas, o en una serie
|
igor@449
|
977 que desea tratar como un conjunto de cambios regular, cuando haya
|
igor@449
|
978 terminado, puede usar técnicas sencillas para mantener su trabajo bien
|
igor@449
|
979 organizado.
|
igor@449
|
980
|
igor@449
|
981 De nombres descriptivos a sus parches. Un buen nombre para un parche
|
igor@449
|
982 podría ser \filename{rework-device-alloc.patch}, porque da de forma
|
igor@449
|
983 inmediata una pista del propósito del parche. Los nombres largos no
|
igor@449
|
984 deben ser un problema; no los estará tecleando repetidamente, pero
|
igor@449
|
985 \emph{estará} ejecutando regularmente órdenes como
|
igor@449
|
986 \hgxcmd{mq}{qapplied} y \hgxcmd{mq}{qtop}. Los nombres adecuados son
|
igor@449
|
987 especialmente importantes cuando tiene bastantes parches con los
|
igor@449
|
988 cuales trabajar, o si está trabajando en diferentes tareas y sus
|
igor@449
|
989 parches toman solamente una porción de su atención.
|
igor@449
|
990
|
igor@449
|
991 Tenga en cuenta en qué parche está trabajando. Use la orden \hgxcmd{mq}{qtop}
|
igor@449
|
992 para dar un vistazo al texto de sus parches frecuentemente---por
|
igor@449
|
993 ejemplo, use \hgcmdargs{tip}{\hgopt{tip}{-p}})---para asegurarse en
|
igor@449
|
994 dónde está ubicado. En distintas oportunidades me sucedió que apliqué
|
igor@449
|
995 \hgxcmd{mq}{qrefresh} a un parche distinto al que deseaba hacerlo, y
|
igor@449
|
996 usualmente es complejo migrar los cambios al parche correcto después
|
igor@449
|
997 de haberlo hecho mal.
|
igor@449
|
998
|
igor@449
|
999 Por este motivo, vale la pena invertir ese poco tiempo para aprender
|
igor@449
|
1000 cómo usar otras herramientas que describí en la
|
igor@449
|
1001 sección~\ref{sec:mq:tools}, particularmente \command{diffstat} y
|
igor@449
|
1002 \command{filterdiff}. La primera le dará una idea de qué cambios está
|
igor@449
|
1003 haciendo su parche, mientras que la segunda permite seleccionar trozos
|
igor@449
|
1004 de un parche para colocarlos en otro.
|
igor@449
|
1005
|
igor@449
|
1006 \section{Recetas de MQ}
|
igor@449
|
1007
|
igor@449
|
1008 \subsection{Administrar parches ``triviales''}
|
igor@449
|
1009
|
igor@449
|
1010 Puesto que colocar ficheros en un repositorio de Mercurial es tan
|
igor@449
|
1011 sencillo, tiene bastante sentido administrar parches de esta forma
|
igor@449
|
1012 incluso si desea hacer algunos cambios al paquete de ficheros que
|
igor@449
|
1013 descargó.
|
igor@449
|
1014
|
igor@449
|
1015 Para comenzar a descargar y desempaqueter un paquete de ficheros, y
|
igor@449
|
1016 volverlo en un repositorio de Mercurial:
|
jerojasro@336
|
1017 \interaction{mq.tarball.download}
|
jerojasro@336
|
1018
|
igor@449
|
1019 Continue creando una pila de parches y haga sus cambios.
|
jerojasro@336
|
1020 \interaction{mq.tarball.qinit}
|
jerojasro@336
|
1021
|
igor@449
|
1022 Digamos que pasan unas semanas o meses, y el autor del paquete libera
|
igor@449
|
1023 una nueva versión. Primero se traen sus cambios al repositorio.
|
jerojasro@336
|
1024 \interaction{mq.tarball.newsource}
|
igor@449
|
1025 La porción que comienza con \hgcmd{locate} mostrada más arriba, borra
|
igor@449
|
1026 todos los ficheros en el directorio de trabajo, así que la opción
|
igor@449
|
1027 \hgopt{commit}{--addremove} de \hgcmd{commit} puede indicar qué
|
igor@449
|
1028 ficheros se han eliminado en la nueva versión del árbol de fuentes.
|
igor@449
|
1029
|
igor@449
|
1030 Finalmente, puede aplicar sus parches encima del nuevo árbol de fuentes
|
jerojasro@336
|
1031 \interaction{mq.tarball.repush}
|
jerojasro@336
|
1032
|
igor@449
|
1033 \subsection{Combinar parches completos}
|
jerojasro@336
|
1034 \label{sec:mq:combine}
|
jerojasro@336
|
1035
|
igor@449
|
1036 MQ provee la orden \hgxcmd{mq}{qfold} que le permite combinar parches
|
igor@449
|
1037 enteros. Se ``integran''\ndt{fold} los parches que usted nombre, en
|
igor@449
|
1038 el orden que especifique, en el último parche aplicado, y concatena
|
igor@449
|
1039 sus descripciones al final de su descripción. Deberá sustraer los
|
igor@449
|
1040 cambios para poder integrarlos.
|
igor@449
|
1041
|
igor@449
|
1042 El orden en el que integre los parches importa. Si el parche
|
igor@449
|
1043 últimamente aplicado es \texttt{foo}, e integra \hgxcmd{mq}{qfold} \texttt{bar} y
|
igor@449
|
1044 \texttt{quux} en él, terminará con un parche que tiene el mismo efecto
|
igor@449
|
1045 que si hubiera aplicado primero \texttt{foo}, y después \texttt{bar},
|
igor@449
|
1046 seguido de \texttt{quux}.
|
igor@449
|
1047
|
igor@449
|
1048 \subsection{Fusionar una porción de un parche dentro de otro}
|
igor@449
|
1049
|
igor@449
|
1050 Fusionar \emph{partes} de un parche dentro de otro es más complejo que
|
igor@449
|
1051 combinar completamente dos parches.
|
igor@449
|
1052
|
igor@449
|
1053 Si desea mover cambios de ficheros completos, puede usar las opciones
|
igor@449
|
1054 \command{filterdiff}'s \cmdopt{filterdiff}{-i} y
|
igor@449
|
1055 \cmdopt{filterdiff}{-x} para elegir las modificaciones remover de un
|
igor@449
|
1056 parche, concatenar su salida al final del parche donde desea
|
igor@449
|
1057 fusionarlo. Usualmente no necesitará modificar el parche del cuál ha
|
igor@449
|
1058 fusionado los cambios. En cambio, MQ reportará que hay unos trozos
|
jerojasro@480
|
1059 que se han desechado cuando usted aplique \hgxcmd{mq}{qpush} (de los
|
igor@449
|
1060 trozos que haya movido al otro parche), y puede sencillamente aplicar
|
igor@449
|
1061 \hgxcmd{mq}{qrefresh} para eliminar los trozos replicados.
|
igor@449
|
1062
|
igor@449
|
1063 Si tiene un parche que tiene varios trozos que modifican un fichero, y
|
igor@449
|
1064 desea mover solamente unos de ellos, el trabajo es un poco más
|
igor@449
|
1065 enredado, pero puede automatizarlo parcialmente. Use
|
igor@449
|
1066 \cmdargs{lsdiff}{-nvv} para imprimir algunos metadatos del parche.
|
jerojasro@336
|
1067 \interaction{mq.tools.lsdiff}
|
jerojasro@336
|
1068
|
igor@449
|
1069 Esta orden imprime tres clases diferentes de números:
|
jerojasro@336
|
1070 \begin{itemize}
|
igor@449
|
1071 \item (en la primera columna) un \emph{número de fichero} para
|
igor@449
|
1072 identificar cada fichero modificado en el parche;
|
igor@449
|
1073 \item (En la siguiente línea, indentado) el número de línea dentro de
|
igor@449
|
1074 un fichero modificado donde comienza el trozo; y
|
igor@449
|
1075 \item (en la misma línea) un \emph{número de trozo} que identifica el
|
igor@449
|
1076 trozo.
|
jerojasro@336
|
1077 \end{itemize}
|
jerojasro@336
|
1078
|
igor@449
|
1079 Tendrá que hacer una inspección visual, y leer el parche para
|
igor@449
|
1080 identificar los números de fichero y trozo que desea, pero puede pasar
|
igor@449
|
1081 posteriormente a las opciones \cmdopt{filterdiff}{--files} y
|
igor@449
|
1082 \cmdopt{filterdiff}{--hunks} de \command{filterdiff}, para seleccionar
|
igor@449
|
1083 exactamente el fichero y el trozo que desea extraer.
|
igor@449
|
1084
|
igor@449
|
1085 Cuando tenga el trozo, puede concatenarlo al final de su parche
|
igor@449
|
1086 objetivo y continuar como en la sección~\ref{sec:mq:combine}.
|
igor@449
|
1087
|
igor@449
|
1088 \section{Diferencias entre quilt y MQ}
|
igor@449
|
1089
|
igor@449
|
1090 Si le es familiar quilt, MQ provee un conjunto similar de órdenes. Hay
|
igor@449
|
1091 algunas diferencias en cómo funcionan.
|
igor@449
|
1092
|
igor@449
|
1093 Debe haber notado que la mayoría de comandos de quilt tienen su
|
igor@449
|
1094 contraparte en MQ, que simplemente comienzan con ``\texttt{q}''. Las
|
igor@449
|
1095 excepciones son las órdenes \texttt{add} y \texttt{remove} de quilt,
|
igor@449
|
1096 que realmente son las órdenes \hgcmd{add} y \hgcmd{remove} de
|
igor@449
|
1097 Mercurial. No hay un equivalente en MQ para la orden
|
igor@449
|
1098 \texttt{edit} de quilt.
|
jerojasro@336
|
1099
|
jerojasro@336
|
1100 %%% Local Variables:
|
jerojasro@336
|
1101 %%% mode: latex
|
jerojasro@336
|
1102 %%% TeX-master: "00book"
|
jerojasro@336
|
1103 %%% End:
|