
jerojasro@481: \chapter{Usos avanzados de las Colas de Mercurial}
jerojasro@336: \label{chap:mq-collab}
jerojasro@336: 
jerojasro@481: Auunque es fácil aprender los usos más directos de las Colas de
jerojasro@481: Mercurial, tener algo de disciplina junto con algunas de las
jerojasro@481: capacidadees menos usadas de MQ hace posible trabajar en entornos de
jerojasro@481: desarrollo complejos.
jerojasro@481: 
jerojasro@481: En este capítulo, usaré como ejemplo una técnica que he usado para
jerojasro@481: administrar el desarrollo de un controlador de dispositivo Infiniband
jerojasro@481: para el kernel de Linux. El controlador en cuestión es grande
jerojasro@481: (al menos en lo que se refiere a controladores), con 25,000 líneas de
jerojasro@481: código esparcidas en 35 ficheros fuente. Es mantenido por un equipo
jerojasro@481: pequeño de desarrolladores. 
jerojasro@481: 
jerojasro@481: Aunque mucho del material en este capítulo es específico de Linux, los
jerojasro@481: mismos principios aplican a cualquier base de código de la que usted
jerojasro@481: no sea el propietario principal, y sobre la que usted necesita hacer
jerojasro@481: un montón de desarrollo.
jerojasro@481: 
jerojasro@481: \section{El problema de múltiples objetivos}
jerojasro@481: 
jerojasro@481: El kernel de Linux cambia con rapidez, y nunca ha sido estable
jerojasro@481: internamente; los desarrolladores hacen cambios drásticos entre
jerojasro@481: %TODO no encontré una traducción adecuada para "release". Por eso el
jerojasro@481: %cambio
jerojasro@481: versiones frecuentemente. Esto significa que una versión del
jerojasro@481: controlador que funciona bien con una versión particular del kernel ni
jerojasro@481: siquiera \emph{compilará} correctamente contra, típicamente, cualquier
jerojasro@481: otra versión.
jerojasro@481: 
jerojasro@481: Para mantener un controlador, debemos tener en cuenta una buena
jerojasro@481: cantidad de versiones de Linux en mente.
jerojasro@336: \begin{itemize}
jerojasro@481: \item Un objetivo es el árbol de desarrollo principal del kernel de
jerojasro@481:   Linux. En este caso el mantenimiento del código es compartido
jerojasro@481:   parcialmente por otros desarrolladores en la comunidad del kernel, 
jerojasro@481:   %TODO drive-by. 
jerojasro@481:   quienes hacen modificaciones ``de-afán'' al controlador a medida que 
jerojasro@481:   desarrollan y refinan subsistemas en el kernel.
jerojasro@481:   %TODO backport
jerojasro@481: \item También mantenemos algunos ``backports'' para versiones antiguas
jerojasro@481:   del kernel de Linux, para dar soporte a las necesidades de los
jerojasro@481:   clientes que están corriendo versiones antiguas de Linux que no
jerojasro@481:   incorporan nuestros controladores. (Hacer el \emph{backport} de un
jerojasro@481:   pedazo de código es modificarlo para que trabaje en una versión
jerojasro@481:   de su entorno objetivo anterior a aquella para la cual fue escrito.)
jerojasro@481: \item Finalmente, nosotros liberamos nuestro software de acuerdo a un
jerojasro@481:   cronograma que no necesariamente está alineado con el que usan los
jerojasro@481:   distribuidores de Linux y los desarrolladores del kernel, así que
jerojasro@481:   podemos entregar nuevas características a los clientes sin forzarlos
jerojasro@481:   a actualizar kernels completos o distribuciones.
jerojasro@336: \end{itemize}
jerojasro@336: 
jerojasro@481: \subsection{Aproximaciones tentadoras que no funcionan adecuadamente}
jerojasro@481: 
jerojasro@481: Hay dos maneras estándar de mantener una porción de software que debe
jerojasro@481: funcionar en muchos entornos diferentes.
jerojasro@336: 
jerojasro@485: La primera es mantener varias ramas, cada una pensada para un único
jerojasro@485: entorno. El problema de esta aproximación es que usted debe tener una
jerojasro@485: disciplina férrea con el flujo de cambios entre repositorios. Una
jerojasro@485: nueva característica o un arreglo de fallo deben empezar su vida en un
jerojasro@485: repositorio ``prístino'', y luego propagarse a cada repositorio de
jerojasro@485: backport. Los cambios para backports están más limitados respecto a
jerojasro@485: las ramas a las que deberían propagarse; un cambio para backport que
jerojasro@485: es aplicado a una rama en la que no corresponde probablemente hará que
jerojasro@485: el controlador no compile.
jerojasro@485: 
jerojasro@485: La segunda es mantener un único árbol de código fuente lleno de
jerojasro@485: declaraciones que activen o desactiven secciones de código dependiendo
jerojasro@485: del entorno objetivo. Ya que estos ``ifdefs'' no están permitidos en
jerojasro@485: el árbol del kernel de Linux, debe seguirse algún proceso manual o
jerojasro@485: automático para eliminarlos y producir un árbol limpio. Una base de
jerojasro@485: código mantenida de esta manera se convierte rápidamente en un nido de
jerojasro@485: ratas de bloques condicionales que son difíciles de entender y
jerojasro@485: mantener.
jerojasro@485: 
jerojasro@485: %TODO canónica?
jerojasro@485: Ninguno de estos enfoques es adecuado para situaciones en las que
jerojasro@485: usted no es ``dueño'' de la copia canónica de un árbol de fuentes. En
jerojasro@485: el caso de un controlador de Linux que es distribuido con el kernel
jerojasro@485: estándar, el árbol de Linux contiene la copia del código que será
jerojasro@485: considerada por el mundo como la canónica. La versión oficial de
jerojasro@485: ``mi'' controlador puede ser modificada por gente que no conozco, sin
jerojasro@485: que yo siquiera me entere de ello hasta después de que los cambios
jerojasro@485: aparecen en el árbol de Linus.
jerojasro@485: 
jerojasro@485: Estos enfoques tienen la debilidad adicional de dificultar la
jerojasro@485: %TODO upstream. no no es río arriba
jerojasro@485: generación de parches bien formados para enviarlos a la versión
jerojasro@485: oficial.
jerojasro@485: 
jerojasro@485: En principio, las Colas de Mercurial parecen ser un buen candidato
jerojasro@485: para administrar un escenario de desarrollo como el de arriba. Aunque
jerojasro@485: este es de hecho el caso, MQ tiene unas cuantas características
jerojasro@485: adicionales que hacen el trabajo más agradable.
jerojasro@336: 
jerojasro@489: \section{Aplicar parches condicionalmente mediante guardias}
jerojasro@489: 
jerojasro@489: Tal vez la mejor manera de conservar la cordura con tantos entornos
jerojasro@489: objetivo es poder escoger parches específicos para aplicar para cada
jerojasro@489: situación. MQ provee una característica llamada ``guardias''
jerojasro@489: (que se origina del comando \texttt{guards} de Quilt) que hace
jerojasro@489: precisamente ésto. Para empezar, creemos un repositorio sencillo para
jerojasro@489: experimentar.
jerojasro@336: \interaction{mq.guards.init}
jerojasro@489: Esto nos brinda un pequeño repositorio que contiene dos parches que no
jerojasro@489: tienen ninguna dependencia respecto al otro, porque tocan ficheros
jerojasro@489: diferentes.
jerojasro@489: 
jerojasro@489: La idea detrás de la aplicación condicional es que usted puede
jerojasro@489: ``etiquetar'' un parche con un \emph{guardia}, que simplemente es una
jerojasro@489: cadena de texto de su elección, y luego decirle a MQ que seleccione
jerojasro@489: guardias específicos para usar cuando aplique parches. MQ entonces
jerojasro@489: aplicará, u omitirá, un parche vigilado, dependiendo de los guardias
jerojasro@489: que usted haya seleccionado.
jerojasro@489: 
jerojasro@489: Un parche puede tener una cantidad arbitraria de guardias; cada uno es
jerojasro@489: \emph{positivo} (``aplique el parche si este guardia es
jerojasro@489: seleccionado'') o \emph{negativo} (``omita este parche si este guardia
jerojasro@489: es seleccionado''). Un parche sin guardias siempre es aplicado.
jerojasro@336: 
jerojasro@490: \section{Controlar los guardias de un parche}
jerojasro@490: 
jerojasro@491: %TODO tal vez no decir determinar, sino definir?
jerojasro@490: El comando \hgxcmd{mq}{qguard} le permite determinar qué guardias
jerojasro@490: deben aplicarse a un parche, o mostrar los guardias que están en
jerojasro@490: efecto. Sin ningún argumento, el comando muestra los guardias del
jerojasro@490: parche actual de la parte más alta de la pila.
jerojasro@336: \interaction{mq.guards.qguard}
jerojasro@490: Para poner un guardia positivo en un parche, prefije el nombre del
jerojasro@490: guardia con un ``\texttt{+}''.
jerojasro@336: \interaction{mq.guards.qguard.pos}
jerojasro@490: Para poner un guardia negativo en un parche, prefije el nombre del
jerojasro@490: guardia con un ``\texttt{-}''.
jerojasro@336: \interaction{mq.guards.qguard.neg}
jerojasro@336: 
jerojasro@336: \begin{note}
jerojasro@490:   El comando \hgxcmd{mq}{qguard} \emph{pone} los guardias en un
jerojasro@490:   parche; no los \emph{modifica}. Esto significa que si usted ejecuta
jerojasro@490:   \hgcmdargs{qguard}{+a +b} sobre un parche, y luego
jerojasro@490:   \hgcmdargs{qguard}{+c} en el mismo parche, el único guardia sobre el
jerojasro@490:   parche después del comando será \texttt{+c}.
jerojasro@336: \end{note}
jerojasro@336: 
jerojasro@490: Mercurial almacena los guardias en el fichero \sfilename{series}; la
jerojasro@490: forma en que son almacenados es fácil tanto de entender como de editar
jerojasro@490: a mano. (En otras palabras, usted no tiene que usar el comando
jerojasro@490: \hgxcmd{mq}{qguard} si no lo desea; está bien simplemente editar el
jerojasro@490: fichero \sfilename{series})
jerojasro@336: \interaction{mq.guards.series}
jerojasro@336: 
jerojasro@491: \section{Selecccionar los guardias a usar}
jerojasro@491: 
jerojasro@491: %TODO tal vez no decir determinar, sino definir?
jerojasro@491: El comando \hgxcmd{mq}{qselect} determina qué guardias están activos
jerojasro@491: en cualquier momento. El efecto de esto es determinar qué parches
jerojasro@491: aplicará MQ la próxima vez que usted ejecute \hgxcmd{mq}{qpush}.  No
jerojasro@491: tiene ningún otro efecto; en particular, no hace nada a los parches
jerojasro@491: que ya han sido aplicados.
jerojasro@491: 
jerojasro@491: Sin argumentos, el comando \hgxcmd{mq}{qselect} lista los guardias en
jerojasro@491: efecto actualmente, uno por cada línea de salida. Cada argumento es
jerojasro@491: tratado como el nombre de un guardia a aplicar.
jerojasro@336: \interaction{mq.guards.qselect.foo}
jerojasro@491: Si está interesado, los guardias seleccionados actualmente están
jerojasro@491: almacenados en el fichero \sfilename{guards}.
jerojasro@336: \interaction{mq.guards.qselect.cat}
jerojasro@491: Podemos ver el efecto que tienen los guardias seleccionados cuando
jerojasro@491: ejecutamos \hgxcmd{mq}{qpush}.
jerojasro@336: \interaction{mq.guards.qselect.qpush}
jerojasro@336: 
jerojasro@491: Un guardia no puede empezar con un  caracter ``\texttt{+}'' o
jerojasro@491: ``\texttt{-}''. El nombre del guardia no debe contener espacios en
jerojasro@491: blanco, pero muchos otros caracteres son aceptables. Si usted trata de
jerojasro@491: usar un guardia con un nombre inválido, MQ se quejará:
jerojasro@336: \interaction{mq.guards.qselect.error} 
jerojasro@491: Cambiar los guardias seleccionados cambia los parches que son
jerojasro@491: aplicados.
jerojasro@336: \interaction{mq.guards.qselect.quux} 
jerojasro@491: Usted puede ver en el ejemplo de abajo que los guardias negativos
jerojasro@491: tienen precedencia sobre los guardias positivos.
jerojasro@336: \interaction{mq.guards.qselect.foobar}
jerojasro@336: 
jerojasro@494: \section{Reglas de MQ para aplicar parches}
jerojasro@494: 
jerojasro@494: Las reglas que MQ usa para decidir si debe aplicar un parche son las
jerojasro@494: siguientes.
jerojasro@336: \begin{itemize}
jerojasro@494: \item Un parche sin guardias es aplicado siempre.
jerojasro@494: \item Si el parche tiene algún guardia negativo que corresponda con
jerojasro@494:   cualquiera de los guardias seleccionados, se salta el parche.
jerojasro@494: \item Si el parche tiene algún guardia positivo que corresponda con
jerojasro@494:   cualquiera de los guardias seleccionados, se aplica el parche.
jerojasro@494: \item Si el parche tiene guardias positivos o negativos, pero ninguno
jerojasro@494:   corresponde con cualquiera de los guardias seleccionados, se salta
jerojasro@494:   el parche.
jerojasro@336: \end{itemize}
jerojasro@336: 
jerojasro@494: \section{Podar el entorno de trabajo}
jerojasro@494: 
jerojasro@494: En el trabajo del controlador de dispositivo que mencioné
jerojasro@494: anteriormente, yo no aplico los parches a un árbol normal del kernel
jerojasro@494: de Linux. En cambio, uso un repositorio que sólo contiene una
jerojasro@494: instantánea de los ficheros fuente y de cabecera que son relevantes
jerojasro@494: para el desarrollo de Infiniband. Este repositorio tiene un~1\% del
jerojasro@494: tamaño del repositorio del kernel, por lo que es más fácil trabajar
jerojasro@494: con él.
jerojasro@494: 
jerojasro@494: Luego escojo una versión ``base'' sobre la cual son aplicados los
jerojasro@494: parches. Es una instantánea del árbol del kernel de Linux en una
jerojasro@494: revisión de mi elección. Cuando tomo la instantánea, almaceno el ID de
jerojasro@494: conjunto de cambios en el mensaje de consignación. Ya que la
jerojasro@494: instantánea preserva la ``forma'' y el contenido de las partes
jerojasro@494: relevantes del árbol del kernel, puedo aplicar mis parches sobre mi
jerojasro@494: pequeño repositorio o sobre un árbol normal del kernel.
jerojasro@494: 
jerojasro@494: Normalmente, el árbol base sobre el que se aplican los parches debería
jerojasro@494: ser una instantánea de un árbol de desarrollo muy reciente. Esto
jerojasro@494: facilita mucho el desarrollo de parches que puedan ser enviados al
jerojasro@494: árbol oficial con pocas o ninguna modificación.
jerojasro@494: 
jerojasro@494: \section{Dividir el fichero \sfilename{series}}
jerojasro@494: 
jerojasro@494: Yo categorizo los parches en el fichero \sfilename{series} en una
jerojasro@494: serie de grupos lógicos. Cada sección de parches similares empieza con
jerojasro@494: un bloque de comentarios que describen el propósito de los parches que
jerojasro@494: le siguen.
jerojasro@494: 
jerojasro@494: La secuencia de grupos de parches que mantengo se muestra a
jerojasro@494: continuación. El orden de los grupos es importante; explicaré porqué
jerojasro@494: luego de que presente los grupos.
jerojasro@336: \begin{itemize}
jerojasro@494: \item El grupo ``aceptado''. Son parches que el equipo de desarrollo
jerojasro@494:   ha enviado al mantenedor del subsistema Infiniband, y que él ha
jerojasro@494:   aceptado, pero que no están presentes en la instantánea en la cual
jerojasro@494:   está basada el repositorio pequeño. Estos son parches de
jerojasro@494:   ``sólo lectura'', presentes únicamente para transformar el árbol en
jerojasro@494:   un estado similar al del repositorio del mantenedor oficial.
jerojasro@494: \item El grupo ``revisar''. Parches que yo he enviado, pero sobre los
jerojasro@494:   que que el mantenedor oficial ha solicitado modificaciones antes de
jerojasro@494:   aceptarlos.
jerojasro@494: \item El grupo ``pendiente''. Parches que no he enviado al mantenedor
jerojasro@494:   oficial, pero que ya están terminados. Estos parches serán de
jerojasro@494:   ``sólo lectura'' por un buen tiempo. Si el mantenedor oficial los
jerojasro@494:   acepta cuando los envíe, los moveré al final del grupo ``aceptado''.
jerojasro@494:   Si él solicita que modificaciones en alguno de ellos, los moveré al
jerojasro@494:   principio del grupo ``revisar''.
jerojasro@494: \item El grupo ``en proceso''. Parches que están siendo activamente
jerojasro@494:   desarrollados, y no deberían ser enviados a ninguna parte aún.
jerojasro@494: \item El grupo ``backport''. Parches que adaptan el árbol de fuentes a
jerojasro@494:     versiones antiguas del árbol del kernel.
jerojasro@494: \item El grupo ``no enviar''. Parches que por alguna razón nunca deben
jerojasro@494:   ser enviados al mantenedor oficial del kernel. Por ejemplo, alguno
jerojasro@494:   de esos parches podría cambiar las cadenas de identificación
jerojasro@494:   embebidas del controlador para hacer más fácil la distinción, en
jerojasro@494:   pruebas de campo, entre una versión del controlador de
jerojasro@494:   salida-del-árbol  y una versión entregada por un vendedor de alguna
jerojasro@494:   distribución.
jerojasro@336: \end{itemize}
jerojasro@336: 
jerojasro@494: Ahora volvemos a las razones para ordenar los grupos de parches en
jerojasro@494: esta manera. Quisiéramos que los parches del fondo de la pila sean tan
jerojasro@494: estables como sea posible, para no tener que revisar parches más
jerojasro@494: arriba debido a cambios de contexto. Poner los parches que nunca
jerojasro@494: cambiarán en el primer lugar del fichero \sfilename{series} sirve a
jerojasro@494: este propósito.
jerojasro@494: 
jerojasro@494: También desearíamos que los parches que sabemos que debemos modificar
jerojasro@494: sean aplicados sobre un árbol de fuentes que se parezca al oficial
jerojasro@494: tanto como sea posible. Es por esto que mantenemos los parches
jerojasro@494: aceptados disponibles por una buena cantidad de tiempo.
jerojasro@494: 
jerojasro@494: Los parches ``backport'' y ``no enviar'' flotan al final del fichero
jerojasro@494: \sfilename{series}. Los parches de backport deben ser aplicados encima
jerojasro@494: de todos los otros parches, y los parches ``no enviar'' pueden
jerojasro@494: perfectamente quedarse fuera del camino.
jerojasro@336: 
jerojasro@495: \section{Mantener la serie de parches}
jerojasro@495: 
jerojasro@495: En mi trabajo, uso varios guardias para controlar qué parches deben
jerojasro@495: ser aplicados.
jerojasro@336: 
jerojasro@336: \begin{itemize}
jerojasro@495: \item Los parches ``aceptados'' son vigilados con
jerojasro@495:   \texttt{accepted}. Yo habilito este guardia la mayoría de las veces.
jerojasro@495:   Cuando aplico los parches sobre un árbol donde los parches ya están
jerojasro@495:   %TODO no será ``desactivar este guardia''? si sí, corregir versión
jerojasro@495:   %en inglés también
jerojasro@495:   presentes, puedo desactivar este parche, y los parches que lo siguen
jerojasro@495:   se aplicarán sin problemas.
jerojasro@495: \item Los parches que están ``terminados'', pero no han sido enviados,
jerojasro@495:   no tienen guardias. Si estoy aplicando la pila de parches a una
jerojasro@495:   copia del árbol oficial, no necesito habilitar ningún guardia para
jerojasro@495:   obtener un árbol de fuentes razonablemente seguro.
jerojasro@495: \item Los parches que necesitan revisión antes de ser reenviados
jerojasro@495:   tienen el guardia \texttt{rework}.
jerojasro@495: \item Para aquellos parches que aún están bajo desarrollo, uso
jerojasro@336:   \texttt{devel}.
jerojasro@495: \item Un parche de backport puede tener varios guardias, uno para cada
jerojasro@495:   versión del kernel a la que aplica. Por ejemplo, un parche que hace
jerojasro@495:   backport de un segmento de código a~2.6.9 tendrá un guardia~\texttt{2.6.9}.
jerojasro@336: \end{itemize}
jerojasro@495: La variedad de guardias me brinda una flexibilidad considerable para
jerojasro@495: determinar qué tipo de árbol de fuentes acabaré por obtener. En la
jerojasro@495: mayoría de las situaciones, la selección de guardias apropiados es
jerojasro@495: automatizada durante el proceso de compilación, pero puedo ajustar
jerojasro@495: manualmente los guardias a usar para circunstancias poco comunes.
jerojasro@336: 
jerojasro@497: \subsection{El arte de escribir parches de backport}
jerojasro@497: 
jerojasro@497: Al usar MQ, escribir un parche de backport es un proceso simple. Todo
jerojasro@497: lo que dicho parche debe hacer es modificar una sección de código que
jerojasro@497: usa una característica del kernel que no está presente en la versión
jerojasro@497: anterior del kernel, para que el controlador siga funcionando
jerojasro@497: correctamente en esa versión anterior.
jerojasro@497: 
jerojasro@497: Una meta útil al escribir un buen parche de backport es hacer parecer
jerojasro@497: que el código hubiera sido escrito para la versión vieja del kernel
jerojasro@497: que usted tiene como objetivo. Entre menos intrusivo el parche, más
jerojasro@497: fácil será entenderlo y mantenerlo. Si usted está escribiendo una
jerojasro@497: colección de parches de backport para evitar el efecto de ``nido de
jerojasro@497: ratas'' de tener muchos \texttt{\#ifdef}s (secciones de código fuente
jerojasro@497: que sólo son usados condicionalmente) en su código, no introduzca
jerojasro@497: \texttt{\#ifdef}s dependientes de versiones específicas en los
jerojasro@497: parches. En vez de eso, escriba varios parches, cada uno de ellos
jerojasro@497: haciendo cambios incondicionales, y controle su aplicación usando
jerojasro@497: guardias.
jerojasro@497: 
jerojasro@497: Hay dos razones para ubicar los parches de backport en un grupo
jerojasro@497: diferente, aparte de los parches ``regulares'' cuyos efectos son
jerojasro@497: modificados por ellos. La primera es que mezclar los dos hace más
jerojasro@497: difícil usar herramientas como la extensión \hgext{patchbomb} para
jerojasro@497: automatizar el proceso de enviar los parches a un mantenedor oficial.
jerojasro@497: La segunda es que un parche de backport puede perturbar el contexto en
jerojasro@497: el que se aplica un parche regular subsecuente, haciendo imposible
jerojasro@497: aplicar el parche normal limpiamente \emph{sin} que el parche de
jerojasro@497: backport sea aplicado antes.
jerojasro@336: 
jerojasro@498: \section{Consejos útiles para hacer desarrollo con MQ}
jerojasro@498: 
jerojasro@498: \subsection{Organizar parches en directorios}
jerojasro@498: 
jerojasro@498: Si está trabajando en un proyecto grande con MQ, no es difícil
jerojasro@498: acumular un gran número de parches. Por ejemplo, tengo un repositorio
jerojasro@498: de parches que contiene más de 250 parches.
jerojasro@498: 
jerojasro@498: Si usted puede agrupar estos parches en categorías lógicas separadas,
jerojasro@498: usted puede almacenarlos en diferentes directorios si lo desea; MQ no
jerojasro@498: tiene problemas manejando nombres de parches que contienen separadores
jerojasro@498: de ruta.
jerojasro@498: 
jerojasro@516: \subsection{Ver el historial de un parche}
jerojasro@336: \label{mq-collab:tips:interdiff}
jerojasro@336: 
jerojasro@498: Si usted está desarrollando un conjunto de parches en un período de
jerojasro@498: tiempo grande, es una buena idea mantenerlos en un repositorio, como
jerojasro@498: se discutió en la sección~\ref{sec:mq:repo}.  Si lo hace, notará
jerojasro@516: rápidamente que usar el comando \hgcmd{diff} para mirar el historial
jerojasro@498: del repositorio no es viable. Esto es debido en parte a que usted está
jerojasro@498: mirando la segunda derivada del código real (el diff de un diff), pero
jerojasro@498: también porque MQ añade ruido al proceso al modificar las marcas de
jerojasro@498: tiempo y los nombres de directorio cuando actualiza un parche.
jerojasro@498: 
jerojasro@498: Sin embargo, usted puede usar la extensión \hgext{extdiff}, que es
jerojasro@498: provisto junto con Mercurial, para convertir un diff de dos versiones
jerojasro@498: de un parche en algo legible. Para hacer esto, usted necesitará un
jerojasro@498: paquete de un tercero llamado
jerojasro@498: \package{patchutils}~\cite{web:patchutils}.  Éste paquete provee un
jerojasro@498: comando llamado \command{interdiff}, que muestra las diferencias entre
jerojasro@498: dos diffs como un diff. Al usarlo en dos versiones del mismo diff,
jerojasro@498: genera un diff que representa el diff de la primera a la segunda
jerojasro@498: versión.
jerojasro@498: 
jerojasro@498: Usted puede habilitar la extensión \hgext{extdiff} de la manera usual,
jerojasro@498: añadiendo una línea a la sección \rcsection{extensions} de su \hgrc.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extensions]
jerojasro@336:   extdiff =
jerojasro@336: \end{codesample2}
jerojasro@498: El comando  \command{interdiff} espera recibir los nombres de dos
jerojasro@498: ficheros, pero la extensión \hgext{extdiff} le pasa un par de
jerojasro@498: directorios al programa que ejecuta, cada uno de los cuales puede
jerojasro@498: contener una cantidad arbitraria de ficheros. Por esto necesitamos un
jerojasro@498: programa pequeño que ejecute \command{interdiff} en cada par de
jerojasro@498: ficheros de estos dos directorios. Este programa está disponible como
jerojasro@498: \sfilename{hg-interdiff} en el directorio \dirname{examples} del
jerojasro@498: repositorio de código fuente que acompaña a este libro.
jerojasro@336: \excode{hg-interdiff}
jerojasro@336: 
jerojasro@498: Con el programa \sfilename{hg-interdiff} en la ruta de búsqueda de su
jerojasro@498: intérprete de comandos, puede ejecutarlo como sigue, desde dentro de
jerojasro@498: un directorio de parches MQ:
jerojasro@336: \begin{codesample2}
jerojasro@336:   hg extdiff -p hg-interdiff -r A:B my-change.patch
jerojasro@336: \end{codesample2}
jerojasro@498: Ya que usted seguramente querrá usar este comando tan largo a menudo,
jerojasro@498: puede hacer que \hgext{hgext} lo haga disponible como un comando
jerojasro@498: normal de Mercurial, editando de nuevo su \hgrc.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extdiff]
jerojasro@336:   cmd.interdiff = hg-interdiff
jerojasro@336: \end{codesample2}
jerojasro@498: Esto le indica a \hgext{hgext} que ponga a disposición un comando
jerojasro@498: \texttt{interdiff}, con lo que usted puede abreviar la invocación
jerojasro@498: anterior de \hgxcmd{extdiff}{extdiff} a algo un poco más manejable.
jerojasro@336: \begin{codesample2}
jerojasro@336:   hg interdiff -r A:B my-change.patch
jerojasro@336: \end{codesample2}
jerojasro@336: 
jerojasro@336: \begin{note}
jerojasro@498:     %TODO revisar redacción
jerojasro@498:   El comando \command{interdiff} trabaja bien sólo si los ficheros
jerojasro@498:   contra los cuales son generadas las versiones de un parche se
jerojasro@498:   mantienen iguales. Si usted crea un parche, modifica los ficheros
jerojasro@498:   subyacentes, y luego regenera el parche, \command{interdiff} podría
jerojasro@498:   no producir ningún resultado útil.
jerojasro@336: \end{note}
jerojasro@336: 
jerojasro@498: La extensión \hgext{extdiff} es útil para más que solamente mejorar la
jerojasro@498: presentación de los parches~MQ. Para leer más acerca de esto, vaya a
jerojasro@498: la sección~\ref{sec:hgext:extdiff}.
jerojasro@336: 
jerojasro@336: %%% Local Variables: 
jerojasro@336: %%% mode: latex
jerojasro@336: %%% TeX-master: "00book"
jerojasro@336: %%% End: 




