
igor@440: \chapter{Añadir funcionalidad con extensiones}
jerojasro@336: \label{chap:hgext}
jerojasro@336: 
igor@451: A pesar de que el corazón de Mercurial es muy completo desde el punto
igor@451: de vista de funcionalidad, carece de características rimbombantes
igor@451: deliberadamente.  Esta aproximación de preservar la simplicidad
igor@451: mantiene el programa sencillo tanto para mantenedores como para
igor@451: usuarios.
igor@451: 
igor@451: Si embargo Mercurial no le cierra las posibilidades a un conjunto
igor@451: inflexible de órdenes: usted puede añadir características como
igor@451: \emph{extensiones} (aveces llamadas \emph{añadidos}\ndt{plugins}).  Ya
igor@451: hemos discutido algunas de estas extensiones en capítulos anteriores:
jerojasro@336: \begin{itemize}
igor@451: \item La sección~\ref{sec:tour-merge:fetch} cubre la extensión
igor@451:   \hgext{fetch}; que combina jalar cambios y fusionarlos con los
igor@451:   cambios locales en una sola orden: \hgxcmd{fetch}{fetch}.
igor@451: \item En el capítulo~\ref{chap:hook}, cubrimos muchas extensiones que
igor@451:   son útiles en funcionalidades relacionadas con ganchos: Los
igor@451:   \hgext{acl} añaden listas de control de acceso; \hgext{bugzilla}
igor@451:   añade integración con el sistema de seguimiento de fallos Bugzilla; y
igor@451:   \hgext{notify} envía notificaciones por correo de nuevos cambios.
igor@451: \item La extensión de administración de parches MQ es tan invaluable
igor@451:   que amerita dos capítulos y un apéndice por sí misma.
igor@451:   El capítulo~\ref{chap:mq} cubre lo básico; el
igor@451:   capítulo~\ref{chap:mq-collab} discute temas avanzados; y el
igor@451:   apéndice~\ref{chap:mqref} muestra en detalle cada orden.
jerojasro@336: \end{itemize}
jerojasro@336: 
igor@451: En este capítulo cubriremos algunas extensiones adicionales
igor@451: disponibles para Mercurial, y daremos un vistazo a la maquinaria que
igor@451: necesita conocer en caso de que desee escribir una extensión.
jerojasro@336: \begin{itemize}
igor@451: \item En la sección~\ref{sec:hgext:inotify}, discutiremos la
igor@451:   posibilidad de mejorar el desempeño \emph{en gran medida} con la extensión
igor@451:   \hgext{inotify}.
jerojasro@336: \end{itemize}
jerojasro@336: 
igor@451: \section{Mejorar el desempeño con la extensión \hgext{inotify}}
jerojasro@336: \label{sec:hgext:inotify}
jerojasro@336: 
igor@451: ¿Desea lograr que las operaciones más comunmente usadas de Mercurial se
igor@451: ejecuten centenas de veces más rápido? ¡A leer!
igor@451: 
igor@451: Mercurial tiene gran desempeño bajo circunstancias normales.  Por
igor@451: ejemplo, cuando ejecuta la orden \hgcmd{status}, Mercurial tiene que
igor@451: revisar casi todos los ficheros y directorios en su repositorio de
igor@451: forma que pueda desplegar el estado de los ficheros.  Muchas otras
igor@451: órdenes tienen que hacer tal trabajo tras bambalinas;  por ejemplo la
igor@451: orden \hgcmd{diff} usa la maquinaria de estado para evitar hacer
igor@451: operaciones de comparación costosas en ficheros que obviamente no han
igor@451: cambiado.
igor@451: 
igor@451: Dado que obtener el estado de los ficheros es crucial para obtener
igor@451: buen desempeño, los autores de Mercurial han optimizado este código en
igor@451: la medida de lo posible.  Sin embargo, no puede obviarse el hecho de
igor@451: que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo
jerojasro@516: menos una costosa llamada al sistema por cada fichero administrado
igor@451: para determinar si ha cambiado desde la última vez que se consignó.
igor@451: Para un repositorio suficientemente grande, puede tardar bastante
igor@451: tiempo.
igor@451: 
igor@451: Para mostrar en números la magnitud de este efect, creé un repositorio
jerojasro@516: que contenía 150.000 ficheros administrador.  Tardó diez segundos para
igor@451: ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros
igor@451: había sido modificado.
igor@451: 
igor@451: Muchos sistemas operativos modernos contienen una facilidad de
jerojasro@516: notificación de ficheros.  Si un programa se registra con un servicio
igor@451: apropiado, el sistema operativo le notificará siempre que un fichero
igor@451: de interés haya sido creado, modificado o borrado.  En sistemas Linux,
igor@451: el componente del núcleo que lo hace se llama \texttt{inotify}.
igor@451: 
igor@451: La extensión \hgext{inotify} habla con el componente \texttt{inotify}
igor@451: del núcleo para optimizar las órdenes de \hgcmd{status}.  La extensión
igor@451: tiene dos componentes.  Un daemonio está en el fondo recibiendo
igor@451: notificaciones del subsistema \texttt{inotify}.  También escucha
igor@451: conexiones de una orden regular de Mercurial.  La extensión modifica
igor@451: el comportamiento de Mercurial de tal forma que, en lugar de revisar
igor@451: el sistema de ficheros, le pregunta al daemonio.  Dado que el daemonio
igor@451: tiene información perfecta acerca del estado del repositorio, puede
igor@451: responder instantáneamente con el resultado, evitando la necesidad de
igor@451: revisar cada directorio y fichero del repositorio.
igor@451: 
igor@451: Retomando los diez segundos que medí al ejecutar la orden
igor@451: \hgcmd{status} de Mercurial sobre un repositorio de 150.000
igor@451: ficheros. Con la extensión \hgext{inotify} habilitada, el tiempo se
igor@451: disipó a 0.1~seconds, un factor \emph{cien veces} más rápido.
igor@451: 
igor@451: Antes de continuar, tenga en cuenta algunos detalles:
jerojasro@336: \begin{itemize}
igor@451: \item La extensión \hgext{inotify} es específica de Linux.  Porque se
igor@451:   enlaza directamente con el subsistema \texttt{inotify} del núcleo
igor@451:   Linux, no funciona en otros sistemas operativos.
igor@451: \item Debería funcionar en cualquier distribución Linux a partir de
igor@451:   comienzos del 2005.  Las distribuciones más antiguas deben tener un
igor@451:   kernel sin \texttt{inotify}, o una versión de \texttt{glibc} que no
igor@451:   tiene necesariamente el soporte para la interfaz.
igor@451: \item No todos los sistemas de ficheros pueden usarse con la extensión
igor@451:   \hgext{inotify}.  Los sistemas de ficheros tales como NFS no lo
igor@451:   soportan, por ejemplo, si está corriendo Mercurial en vaios
igor@451:   sistemas, montados todos sobre el mismo sistema de ficheros en red.
igor@451:   El sistema \texttt{inotify} del kernel no tiene forma de saber
igor@451:   acerca de los cambios hechos en otro sistema.  La mayoría de
igor@451:   sistemas de ficheros locales (p.e.~ext3, XFS, ReiserFS) deberían
igor@451:   funcionar bien.
jerojasro@336: \end{itemize}
jerojasro@336: 
igor@451: Hacia mayo de 2007 la extensión \hgext{inotify} no venía de forma
igor@451: predeterminada en Mercurial\ndt{Desde el 2008 para kernels 2.6 viene
igor@451:   en Mercurial, pero no está activada de forma predeterminada}, y es
igor@451: un poco más compleja de activar que otras extensiones.  Pero la mejora
igor@451: en el desempeño bien vale la pena!
igor@451: 
igor@451: La extensión venía en dos partes: un conjunto de parches al código
igor@451: fuente de Mercurial, y una librería de interfaces de Python hacia el
igor@451: subsistema \texttt{inotify}.
jerojasro@336: \begin{note}
igor@451:   Hay \emph{dos} librerías de enlace de Python hacia \texttt{inotify}.
igor@451:   Una de ellas se llama \texttt{pyinotify}, y en algunas
igor@451:   distribuciones de Linux se encuentra como \texttt{python-inotify}.
igor@451:   Esta es la que \emph{no} necesita, puesto que tiene muchos fallos,
igor@451:   y es ineficiente para ser práctica.
jerojasro@336: \end{note}
igor@451: Para comenzar, es mejor tener una copia de Mercurial funcional
igor@451: instalada:
jerojasro@336: \begin{note}
igor@451:   Si sigue las instrucciones a continuación, estará
igor@451:   \emph{reemplazando} y sobreescribiendo cualquier instalación previa
igor@451:   de Mercurial que pudiera tener, con el código de Mercurial ``más
igor@451:   reciente y peligrosa''.  No diga que no se le advirtio!
jerojasro@336: \end{note}
jerojasro@336: \begin{enumerate}
igor@451: \item Clone el repositorio de interfaz entre Python e
igor@451:   \texttt{inotify}. Ármelo e instálelo:
jerojasro@336:   \begin{codesample4}
jerojasro@336:     hg clone http://hg.kublai.com/python/inotify
jerojasro@336:     cd inotify
jerojasro@336:     python setup.py build --force
jerojasro@336:     sudo python setup.py install --skip-build
jerojasro@336:   \end{codesample4}
igor@451: \item Clone el repositorio \dirname{crew} de Mercurial.  Clone el
igor@451:   repositorio de parches de \hgext{inotify} de forma tal que las colas
igor@451:   de Mercurial puedan aplicar los parches sobre el repositorio \dirname{crew}.
jerojasro@336:   \begin{codesample4}
jerojasro@336:     hg clone http://hg.intevation.org/mercurial/crew
jerojasro@336:     hg clone crew inotify
jerojasro@336:     hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
jerojasro@336:   \end{codesample4}
igor@451: \item Asegúrese de instalar la extensión Colas de Mercurial
igor@451:   \hgext{mq} y que estén habilitadas.  Si nunca ha usado MQ, lea la
igor@451:   sección~\ref{sec:mq:start} para poder comenzar rápidamente.
igor@451: \item Vaya al repositorio de \dirname{inotify} y aplique todos los
igor@451:   parches de \hgext{inotify} con la opción \hgxopt{mq}{qpush}{-a} de
igor@451:   la orden \hgxcmd{mq}{qpush}.
jerojasro@336:   \begin{codesample4}
jerojasro@336:     cd inotify
jerojasro@336:     hg qpush -a
jerojasro@336:   \end{codesample4}
igor@451:   Si obtiene un mensaje de error de \hgxcmd{mq}{qpush}, no debería
igor@451:   continuar.  Mejor pida ayuda.
igor@451: \item Arme e instale la versión parchada de Mercurial.
jerojasro@336:   \begin{codesample4}
jerojasro@336:     python setup.py build --force
jerojasro@336:     sudo python setup.py install --skip-build
jerojasro@336:   \end{codesample4}
jerojasro@336: \end{enumerate}
igor@451: Una vez que haya armado una versión funcional parchada de Mercurial,
igor@451: todo lo que necesita es habilitar la extensión \hgext{inotify}
igor@451: colocando una entrada en su \hgrc.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extensions]
jerojasro@336:   inotify =
jerojasro@336: \end{codesample2}
igor@451: Cuando la extensión \hgext{inotify} esté habilitada, Mercurial
igor@451: iniciará transparente y automáticamente el daemonio de estado la
igor@451: primera vez que ejecute un comando que requiera estado del
jerojasro@483: repositorio.  Ejecuta un daemonio de estado por repositorio.
igor@451: 
igor@451: El daemonio de estado se inicia silenciosamente y se ejecuta en el
igor@451: fondo. Si mira a la lista de procesos en ejecución después de
igor@451: habilitar la extensión \hgext{inotify} y ejecuta unos pocos comandos
igor@451: en diferentes repositorios, verá que hay algunos procesos de
igor@451: \texttt{hg} por ahí, esperando actualizaciones del kernel y
igor@451: solicitudes de Mercurial.
igor@451: 
igor@451: La primera vez que ejecuta un comando de Mercurial en un repositorio
igor@451: cuando tiene la extensión \hgext{inotify} habilitada, correrá casi con
igor@451: el mismo desempeño que una orden usual de Mercurial.  Esto es debido a
igor@451: que el estado del daemonio necesita aplicar una búsqueda normal sobre
igor@451: el estado para poder tener una línea de partida frente a la cual
igor@451: aplicar posteriormente actualizaciones del núcleo.  De todas formas,
igor@451: \emph{todo} comando posterior que haga cualquier clase de revisión del
igor@451: estado debería ser notablemente más rápido en repositorios con incluso
igor@451: un tamaño modesto.  Aún mejor, a medida que su repositorio sea más
igor@451: grande, mejor desempeño verá.  El daemonio \hgext{inotify} hace
igor@451: operaciones de estado de forma casi instantánea en repositorios de
igor@451: todos los tamaños!
igor@451: 
igor@451: Si lo desea, puede iniciar manualmente un daemonio de estado con la orden
igor@451: \hgxcmd{inotify}{inserve}.  Esto le da un control un poco más fino
igor@451: acerca de cómo debería ejecutarse el daemonio.  Esta orden solamente
igor@451: estará disponible cuando haya habilitado la extensión \hgext{inotify}.
igor@451: 
igor@451: Cuando esté usando la extensión \hgext{inotify},
igor@451: \emph{no debería ver diferencia} en el comportamiento de Mercurial,
igor@451: con la única excepción de que los comandos relacionados con el estado
igor@451: deberían ejectuarse mucho más rápido que como solían hacerlo.  Debería
igor@451: esperar específicamente que las órdenes no deberían ofrecer salidas
igor@451: distintas; ni ofrecer resultados diferentes.  Si alguna de estas
igor@451: situaciones ocurre, por favor reporte el fallo.
igor@451: 
igor@451: \section{Soporte flexible de diff con la extensión \hgext{extdiff}}
jerojasro@336: \label{sec:hgext:extdiff}
jerojasro@336: 
igor@451: La orden predeterminada \hgcmd{diff} de Mercurial despliega diffs en
igor@451: texto plano unificadas.
jerojasro@336: \interaction{extdiff.diff}
igor@451: Si dese emplear una herramienta externa para desplegar las
igor@451: modificaciones, querrá usar la extensión \hgext{extdiff}.  Esta le
igor@451: permitirá usar por ejemplo una herramienta gráfica de diff.
igor@451: 
igor@451: La extensión \hgext{extdiff} viene con Mercurial, y es fácil
jerojasro@486: configurar.  En la sección \rcsection{extensions} de su \hgrc,
igor@451: basta con añadir una entrada de una línea para habilitar la extensión.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extensions]
jerojasro@336:   extdiff =
jerojasro@336: \end{codesample2}
igor@451: Esto introduce una orden llamada \hgxcmd{extdiff}{extdiff}, que de
igor@451: forma predeterminada usa su orden del sistema \command{diff} para
igor@451: generar un diff unificado de la misma forma que lo hace el comando
igor@451: predeterminado \hgcmd{diff}.
jerojasro@336: \interaction{extdiff.extdiff}
igor@451: El resultado no será exactamente el mismo que con la orden interna
igor@451: \hgcmd{diff}, puesto que la salida de \command{diff} varía de un
igor@451: sistema a otro, incluso pasando las mismas opciones.
jerojasro@336: 
igor@453: Como lo indican las líneas``\texttt{making snapshot}'', la orden
igor@453: \hgxcmd{extdiff}{extdiff} funciona creando dos instantáneas de su
igor@453: árbol de fuentes.  La primera instantánea es la revisión fuente; la
igor@453: segunda es la revisión objetivo del directorio de trabajo.  La orden
igor@453: \hgxcmd{extdiff}{extdiff} genera estas instantáneas en un directorio
igor@453: temporal, pasa el nombre de cada directorio a un visor de diffs
igor@453: temporal y borra los directorios temporales.  Por cuestiones de
igor@453: eficiencia solamente genera instantáneas de los directorios y ficheros
igor@453: que han cambiado entre dos revisiones.
igor@453: 
igor@453: Los nombres de los directorios de instantáneas tienen los mismos
igor@453: nombres base de su repositorio.  Si su repositorio tiene por ruta
igor@453: \dirname{/quux/bar/foo}, \dirname{foo} será el nombre de cada
igor@453: instantánea de directorio.  Cada instantánea de directorio tiene sus
igor@453: identificadores de conjuntos de cambios al final del nombre en caso de
igor@453: que sea apropiado.  Si una instantánea viene de la revisión
igor@453: \texttt{a631aca1083f}, el directorio se llamará
igor@453: \dirname{foo.a631aca1083f}.  Una instantánea del directorio de trabajo
igor@453: no tendrá el identificador del conjunto de cambios, y por lo tanto
igor@453: será solamente \dirname{foo} en este ejemplo.  Para ver cómo luce en
igor@453: la práctica, veamos de nuevo el ejemplo \hgxcmd{extdiff}{extdiff}
igor@453: antes mencionado.  Tenga en cuenta que los diffs tienen los nombres de
igor@453: las instantáneas de directorio dentro de su encabezado.
igor@453: 
igor@453: La orden \hgxcmd{extdiff}{extdiff} acepta dos opciones importantes.
igor@453: La opción \hgxopt{extdiff}{extdiff}{-p} le permite elegir un programa
igor@453: para ver las diferencias, en lugar de \command{diff}.  Con la opción
igor@453: \hgxopt{extdiff}{extdiff}{-o} puede cambiar las opciones que
jerojasro@520: \hgxcmd{extdiff}{extdiff} pasa a tal programa (de forma predeterminada
igor@453: las opciones son``\texttt{-Npru}'', que tienen sentido únicamente si
igor@453: está usando \command{diff}).  En otros aspectos, la orden
igor@453: \hgxcmd{extdiff}{extdiff} actúa de forma similar a como lo hace la
igor@453: orden \hgcmd{diff} de Mercurial: usted usa los mismos nombres de
igor@453: opciones, sintaxis y argumentos para especificar las revisiones y los
igor@453: ficheros que quiere, y así sucesivamente.
igor@453: 
igor@453: Por ejemplo, para ejecutar la orden usual del sistema \command{diff},
igor@453: para lograr que se generen diferencias de contexto (con la opción
igor@453: \cmdopt{diff}{-c}) en lugar de diferencias unificadas, y cinco líneas
jerojasro@520: de contexto en lugar de las tres predeterminadas (pasando \texttt{5}
igor@453: como argumento a la opción \cmdopt{diff}{-C}).
jerojasro@336: \interaction{extdiff.extdiff-ctx}
jerojasro@336: 
igor@453: Es sencillo lanzar unas herramienta usual de diferencias.  Para lanzar
igor@453: el visor \command{kdiff3}:
jerojasro@336: \begin{codesample2}
jerojasro@336:   hg extdiff -p kdiff3 -o ''
jerojasro@336: \end{codesample2}
jerojasro@336: 
igor@453: Si su orden para visualizar diferencias no puede tratar con
igor@453: directorios, puede usar un poco de scripting para lograrlo.  Un
igor@453: ejemplo de un script con la extensión \hgext{mq} junto con la orden
igor@453: \command{interdiff} está en la sección~\ref{mq-collab:tips:interdiff}.
igor@453: 
igor@453: \subsection{Definición de alias de comandos}
jerojasro@336: 
igor@454: Acordarse de todas las opciones de las órdenes
igor@454: \hgxcmd{extdiff}{extdiff} y el visor de diferencias de su preferencia
igor@454: puede ser dispendioso, y por lo tanto la extensión \hgext{extdiff} le
igor@454: permite definir \emph{nuevas} órdenes que invocarán su visor de
igor@454: diferencias con las opciones exactas.
igor@454: 
igor@454: Basta con editar su fichero \hgrc, y añadir una sección llamada
igor@454: \rcsection{extdiff}.  Dentro de esta sección puede definir varias
igor@454: órdenes. Mostraremos como añadir la orden \texttt{kdiff3}.  Después de
igor@454: definido, puede teclear ``\texttt{hg kdiff3}'' y la extensión a
igor@454: \hgext{extdiff} ejecutará la orden \command{kdiff3}.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extdiff]
jerojasro@336:   cmd.kdiff3 =
jerojasro@336: \end{codesample2}
igor@454: Si deja vacía la porción derecha de la definición, como en el ejemplo,
igor@454: la extensión \hgext{extdiff} usa el nombre de la orden se definirá
igor@454: como el nombre del programa externo a ejecutar.  Pero tales nombres no
igor@454: tienen por qué ser iguales.  Definimos ahora la orden llamada
igor@454:  ``\texttt{hg wibble}'', que ejecuta \command{kdiff3}.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extdiff]
jerojasro@336:   cmd.wibble = kdiff3
jerojasro@336: \end{codesample2}
jerojasro@336: 
igor@454: También puede especificar las opciones predeterminadas con las cuales
igor@454: desea invocar el visor de diferencias.  Se usa el prefijo ``\texttt{opts.}'',
igor@454: seguido por el nombre de la orden a la cual se aplican las opciones.
igor@454: En este ejemplos se define la orden ``\texttt{hg vimdiff}'' que
igor@454: ejecuta la extensión \texttt{DirDiff} del editor \command{vim}.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extdiff]  
jerojasro@336:   cmd.vimdiff = vim
jerojasro@336:   opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
jerojasro@336: \end{codesample2}
jerojasro@336: 
igor@454: \section{Uso de la extensión \hgext{transplant} para seleccionar}
jerojasro@336: \label{sec:hgext:transplant}
jerojasro@336: 
jerojasro@336: Need to have a long chat with Brendan about this.
jerojasro@336: 
igor@454: \section{Enviar cambios vía correo electrónico con la extensión \hgext{patchbomb}}
jerojasro@336: \label{sec:hgext:patchbomb}
jerojasro@336: 
igor@454: Varios proyectos tienen la cultura de ``revisión de cambios'', en la
igor@454: cual la gente envía sus modificaciones a una lista de correo para que
igor@454: otros las lean y comenten antes de consignar la versión final a un
igor@454: repositorio compartido.  Algunos proyectos tienen personas que actúan
igor@454: como cancerberos; ellos aplican los cambios de otras personas a un
igor@454: repositorio para aquellos que no tienen acceso.
igor@454: 
igor@454: Mercurial facilita enviar cambios por correo para revisión o
igor@454: aplicación gracias a su extensión \hgext{patchbomb}.  La extensión es
igor@454: tan popular porque los cambios se formatean como parches y es usual
igor@454: que se envía un conjunto de cambios por cada correo.  Enviar una gran
igor@454: cantidad de cambios por correos se llama por tanto ``bombardear'' el
igor@454: buzón de entrada del destinatario, de ahí su nombre ``bombardeo de
igor@454: parches''.
jerojasro@336: 
igor@455: Como es usual, la configuración básica de la extensión
igor@455: \hgext{patchbomb} consta de una o dos líneas en su \hgrc.
jerojasro@336: \begin{codesample2}
jerojasro@336:   [extensions]
jerojasro@336:   patchbomb =
jerojasro@336: \end{codesample2}
igor@455: Cuando haya habilitado la extensión, dispondrá de una nueva orden,
igor@455: llamada \hgxcmd{patchbomb}{email}.
igor@455: 
igor@455: La forma mejor y más segura para invocar la orden
igor@455: \hgxcmd{patchbomb}{email} es ejecutarla \emph{siempre} con la opción
igor@455: \hgxopt{patchbomb}{email}{-n}; que le mostrará lo que la orden
igor@455: \emph{enviaría}, sin enviar nada.  Una vez que haya dado un vistazo a
igor@455: los cambios y verificado que está enviando los correctos, puede volver
igor@455: a ejecutar la misma orden, sin la opción \hgxopt{patchbomb}{email}{-n}.
igor@455: 
igor@455: La orden \hgxcmd{patchbomb}{email} acepta la misma clase de sintaxis
igor@455: de revisiones como cualquier otra orden de Mercurial.  Por ejemplo,
igor@455: enviará todas las revisiones entre la 7 y la \texttt{punta}, inclusive.
jerojasro@336: \begin{codesample2}
jerojasro@336:   hg email -n 7:tip
jerojasro@336: \end{codesample2}
igor@455: También puede especificar un \emph{repositorio} para comparar.  Si
igor@455: indica un repositoro sin revisiones, la orden \hgxcmd{patchbomb}{email}
igor@455: enviará todas las revisiones en el repositorio local que no están
igor@455: presentes en el repositorio remoto.  Si especifica revisiones
jerojasro@520: adicionalmente o el nombre de una rama (la última con la opción
igor@455: \hgxopt{patchbomb}{email}{-b}), respetará las revisiones enviadas.
igor@455: 
igor@455: Ejecutar la orden \hgxcmd{patchbomb}{email} sin los nombres de
igor@455: aquellas personas a las cuales desea enviar el correo es completamente
igor@455: seguro: si lo hace, solicitará tales valores de forma interactiva.
igor@455: (Si está usando Linux o un sistema tipo Unix, tendrá capacidades
igor@455: estilo--\texttt{readline} aumentadas cuando ingrese tales encabezados,
igor@455: lo cual es sumamente útil.)
igor@455: 
igor@455: Cuando envíe una sola revisión, la orden \hgxcmd{patchbomb}{email}
igor@455: de forma predeterminada usará la primera línea de descripción del
igor@455: conjunto de cambios como el tema del único mensaje que se enviará.
igor@455: 
igor@455: Si envía varias revisiones, la orden \hgxcmd{patchbomb}{email} enviará
jerojasro@525: normalmente un mensaje por conjunto de cambios. Colocará como
igor@455: prefacio un mensaje introductorio en el cual usted debería describir
igor@455: el propósito de la serie de cambios que está enviando.
igor@455: 
igor@455: \subsection{Cambiar el comportamiento de las bombas de parches}
igor@455: 
igor@455: Cada proyecto tiene sus propias convenciones para enviar cambios en un
igor@455: correo electrónico; la extensión \hgext{patchbomb} intenta acomodarse
igor@455: a diferentes variaciones gracias a las opciones de la línea de órdenes:
jerojasro@336: \begin{itemize}
igor@455: \item Puede escribir un tema para el mensaje introductorio en la línea
igor@455:   de órdenes con la opciń \hgxopt{patchbomb}{email}{-s}.  Toma un
igor@455:   argumento: el tema del mensaje a usar.
igor@455: \item Para cambiar el correo electrónico del campo del cual se
igor@455:   origina, use la opción \hgxopt{patchbomb}{email}{-f}.  Toma un
igor@455:   argumento, el correo electrónico a usar.
igor@455: \item El comportamiento predeterminado es enviar diferencias
igor@455:   unificadas (consulte la sección~\ref{sec:mq:patch} si desea una
igor@455:   descripción del formato), una por mensaje.  Puede enviar un conjunto
igor@455:   binario\ndt{binary bundle} con la opción \hgxopt{patchbomb}{email}{-b}.
igor@455: \item Las diferencias unificadas están precedidas por un encabezado de
igor@455:   metadatos.  Puede omitirlo, y enviar diferencias sin adornos con la
igor@455:   opción \hgxopt{patchbomb}{email}{--plain}.
igor@455: \item Las diferencias usualmente se envían ``en línea'', como parte
igor@455:   del cuerpo del mensaje con la descripción del parche.  Que facilita a
igor@455:   a la mayor cantidad de lectores citar y responder partes de un diff,
igor@455:   dado que algunos clientes de correo solamente citarán la primera
igor@455:   parte MIME del cuerpo de un mensaje.  Si prefiere enviar la
igor@455:   descripción y el diff en partes separadas del cuerpo, use la opción
igor@455:   \hgxopt{patchbomb}{email}{-a}.
igor@455: \item En lugar de enviar mensajes de correo puede escribirlos a un
igor@455:   fichero con formato-\texttt{mbox}- con la opción
igor@455:   \hgxopt{patchbomb}{email}{-m}.  La opción recibe un argumento, el
igor@455:   nombre del fichero en el cual escribir.
igor@455: \item Si desea añadir un resumen con formato-\command{diffstat} en
igor@455:   cada parche, y uno como mensaje introductorio, use la opción
igor@455:   \hgxopt{patchbomb}{email}{-d}.  La orden \command{diffstat}
igor@455:   despliega una tabla que contiene el nombre de cada fichero parchado,
igor@455:   el número de líneas afectadas, y un historgrama mostrando cuánto ha
igor@455:   sido modificado cada fichero.  Lo cual ofrece a los lectores una
igor@455:   mirada cuantitativa de cuan complejo es el parche.
jerojasro@336: \end{itemize}
jerojasro@336: 
jerojasro@336: %%% Local Variables: 
jerojasro@336: %%% mode: latex
jerojasro@336: %%% TeX-master: "00book"
jerojasro@336: %%% End: 




