hgbook

annotate es/mq-collab.tex @ 514:db12ab3b3b25

find changesets by author, revision, files, or words in the commit message
corrected some typos on the title page.

translated a couple of index entries
author Javier Rojas <jerojasro@devnull.li>
date Sun Jan 18 19:45:33 2009 -0500 (2009-01-18)
parents 58dbbfef964f
children 9da096de3c52
rev   line source
jerojasro@481 1 \chapter{Usos avanzados de las Colas de Mercurial}
jerojasro@336 2 \label{chap:mq-collab}
jerojasro@336 3
jerojasro@481 4 Auunque es fácil aprender los usos más directos de las Colas de
jerojasro@481 5 Mercurial, tener algo de disciplina junto con algunas de las
jerojasro@481 6 capacidadees menos usadas de MQ hace posible trabajar en entornos de
jerojasro@481 7 desarrollo complejos.
jerojasro@481 8
jerojasro@481 9 En este capítulo, usaré como ejemplo una técnica que he usado para
jerojasro@481 10 administrar el desarrollo de un controlador de dispositivo Infiniband
jerojasro@481 11 para el kernel de Linux. El controlador en cuestión es grande
jerojasro@481 12 (al menos en lo que se refiere a controladores), con 25,000 líneas de
jerojasro@481 13 código esparcidas en 35 ficheros fuente. Es mantenido por un equipo
jerojasro@481 14 pequeño de desarrolladores.
jerojasro@481 15
jerojasro@481 16 Aunque mucho del material en este capítulo es específico de Linux, los
jerojasro@481 17 mismos principios aplican a cualquier base de código de la que usted
jerojasro@481 18 no sea el propietario principal, y sobre la que usted necesita hacer
jerojasro@481 19 un montón de desarrollo.
jerojasro@481 20
jerojasro@481 21 \section{El problema de múltiples objetivos}
jerojasro@481 22
jerojasro@481 23 El kernel de Linux cambia con rapidez, y nunca ha sido estable
jerojasro@481 24 internamente; los desarrolladores hacen cambios drásticos entre
jerojasro@481 25 %TODO no encontré una traducción adecuada para "release". Por eso el
jerojasro@481 26 %cambio
jerojasro@481 27 versiones frecuentemente. Esto significa que una versión del
jerojasro@481 28 controlador que funciona bien con una versión particular del kernel ni
jerojasro@481 29 siquiera \emph{compilará} correctamente contra, típicamente, cualquier
jerojasro@481 30 otra versión.
jerojasro@481 31
jerojasro@481 32 Para mantener un controlador, debemos tener en cuenta una buena
jerojasro@481 33 cantidad de versiones de Linux en mente.
jerojasro@336 34 \begin{itemize}
jerojasro@481 35 \item Un objetivo es el árbol de desarrollo principal del kernel de
jerojasro@481 36 Linux. En este caso el mantenimiento del código es compartido
jerojasro@481 37 parcialmente por otros desarrolladores en la comunidad del kernel,
jerojasro@481 38 %TODO drive-by.
jerojasro@481 39 quienes hacen modificaciones ``de-afán'' al controlador a medida que
jerojasro@481 40 desarrollan y refinan subsistemas en el kernel.
jerojasro@481 41 %TODO backport
jerojasro@481 42 \item También mantenemos algunos ``backports'' para versiones antiguas
jerojasro@481 43 del kernel de Linux, para dar soporte a las necesidades de los
jerojasro@481 44 clientes que están corriendo versiones antiguas de Linux que no
jerojasro@481 45 incorporan nuestros controladores. (Hacer el \emph{backport} de un
jerojasro@481 46 pedazo de código es modificarlo para que trabaje en una versión
jerojasro@481 47 de su entorno objetivo anterior a aquella para la cual fue escrito.)
jerojasro@481 48 \item Finalmente, nosotros liberamos nuestro software de acuerdo a un
jerojasro@481 49 cronograma que no necesariamente está alineado con el que usan los
jerojasro@481 50 distribuidores de Linux y los desarrolladores del kernel, así que
jerojasro@481 51 podemos entregar nuevas características a los clientes sin forzarlos
jerojasro@481 52 a actualizar kernels completos o distribuciones.
jerojasro@336 53 \end{itemize}
jerojasro@336 54
jerojasro@481 55 \subsection{Aproximaciones tentadoras que no funcionan adecuadamente}
jerojasro@481 56
jerojasro@481 57 Hay dos maneras estándar de mantener una porción de software que debe
jerojasro@481 58 funcionar en muchos entornos diferentes.
jerojasro@336 59
jerojasro@485 60 La primera es mantener varias ramas, cada una pensada para un único
jerojasro@485 61 entorno. El problema de esta aproximación es que usted debe tener una
jerojasro@485 62 disciplina férrea con el flujo de cambios entre repositorios. Una
jerojasro@485 63 nueva característica o un arreglo de fallo deben empezar su vida en un
jerojasro@485 64 repositorio ``prístino'', y luego propagarse a cada repositorio de
jerojasro@485 65 backport. Los cambios para backports están más limitados respecto a
jerojasro@485 66 las ramas a las que deberían propagarse; un cambio para backport que
jerojasro@485 67 es aplicado a una rama en la que no corresponde probablemente hará que
jerojasro@485 68 el controlador no compile.
jerojasro@485 69
jerojasro@485 70 La segunda es mantener un único árbol de código fuente lleno de
jerojasro@485 71 declaraciones que activen o desactiven secciones de código dependiendo
jerojasro@485 72 del entorno objetivo. Ya que estos ``ifdefs'' no están permitidos en
jerojasro@485 73 el árbol del kernel de Linux, debe seguirse algún proceso manual o
jerojasro@485 74 automático para eliminarlos y producir un árbol limpio. Una base de
jerojasro@485 75 código mantenida de esta manera se convierte rápidamente en un nido de
jerojasro@485 76 ratas de bloques condicionales que son difíciles de entender y
jerojasro@485 77 mantener.
jerojasro@485 78
jerojasro@485 79 %TODO canónica?
jerojasro@485 80 Ninguno de estos enfoques es adecuado para situaciones en las que
jerojasro@485 81 usted no es ``dueño'' de la copia canónica de un árbol de fuentes. En
jerojasro@485 82 el caso de un controlador de Linux que es distribuido con el kernel
jerojasro@485 83 estándar, el árbol de Linux contiene la copia del código que será
jerojasro@485 84 considerada por el mundo como la canónica. La versión oficial de
jerojasro@485 85 ``mi'' controlador puede ser modificada por gente que no conozco, sin
jerojasro@485 86 que yo siquiera me entere de ello hasta después de que los cambios
jerojasro@485 87 aparecen en el árbol de Linus.
jerojasro@485 88
jerojasro@485 89 Estos enfoques tienen la debilidad adicional de dificultar la
jerojasro@485 90 %TODO upstream. no no es río arriba
jerojasro@485 91 generación de parches bien formados para enviarlos a la versión
jerojasro@485 92 oficial.
jerojasro@485 93
jerojasro@485 94 En principio, las Colas de Mercurial parecen ser un buen candidato
jerojasro@485 95 para administrar un escenario de desarrollo como el de arriba. Aunque
jerojasro@485 96 este es de hecho el caso, MQ tiene unas cuantas características
jerojasro@485 97 adicionales que hacen el trabajo más agradable.
jerojasro@336 98
jerojasro@489 99 \section{Aplicar parches condicionalmente mediante guardias}
jerojasro@489 100
jerojasro@489 101 Tal vez la mejor manera de conservar la cordura con tantos entornos
jerojasro@489 102 objetivo es poder escoger parches específicos para aplicar para cada
jerojasro@489 103 situación. MQ provee una característica llamada ``guardias''
jerojasro@489 104 (que se origina del comando \texttt{guards} de Quilt) que hace
jerojasro@489 105 precisamente ésto. Para empezar, creemos un repositorio sencillo para
jerojasro@489 106 experimentar.
jerojasro@336 107 \interaction{mq.guards.init}
jerojasro@489 108 Esto nos brinda un pequeño repositorio que contiene dos parches que no
jerojasro@489 109 tienen ninguna dependencia respecto al otro, porque tocan ficheros
jerojasro@489 110 diferentes.
jerojasro@489 111
jerojasro@489 112 La idea detrás de la aplicación condicional es que usted puede
jerojasro@489 113 ``etiquetar'' un parche con un \emph{guardia}, que simplemente es una
jerojasro@489 114 cadena de texto de su elección, y luego decirle a MQ que seleccione
jerojasro@489 115 guardias específicos para usar cuando aplique parches. MQ entonces
jerojasro@489 116 aplicará, u omitirá, un parche vigilado, dependiendo de los guardias
jerojasro@489 117 que usted haya seleccionado.
jerojasro@489 118
jerojasro@489 119 Un parche puede tener una cantidad arbitraria de guardias; cada uno es
jerojasro@489 120 \emph{positivo} (``aplique el parche si este guardia es
jerojasro@489 121 seleccionado'') o \emph{negativo} (``omita este parche si este guardia
jerojasro@489 122 es seleccionado''). Un parche sin guardias siempre es aplicado.
jerojasro@336 123
jerojasro@490 124 \section{Controlar los guardias de un parche}
jerojasro@490 125
jerojasro@491 126 %TODO tal vez no decir determinar, sino definir?
jerojasro@490 127 El comando \hgxcmd{mq}{qguard} le permite determinar qué guardias
jerojasro@490 128 deben aplicarse a un parche, o mostrar los guardias que están en
jerojasro@490 129 efecto. Sin ningún argumento, el comando muestra los guardias del
jerojasro@490 130 parche actual de la parte más alta de la pila.
jerojasro@336 131 \interaction{mq.guards.qguard}
jerojasro@490 132 Para poner un guardia positivo en un parche, prefije el nombre del
jerojasro@490 133 guardia con un ``\texttt{+}''.
jerojasro@336 134 \interaction{mq.guards.qguard.pos}
jerojasro@490 135 Para poner un guardia negativo en un parche, prefije el nombre del
jerojasro@490 136 guardia con un ``\texttt{-}''.
jerojasro@336 137 \interaction{mq.guards.qguard.neg}
jerojasro@336 138
jerojasro@336 139 \begin{note}
jerojasro@490 140 El comando \hgxcmd{mq}{qguard} \emph{pone} los guardias en un
jerojasro@490 141 parche; no los \emph{modifica}. Esto significa que si usted ejecuta
jerojasro@490 142 \hgcmdargs{qguard}{+a +b} sobre un parche, y luego
jerojasro@490 143 \hgcmdargs{qguard}{+c} en el mismo parche, el único guardia sobre el
jerojasro@490 144 parche después del comando será \texttt{+c}.
jerojasro@336 145 \end{note}
jerojasro@336 146
jerojasro@490 147 Mercurial almacena los guardias en el fichero \sfilename{series}; la
jerojasro@490 148 forma en que son almacenados es fácil tanto de entender como de editar
jerojasro@490 149 a mano. (En otras palabras, usted no tiene que usar el comando
jerojasro@490 150 \hgxcmd{mq}{qguard} si no lo desea; está bien simplemente editar el
jerojasro@490 151 fichero \sfilename{series})
jerojasro@336 152 \interaction{mq.guards.series}
jerojasro@336 153
jerojasro@491 154 \section{Selecccionar los guardias a usar}
jerojasro@491 155
jerojasro@491 156 %TODO tal vez no decir determinar, sino definir?
jerojasro@491 157 El comando \hgxcmd{mq}{qselect} determina qué guardias están activos
jerojasro@491 158 en cualquier momento. El efecto de esto es determinar qué parches
jerojasro@491 159 aplicará MQ la próxima vez que usted ejecute \hgxcmd{mq}{qpush}. No
jerojasro@491 160 tiene ningún otro efecto; en particular, no hace nada a los parches
jerojasro@491 161 que ya han sido aplicados.
jerojasro@491 162
jerojasro@491 163 Sin argumentos, el comando \hgxcmd{mq}{qselect} lista los guardias en
jerojasro@491 164 efecto actualmente, uno por cada línea de salida. Cada argumento es
jerojasro@491 165 tratado como el nombre de un guardia a aplicar.
jerojasro@336 166 \interaction{mq.guards.qselect.foo}
jerojasro@491 167 Si está interesado, los guardias seleccionados actualmente están
jerojasro@491 168 almacenados en el fichero \sfilename{guards}.
jerojasro@336 169 \interaction{mq.guards.qselect.cat}
jerojasro@491 170 Podemos ver el efecto que tienen los guardias seleccionados cuando
jerojasro@491 171 ejecutamos \hgxcmd{mq}{qpush}.
jerojasro@336 172 \interaction{mq.guards.qselect.qpush}
jerojasro@336 173
jerojasro@491 174 Un guardia no puede empezar con un caracter ``\texttt{+}'' o
jerojasro@491 175 ``\texttt{-}''. El nombre del guardia no debe contener espacios en
jerojasro@491 176 blanco, pero muchos otros caracteres son aceptables. Si usted trata de
jerojasro@491 177 usar un guardia con un nombre inválido, MQ se quejará:
jerojasro@336 178 \interaction{mq.guards.qselect.error}
jerojasro@491 179 Cambiar los guardias seleccionados cambia los parches que son
jerojasro@491 180 aplicados.
jerojasro@336 181 \interaction{mq.guards.qselect.quux}
jerojasro@491 182 Usted puede ver en el ejemplo de abajo que los guardias negativos
jerojasro@491 183 tienen precedencia sobre los guardias positivos.
jerojasro@336 184 \interaction{mq.guards.qselect.foobar}
jerojasro@336 185
jerojasro@494 186 \section{Reglas de MQ para aplicar parches}
jerojasro@494 187
jerojasro@494 188 Las reglas que MQ usa para decidir si debe aplicar un parche son las
jerojasro@494 189 siguientes.
jerojasro@336 190 \begin{itemize}
jerojasro@494 191 \item Un parche sin guardias es aplicado siempre.
jerojasro@494 192 \item Si el parche tiene algún guardia negativo que corresponda con
jerojasro@494 193 cualquiera de los guardias seleccionados, se salta el parche.
jerojasro@494 194 \item Si el parche tiene algún guardia positivo que corresponda con
jerojasro@494 195 cualquiera de los guardias seleccionados, se aplica el parche.
jerojasro@494 196 \item Si el parche tiene guardias positivos o negativos, pero ninguno
jerojasro@494 197 corresponde con cualquiera de los guardias seleccionados, se salta
jerojasro@494 198 el parche.
jerojasro@336 199 \end{itemize}
jerojasro@336 200
jerojasro@494 201 \section{Podar el entorno de trabajo}
jerojasro@494 202
jerojasro@494 203 En el trabajo del controlador de dispositivo que mencioné
jerojasro@494 204 anteriormente, yo no aplico los parches a un árbol normal del kernel
jerojasro@494 205 de Linux. En cambio, uso un repositorio que sólo contiene una
jerojasro@494 206 instantánea de los ficheros fuente y de cabecera que son relevantes
jerojasro@494 207 para el desarrollo de Infiniband. Este repositorio tiene un~1\% del
jerojasro@494 208 tamaño del repositorio del kernel, por lo que es más fácil trabajar
jerojasro@494 209 con él.
jerojasro@494 210
jerojasro@494 211 Luego escojo una versión ``base'' sobre la cual son aplicados los
jerojasro@494 212 parches. Es una instantánea del árbol del kernel de Linux en una
jerojasro@494 213 revisión de mi elección. Cuando tomo la instantánea, almaceno el ID de
jerojasro@494 214 conjunto de cambios en el mensaje de consignación. Ya que la
jerojasro@494 215 instantánea preserva la ``forma'' y el contenido de las partes
jerojasro@494 216 relevantes del árbol del kernel, puedo aplicar mis parches sobre mi
jerojasro@494 217 pequeño repositorio o sobre un árbol normal del kernel.
jerojasro@494 218
jerojasro@494 219 Normalmente, el árbol base sobre el que se aplican los parches debería
jerojasro@494 220 ser una instantánea de un árbol de desarrollo muy reciente. Esto
jerojasro@494 221 facilita mucho el desarrollo de parches que puedan ser enviados al
jerojasro@494 222 árbol oficial con pocas o ninguna modificación.
jerojasro@494 223
jerojasro@494 224 \section{Dividir el fichero \sfilename{series}}
jerojasro@494 225
jerojasro@494 226 Yo categorizo los parches en el fichero \sfilename{series} en una
jerojasro@494 227 serie de grupos lógicos. Cada sección de parches similares empieza con
jerojasro@494 228 un bloque de comentarios que describen el propósito de los parches que
jerojasro@494 229 le siguen.
jerojasro@494 230
jerojasro@494 231 La secuencia de grupos de parches que mantengo se muestra a
jerojasro@494 232 continuación. El orden de los grupos es importante; explicaré porqué
jerojasro@494 233 luego de que presente los grupos.
jerojasro@336 234 \begin{itemize}
jerojasro@494 235 \item El grupo ``aceptado''. Son parches que el equipo de desarrollo
jerojasro@494 236 ha enviado al mantenedor del subsistema Infiniband, y que él ha
jerojasro@494 237 aceptado, pero que no están presentes en la instantánea en la cual
jerojasro@494 238 está basada el repositorio pequeño. Estos son parches de
jerojasro@494 239 ``sólo lectura'', presentes únicamente para transformar el árbol en
jerojasro@494 240 un estado similar al del repositorio del mantenedor oficial.
jerojasro@494 241 \item El grupo ``revisar''. Parches que yo he enviado, pero sobre los
jerojasro@494 242 que que el mantenedor oficial ha solicitado modificaciones antes de
jerojasro@494 243 aceptarlos.
jerojasro@494 244 \item El grupo ``pendiente''. Parches que no he enviado al mantenedor
jerojasro@494 245 oficial, pero que ya están terminados. Estos parches serán de
jerojasro@494 246 ``sólo lectura'' por un buen tiempo. Si el mantenedor oficial los
jerojasro@494 247 acepta cuando los envíe, los moveré al final del grupo ``aceptado''.
jerojasro@494 248 Si él solicita que modificaciones en alguno de ellos, los moveré al
jerojasro@494 249 principio del grupo ``revisar''.
jerojasro@494 250 \item El grupo ``en proceso''. Parches que están siendo activamente
jerojasro@494 251 desarrollados, y no deberían ser enviados a ninguna parte aún.
jerojasro@494 252 \item El grupo ``backport''. Parches que adaptan el árbol de fuentes a
jerojasro@494 253 versiones antiguas del árbol del kernel.
jerojasro@494 254 \item El grupo ``no enviar''. Parches que por alguna razón nunca deben
jerojasro@494 255 ser enviados al mantenedor oficial del kernel. Por ejemplo, alguno
jerojasro@494 256 de esos parches podría cambiar las cadenas de identificación
jerojasro@494 257 embebidas del controlador para hacer más fácil la distinción, en
jerojasro@494 258 pruebas de campo, entre una versión del controlador de
jerojasro@494 259 salida-del-árbol y una versión entregada por un vendedor de alguna
jerojasro@494 260 distribución.
jerojasro@336 261 \end{itemize}
jerojasro@336 262
jerojasro@494 263 Ahora volvemos a las razones para ordenar los grupos de parches en
jerojasro@494 264 esta manera. Quisiéramos que los parches del fondo de la pila sean tan
jerojasro@494 265 estables como sea posible, para no tener que revisar parches más
jerojasro@494 266 arriba debido a cambios de contexto. Poner los parches que nunca
jerojasro@494 267 cambiarán en el primer lugar del fichero \sfilename{series} sirve a
jerojasro@494 268 este propósito.
jerojasro@494 269
jerojasro@494 270 También desearíamos que los parches que sabemos que debemos modificar
jerojasro@494 271 sean aplicados sobre un árbol de fuentes que se parezca al oficial
jerojasro@494 272 tanto como sea posible. Es por esto que mantenemos los parches
jerojasro@494 273 aceptados disponibles por una buena cantidad de tiempo.
jerojasro@494 274
jerojasro@494 275 Los parches ``backport'' y ``no enviar'' flotan al final del fichero
jerojasro@494 276 \sfilename{series}. Los parches de backport deben ser aplicados encima
jerojasro@494 277 de todos los otros parches, y los parches ``no enviar'' pueden
jerojasro@494 278 perfectamente quedarse fuera del camino.
jerojasro@336 279
jerojasro@495 280 \section{Mantener la serie de parches}
jerojasro@495 281
jerojasro@495 282 En mi trabajo, uso varios guardias para controlar qué parches deben
jerojasro@495 283 ser aplicados.
jerojasro@336 284
jerojasro@336 285 \begin{itemize}
jerojasro@495 286 \item Los parches ``aceptados'' son vigilados con
jerojasro@495 287 \texttt{accepted}. Yo habilito este guardia la mayoría de las veces.
jerojasro@495 288 Cuando aplico los parches sobre un árbol donde los parches ya están
jerojasro@495 289 %TODO no será ``desactivar este guardia''? si sí, corregir versión
jerojasro@495 290 %en inglés también
jerojasro@495 291 presentes, puedo desactivar este parche, y los parches que lo siguen
jerojasro@495 292 se aplicarán sin problemas.
jerojasro@495 293 \item Los parches que están ``terminados'', pero no han sido enviados,
jerojasro@495 294 no tienen guardias. Si estoy aplicando la pila de parches a una
jerojasro@495 295 copia del árbol oficial, no necesito habilitar ningún guardia para
jerojasro@495 296 obtener un árbol de fuentes razonablemente seguro.
jerojasro@495 297 \item Los parches que necesitan revisión antes de ser reenviados
jerojasro@495 298 tienen el guardia \texttt{rework}.
jerojasro@495 299 \item Para aquellos parches que aún están bajo desarrollo, uso
jerojasro@336 300 \texttt{devel}.
jerojasro@495 301 \item Un parche de backport puede tener varios guardias, uno para cada
jerojasro@495 302 versión del kernel a la que aplica. Por ejemplo, un parche que hace
jerojasro@495 303 backport de un segmento de código a~2.6.9 tendrá un guardia~\texttt{2.6.9}.
jerojasro@336 304 \end{itemize}
jerojasro@495 305 La variedad de guardias me brinda una flexibilidad considerable para
jerojasro@495 306 determinar qué tipo de árbol de fuentes acabaré por obtener. En la
jerojasro@495 307 mayoría de las situaciones, la selección de guardias apropiados es
jerojasro@495 308 automatizada durante el proceso de compilación, pero puedo ajustar
jerojasro@495 309 manualmente los guardias a usar para circunstancias poco comunes.
jerojasro@336 310
jerojasro@497 311 \subsection{El arte de escribir parches de backport}
jerojasro@497 312
jerojasro@497 313 Al usar MQ, escribir un parche de backport es un proceso simple. Todo
jerojasro@497 314 lo que dicho parche debe hacer es modificar una sección de código que
jerojasro@497 315 usa una característica del kernel que no está presente en la versión
jerojasro@497 316 anterior del kernel, para que el controlador siga funcionando
jerojasro@497 317 correctamente en esa versión anterior.
jerojasro@497 318
jerojasro@497 319 Una meta útil al escribir un buen parche de backport es hacer parecer
jerojasro@497 320 que el código hubiera sido escrito para la versión vieja del kernel
jerojasro@497 321 que usted tiene como objetivo. Entre menos intrusivo el parche, más
jerojasro@497 322 fácil será entenderlo y mantenerlo. Si usted está escribiendo una
jerojasro@497 323 colección de parches de backport para evitar el efecto de ``nido de
jerojasro@497 324 ratas'' de tener muchos \texttt{\#ifdef}s (secciones de código fuente
jerojasro@497 325 que sólo son usados condicionalmente) en su código, no introduzca
jerojasro@497 326 \texttt{\#ifdef}s dependientes de versiones específicas en los
jerojasro@497 327 parches. En vez de eso, escriba varios parches, cada uno de ellos
jerojasro@497 328 haciendo cambios incondicionales, y controle su aplicación usando
jerojasro@497 329 guardias.
jerojasro@497 330
jerojasro@497 331 Hay dos razones para ubicar los parches de backport en un grupo
jerojasro@497 332 diferente, aparte de los parches ``regulares'' cuyos efectos son
jerojasro@497 333 modificados por ellos. La primera es que mezclar los dos hace más
jerojasro@497 334 difícil usar herramientas como la extensión \hgext{patchbomb} para
jerojasro@497 335 automatizar el proceso de enviar los parches a un mantenedor oficial.
jerojasro@497 336 La segunda es que un parche de backport puede perturbar el contexto en
jerojasro@497 337 el que se aplica un parche regular subsecuente, haciendo imposible
jerojasro@497 338 aplicar el parche normal limpiamente \emph{sin} que el parche de
jerojasro@497 339 backport sea aplicado antes.
jerojasro@336 340
jerojasro@498 341 \section{Consejos útiles para hacer desarrollo con MQ}
jerojasro@498 342
jerojasro@498 343 \subsection{Organizar parches en directorios}
jerojasro@498 344
jerojasro@498 345 Si está trabajando en un proyecto grande con MQ, no es difícil
jerojasro@498 346 acumular un gran número de parches. Por ejemplo, tengo un repositorio
jerojasro@498 347 de parches que contiene más de 250 parches.
jerojasro@498 348
jerojasro@498 349 Si usted puede agrupar estos parches en categorías lógicas separadas,
jerojasro@498 350 usted puede almacenarlos en diferentes directorios si lo desea; MQ no
jerojasro@498 351 tiene problemas manejando nombres de parches que contienen separadores
jerojasro@498 352 de ruta.
jerojasro@498 353
jerojasro@498 354 \subsection{Ver la historia de un parche}
jerojasro@336 355 \label{mq-collab:tips:interdiff}
jerojasro@336 356
jerojasro@498 357 Si usted está desarrollando un conjunto de parches en un período de
jerojasro@498 358 tiempo grande, es una buena idea mantenerlos en un repositorio, como
jerojasro@498 359 se discutió en la sección~\ref{sec:mq:repo}. Si lo hace, notará
jerojasro@498 360 rápidamente que usar el comando \hgcmd{diff} para mirar la historia
jerojasro@498 361 del repositorio no es viable. Esto es debido en parte a que usted está
jerojasro@498 362 mirando la segunda derivada del código real (el diff de un diff), pero
jerojasro@498 363 también porque MQ añade ruido al proceso al modificar las marcas de
jerojasro@498 364 tiempo y los nombres de directorio cuando actualiza un parche.
jerojasro@498 365
jerojasro@498 366 Sin embargo, usted puede usar la extensión \hgext{extdiff}, que es
jerojasro@498 367 provisto junto con Mercurial, para convertir un diff de dos versiones
jerojasro@498 368 de un parche en algo legible. Para hacer esto, usted necesitará un
jerojasro@498 369 paquete de un tercero llamado
jerojasro@498 370 \package{patchutils}~\cite{web:patchutils}. Éste paquete provee un
jerojasro@498 371 comando llamado \command{interdiff}, que muestra las diferencias entre
jerojasro@498 372 dos diffs como un diff. Al usarlo en dos versiones del mismo diff,
jerojasro@498 373 genera un diff que representa el diff de la primera a la segunda
jerojasro@498 374 versión.
jerojasro@498 375
jerojasro@498 376 Usted puede habilitar la extensión \hgext{extdiff} de la manera usual,
jerojasro@498 377 añadiendo una línea a la sección \rcsection{extensions} de su \hgrc.
jerojasro@336 378 \begin{codesample2}
jerojasro@336 379 [extensions]
jerojasro@336 380 extdiff =
jerojasro@336 381 \end{codesample2}
jerojasro@498 382 El comando \command{interdiff} espera recibir los nombres de dos
jerojasro@498 383 ficheros, pero la extensión \hgext{extdiff} le pasa un par de
jerojasro@498 384 directorios al programa que ejecuta, cada uno de los cuales puede
jerojasro@498 385 contener una cantidad arbitraria de ficheros. Por esto necesitamos un
jerojasro@498 386 programa pequeño que ejecute \command{interdiff} en cada par de
jerojasro@498 387 ficheros de estos dos directorios. Este programa está disponible como
jerojasro@498 388 \sfilename{hg-interdiff} en el directorio \dirname{examples} del
jerojasro@498 389 repositorio de código fuente que acompaña a este libro.
jerojasro@336 390 \excode{hg-interdiff}
jerojasro@336 391
jerojasro@498 392 Con el programa \sfilename{hg-interdiff} en la ruta de búsqueda de su
jerojasro@498 393 intérprete de comandos, puede ejecutarlo como sigue, desde dentro de
jerojasro@498 394 un directorio de parches MQ:
jerojasro@336 395 \begin{codesample2}
jerojasro@336 396 hg extdiff -p hg-interdiff -r A:B my-change.patch
jerojasro@336 397 \end{codesample2}
jerojasro@498 398 Ya que usted seguramente querrá usar este comando tan largo a menudo,
jerojasro@498 399 puede hacer que \hgext{hgext} lo haga disponible como un comando
jerojasro@498 400 normal de Mercurial, editando de nuevo su \hgrc.
jerojasro@336 401 \begin{codesample2}
jerojasro@336 402 [extdiff]
jerojasro@336 403 cmd.interdiff = hg-interdiff
jerojasro@336 404 \end{codesample2}
jerojasro@498 405 Esto le indica a \hgext{hgext} que ponga a disposición un comando
jerojasro@498 406 \texttt{interdiff}, con lo que usted puede abreviar la invocación
jerojasro@498 407 anterior de \hgxcmd{extdiff}{extdiff} a algo un poco más manejable.
jerojasro@336 408 \begin{codesample2}
jerojasro@336 409 hg interdiff -r A:B my-change.patch
jerojasro@336 410 \end{codesample2}
jerojasro@336 411
jerojasro@336 412 \begin{note}
jerojasro@498 413 %TODO revisar redacción
jerojasro@498 414 El comando \command{interdiff} trabaja bien sólo si los ficheros
jerojasro@498 415 contra los cuales son generadas las versiones de un parche se
jerojasro@498 416 mantienen iguales. Si usted crea un parche, modifica los ficheros
jerojasro@498 417 subyacentes, y luego regenera el parche, \command{interdiff} podría
jerojasro@498 418 no producir ningún resultado útil.
jerojasro@336 419 \end{note}
jerojasro@336 420
jerojasro@498 421 La extensión \hgext{extdiff} es útil para más que solamente mejorar la
jerojasro@498 422 presentación de los parches~MQ. Para leer más acerca de esto, vaya a
jerojasro@498 423 la sección~\ref{sec:hgext:extdiff}.
jerojasro@336 424
jerojasro@336 425 %%% Local Variables:
jerojasro@336 426 %%% mode: latex
jerojasro@336 427 %%% TeX-master: "00book"
jerojasro@336 428 %%% End: