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@336: \subsection{The art of writing backport patches} jerojasro@336: jerojasro@336: Using MQ, writing a backport patch is a simple process. All such a jerojasro@336: patch has to do is modify a piece of code that uses a kernel feature jerojasro@336: not present in the older version of the kernel, so that the driver jerojasro@336: continues to work correctly under that older version. jerojasro@336: jerojasro@336: A useful goal when writing a good backport patch is to make your code jerojasro@336: look as if it was written for the older version of the kernel you're jerojasro@336: targeting. The less obtrusive the patch, the easier it will be to jerojasro@336: understand and maintain. If you're writing a collection of backport jerojasro@336: patches to avoid the ``rat's nest'' effect of lots of jerojasro@336: \texttt{\#ifdef}s (hunks of source code that are only used jerojasro@336: conditionally) in your code, don't introduce version-dependent jerojasro@336: \texttt{\#ifdef}s into the patches. Instead, write several patches, jerojasro@336: each of which makes unconditional changes, and control their jerojasro@336: application using guards. jerojasro@336: jerojasro@336: There are two reasons to divide backport patches into a distinct jerojasro@336: group, away from the ``regular'' patches whose effects they modify. jerojasro@336: The first is that intermingling the two makes it more difficult to use jerojasro@336: a tool like the \hgext{patchbomb} extension to automate the process of jerojasro@336: submitting the patches to an upstream maintainer. The second is that jerojasro@336: a backport patch could perturb the context in which a subsequent jerojasro@336: regular patch is applied, making it impossible to apply the regular jerojasro@336: patch cleanly \emph{without} the earlier backport patch already being jerojasro@336: applied. jerojasro@336: jerojasro@336: \section{Useful tips for developing with MQ} jerojasro@336: jerojasro@336: \subsection{Organising patches in directories} jerojasro@336: jerojasro@336: If you're working on a substantial project with MQ, it's not difficult jerojasro@336: to accumulate a large number of patches. For example, I have one jerojasro@336: patch repository that contains over 250 patches. jerojasro@336: jerojasro@336: If you can group these patches into separate logical categories, you jerojasro@336: can if you like store them in different directories; MQ has no jerojasro@336: problems with patch names that contain path separators. jerojasro@336: jerojasro@336: \subsection{Viewing the history of a patch} jerojasro@336: \label{mq-collab:tips:interdiff} jerojasro@336: jerojasro@336: If you're developing a set of patches over a long time, it's a good jerojasro@336: idea to maintain them in a repository, as discussed in jerojasro@336: section~\ref{sec:mq:repo}. If you do so, you'll quickly discover that jerojasro@336: using the \hgcmd{diff} command to look at the history of changes to a jerojasro@336: patch is unworkable. This is in part because you're looking at the jerojasro@336: second derivative of the real code (a diff of a diff), but also jerojasro@336: because MQ adds noise to the process by modifying time stamps and jerojasro@336: directory names when it updates a patch. jerojasro@336: jerojasro@336: However, you can use the \hgext{extdiff} extension, which is bundled jerojasro@336: with Mercurial, to turn a diff of two versions of a patch into jerojasro@336: something readable. To do this, you will need a third-party package jerojasro@336: called \package{patchutils}~\cite{web:patchutils}. This provides a jerojasro@336: command named \command{interdiff}, which shows the differences between jerojasro@336: two diffs as a diff. Used on two versions of the same diff, it jerojasro@336: generates a diff that represents the diff from the first to the second jerojasro@336: version. jerojasro@336: jerojasro@336: You can enable the \hgext{extdiff} extension in the usual way, by jerojasro@336: adding a line to the \rcsection{extensions} section of your \hgrc. jerojasro@336: \begin{codesample2} jerojasro@336: [extensions] jerojasro@336: extdiff = jerojasro@336: \end{codesample2} jerojasro@336: The \command{interdiff} command expects to be passed the names of two jerojasro@336: files, but the \hgext{extdiff} extension passes the program it runs a jerojasro@336: pair of directories, each of which can contain an arbitrary number of jerojasro@336: files. We thus need a small program that will run \command{interdiff} jerojasro@336: on each pair of files in these two directories. This program is jerojasro@336: available as \sfilename{hg-interdiff} in the \dirname{examples} jerojasro@336: directory of the source code repository that accompanies this book. jerojasro@336: \excode{hg-interdiff} jerojasro@336: jerojasro@336: With the \sfilename{hg-interdiff} program in your shell's search path, jerojasro@336: you can run it as follows, from inside an MQ patch directory: jerojasro@336: \begin{codesample2} jerojasro@336: hg extdiff -p hg-interdiff -r A:B my-change.patch jerojasro@336: \end{codesample2} jerojasro@336: Since you'll probably want to use this long-winded command a lot, you jerojasro@336: can get \hgext{hgext} to make it available as a normal Mercurial jerojasro@336: command, again by editing your \hgrc. jerojasro@336: \begin{codesample2} jerojasro@336: [extdiff] jerojasro@336: cmd.interdiff = hg-interdiff jerojasro@336: \end{codesample2} jerojasro@336: This directs \hgext{hgext} to make an \texttt{interdiff} command jerojasro@336: available, so you can now shorten the previous invocation of jerojasro@336: \hgxcmd{extdiff}{extdiff} to something a little more wieldy. 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@336: The \command{interdiff} command works well only if the underlying jerojasro@336: files against which versions of a patch are generated remain the jerojasro@336: same. If you create a patch, modify the underlying files, and then jerojasro@336: regenerate the patch, \command{interdiff} may not produce useful jerojasro@336: output. jerojasro@336: \end{note} jerojasro@336: jerojasro@336: The \hgext{extdiff} extension is useful for more than merely improving jerojasro@336: the presentation of MQ~patches. To read more about it, go to jerojasro@336: section~\ref{sec:hgext:extdiff}. jerojasro@336: jerojasro@336: %%% Local Variables: jerojasro@336: %%% mode: latex jerojasro@336: %%% TeX-master: "00book" jerojasro@336: %%% End: