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: