1.1 --- a/es/Leame.1st	Sat Dec 13 12:33:15 2008 -0500
     1.2 +++ b/es/Leame.1st	Sat Dec 13 23:55:07 2008 -0500
     1.3 @@ -107,7 +107,7 @@
     1.4  || filenames.tex   || Javier Rojas  ||     72%    || 27/11/2008 ||             ||
     1.5  || hook.tex        || Javier Rojas  ||     26%    || 01/12/2008 ||             ||
     1.6  || mq.tex          || Igor Támara   ||    100%    || 06/12/2008 ||  13/12/2008 ||
     1.7 -|| hgext.tex       || Igor Támara   ||      0%    ||            ||             ||
     1.8 +|| hgext.tex       || Igor Támara   ||     50%    || 13/12/2008 ||             ||
     1.9  || template.tex    ||               ||            ||            ||             ||
    1.10  || mq-collab.tex   ||               ||            ||            ||             ||
    1.11  || mq-ref.tex      ||               ||            ||            ||             ||

     2.1 --- a/es/hgext.tex	Sat Dec 13 12:33:15 2008 -0500
     2.2 +++ b/es/hgext.tex	Sat Dec 13 23:55:07 2008 -0500
     2.3 @@ -1,230 +1,240 @@
     2.4  \chapter{Añadir funcionalidad con extensiones}
     2.5  \label{chap:hgext}
     2.6  
     2.7 -While the core of Mercurial is quite complete from a functionality
     2.8 -standpoint, it's deliberately shorn of fancy features.  This approach
     2.9 -of preserving simplicity keeps the software easy to deal with for both
    2.10 -maintainers and users.
    2.11 -
    2.12 -However, Mercurial doesn't box you in with an inflexible command set:
    2.13 -you can add features to it as \emph{extensions} (sometimes known as
    2.14 -\emph{plugins}).  We've already discussed a few of these extensions in
    2.15 -earlier chapters.
    2.16 +A pesar de que el corazón de Mercurial es muy completo desde el punto
    2.17 +de vista de funcionalidad, carece de características rimbombantes
    2.18 +deliberadamente.  Esta aproximación de preservar la simplicidad
    2.19 +mantiene el programa sencillo tanto para mantenedores como para
    2.20 +usuarios.
    2.21 +
    2.22 +Si embargo Mercurial no le cierra las posibilidades a un conjunto
    2.23 +inflexible de órdenes: usted puede añadir características como
    2.24 +\emph{extensiones} (aveces llamadas \emph{añadidos}\ndt{plugins}).  Ya
    2.25 +hemos discutido algunas de estas extensiones en capítulos anteriores:
    2.26  \begin{itemize}
    2.27 -\item Section~\ref{sec:tour-merge:fetch} covers the \hgext{fetch}
    2.28 -  extension; this combines pulling new changes and merging them with
    2.29 -  local changes into a single command, \hgxcmd{fetch}{fetch}.
    2.30 -\item In chapter~\ref{chap:hook}, we covered several extensions that
    2.31 -  are useful for hook-related functionality: \hgext{acl} adds access
    2.32 -  control lists; \hgext{bugzilla} adds integration with the Bugzilla
    2.33 -  bug tracking system; and \hgext{notify} sends notification emails on
    2.34 -  new changes.
    2.35 -\item The Mercurial Queues patch management extension is so invaluable
    2.36 -  that it merits two chapters and an appendix all to itself.
    2.37 -  Chapter~\ref{chap:mq} covers the basics;
    2.38 -  chapter~\ref{chap:mq-collab} discusses advanced topics; and
    2.39 -  appendix~\ref{chap:mqref} goes into detail on each command.
    2.40 +\item La sección~\ref{sec:tour-merge:fetch} cubre la extensión
    2.41 +  \hgext{fetch}; que combina jalar cambios y fusionarlos con los
    2.42 +  cambios locales en una sola orden: \hgxcmd{fetch}{fetch}.
    2.43 +\item En el capítulo~\ref{chap:hook}, cubrimos muchas extensiones que
    2.44 +  son útiles en funcionalidades relacionadas con ganchos: Los
    2.45 +  \hgext{acl} añaden listas de control de acceso; \hgext{bugzilla}
    2.46 +  añade integración con el sistema de seguimiento de fallos Bugzilla; y
    2.47 +  \hgext{notify} envía notificaciones por correo de nuevos cambios.
    2.48 +\item La extensión de administración de parches MQ es tan invaluable
    2.49 +  que amerita dos capítulos y un apéndice por sí misma.
    2.50 +  El capítulo~\ref{chap:mq} cubre lo básico; el
    2.51 +  capítulo~\ref{chap:mq-collab} discute temas avanzados; y el
    2.52 +  apéndice~\ref{chap:mqref} muestra en detalle cada orden.
    2.53  \end{itemize}
    2.54  
    2.55 -In this chapter, we'll cover some of the other extensions that are
    2.56 -available for Mercurial, and briefly touch on some of the machinery
    2.57 -you'll need to know about if you want to write an extension of your
    2.58 -own.
    2.59 +En este capítulo cubriremos algunas extensiones adicionales
    2.60 +disponibles para Mercurial, y daremos un vistazo a la maquinaria que
    2.61 +necesita conocer en caso de que desee escribir una extensión.
    2.62  \begin{itemize}
    2.63 -\item In section~\ref{sec:hgext:inotify}, we'll discuss the
    2.64 -  possibility of \emph{huge} performance improvements using the
    2.65 -  \hgext{inotify} extension.
    2.66 +\item En la sección~\ref{sec:hgext:inotify}, discutiremos la
    2.67 +  posibilidad de mejorar el desempeño \emph{en gran medida} con la extensión
    2.68 +  \hgext{inotify}.
    2.69  \end{itemize}
    2.70  
    2.71 -\section{Improve performance with the \hgext{inotify} extension}
    2.72 +\section{Mejorar el desempeño con la extensión \hgext{inotify}}
    2.73  \label{sec:hgext:inotify}
    2.74  
    2.75 -Are you interested in having some of the most common Mercurial
    2.76 -operations run as much as a hundred times faster?  Read on!
    2.77 -
    2.78 -Mercurial has great performance under normal circumstances.  For
    2.79 -example, when you run the \hgcmd{status} command, Mercurial has to
    2.80 -scan almost every directory and file in your repository so that it can
    2.81 -display file status.  Many other Mercurial commands need to do the
    2.82 -same work behind the scenes; for example, the \hgcmd{diff} command
    2.83 -uses the status machinery to avoid doing an expensive comparison
    2.84 -operation on files that obviously haven't changed.
    2.85 -
    2.86 -Because obtaining file status is crucial to good performance, the
    2.87 -authors of Mercurial have optimised this code to within an inch of its
    2.88 -life.  However, there's no avoiding the fact that when you run
    2.89 -\hgcmd{status}, Mercurial is going to have to perform at least one
    2.90 -expensive system call for each managed file to determine whether it's
    2.91 -changed since the last time Mercurial checked.  For a sufficiently
    2.92 -large repository, this can take a long time.
    2.93 -
    2.94 -To put a number on the magnitude of this effect, I created a
    2.95 -repository containing 150,000 managed files.  I timed \hgcmd{status}
    2.96 -as taking ten seconds to run, even when \emph{none} of those files had
    2.97 -been modified.
    2.98 -
    2.99 -Many modern operating systems contain a file notification facility.
   2.100 -If a program signs up to an appropriate service, the operating system
   2.101 -will notify it every time a file of interest is created, modified, or
   2.102 -deleted.  On Linux systems, the kernel component that does this is
   2.103 -called \texttt{inotify}.
   2.104 -
   2.105 -Mercurial's \hgext{inotify} extension talks to the kernel's
   2.106 -\texttt{inotify} component to optimise \hgcmd{status} commands.  The
   2.107 -extension has two components.  A daemon sits in the background and
   2.108 -receives notifications from the \texttt{inotify} subsystem.  It also
   2.109 -listens for connections from a regular Mercurial command.  The
   2.110 -extension modifies Mercurial's behaviour so that instead of scanning
   2.111 -the filesystem, it queries the daemon.  Since the daemon has perfect
   2.112 -information about the state of the repository, it can respond with a
   2.113 -result instantaneously, avoiding the need to scan every directory and
   2.114 -file in the repository.
   2.115 -
   2.116 -Recall the ten seconds that I measured plain Mercurial as taking to
   2.117 -run \hgcmd{status} on a 150,000 file repository.  With the
   2.118 -\hgext{inotify} extension enabled, the time dropped to 0.1~seconds, a
   2.119 -factor of \emph{one hundred} faster.
   2.120 -
   2.121 -Before we continue, please pay attention to some caveats.
   2.122 +¿Desea lograr que las operaciones más comunmente usadas de Mercurial se
   2.123 +ejecuten centenas de veces más rápido? ¡A leer!
   2.124 +
   2.125 +Mercurial tiene gran desempeño bajo circunstancias normales.  Por
   2.126 +ejemplo, cuando ejecuta la orden \hgcmd{status}, Mercurial tiene que
   2.127 +revisar casi todos los ficheros y directorios en su repositorio de
   2.128 +forma que pueda desplegar el estado de los ficheros.  Muchas otras
   2.129 +órdenes tienen que hacer tal trabajo tras bambalinas;  por ejemplo la
   2.130 +orden \hgcmd{diff} usa la maquinaria de estado para evitar hacer
   2.131 +operaciones de comparación costosas en ficheros que obviamente no han
   2.132 +cambiado.
   2.133 +
   2.134 +Dado que obtener el estado de los ficheros es crucial para obtener
   2.135 +buen desempeño, los autores de Mercurial han optimizado este código en
   2.136 +la medida de lo posible.  Sin embargo, no puede obviarse el hecho de
   2.137 +que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo
   2.138 +menos una costosa llamada al sistema por cada archivo administrado
   2.139 +para determinar si ha cambiado desde la última vez que se consignó.
   2.140 +Para un repositorio suficientemente grande, puede tardar bastante
   2.141 +tiempo.
   2.142 +
   2.143 +Para mostrar en números la magnitud de este efect, creé un repositorio
   2.144 +que contenía 150.000 archivos administrador.  Tardó diez segundos para
   2.145 +ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros
   2.146 +había sido modificado.
   2.147 +
   2.148 +Muchos sistemas operativos modernos contienen una facilidad de
   2.149 +notificación de archivos.  Si un programa se registra con un servicio
   2.150 +apropiado, el sistema operativo le notificará siempre que un fichero
   2.151 +de interés haya sido creado, modificado o borrado.  En sistemas Linux,
   2.152 +el componente del núcleo que lo hace se llama \texttt{inotify}.
   2.153 +
   2.154 +La extensión \hgext{inotify} habla con el componente \texttt{inotify}
   2.155 +del núcleo para optimizar las órdenes de \hgcmd{status}.  La extensión
   2.156 +tiene dos componentes.  Un daemonio está en el fondo recibiendo
   2.157 +notificaciones del subsistema \texttt{inotify}.  También escucha
   2.158 +conexiones de una orden regular de Mercurial.  La extensión modifica
   2.159 +el comportamiento de Mercurial de tal forma que, en lugar de revisar
   2.160 +el sistema de ficheros, le pregunta al daemonio.  Dado que el daemonio
   2.161 +tiene información perfecta acerca del estado del repositorio, puede
   2.162 +responder instantáneamente con el resultado, evitando la necesidad de
   2.163 +revisar cada directorio y fichero del repositorio.
   2.164 +
   2.165 +Retomando los diez segundos que medí al ejecutar la orden
   2.166 +\hgcmd{status} de Mercurial sobre un repositorio de 150.000
   2.167 +ficheros. Con la extensión \hgext{inotify} habilitada, el tiempo se
   2.168 +disipó a 0.1~seconds, un factor \emph{cien veces} más rápido.
   2.169 +
   2.170 +Antes de continuar, tenga en cuenta algunos detalles:
   2.171  \begin{itemize}
   2.172 -\item The \hgext{inotify} extension is Linux-specific.  Because it
   2.173 -  interfaces directly to the Linux kernel's \texttt{inotify}
   2.174 -  subsystem, it does not work on other operating systems.
   2.175 -\item It should work on any Linux distribution that was released after
   2.176 -  early~2005.  Older distributions are likely to have a kernel that
   2.177 -  lacks \texttt{inotify}, or a version of \texttt{glibc} that does not
   2.178 -  have the necessary interfacing support.
   2.179 -\item Not all filesystems are suitable for use with the
   2.180 -  \hgext{inotify} extension.  Network filesystems such as NFS are a
   2.181 -  non-starter, for example, particularly if you're running Mercurial
   2.182 -  on several systems, all mounting the same network filesystem.  The
   2.183 -  kernel's \texttt{inotify} system has no way of knowing about changes
   2.184 -  made on another system.  Most local filesystems (e.g.~ext3, XFS,
   2.185 -  ReiserFS) should work fine.
   2.186 +\item La extensión \hgext{inotify} es específica de Linux.  Porque se
   2.187 +  enlaza directamente con el subsistema \texttt{inotify} del núcleo
   2.188 +  Linux, no funciona en otros sistemas operativos.
   2.189 +\item Debería funcionar en cualquier distribución Linux a partir de
   2.190 +  comienzos del 2005.  Las distribuciones más antiguas deben tener un
   2.191 +  kernel sin \texttt{inotify}, o una versión de \texttt{glibc} que no
   2.192 +  tiene necesariamente el soporte para la interfaz.
   2.193 +\item No todos los sistemas de ficheros pueden usarse con la extensión
   2.194 +  \hgext{inotify}.  Los sistemas de ficheros tales como NFS no lo
   2.195 +  soportan, por ejemplo, si está corriendo Mercurial en vaios
   2.196 +  sistemas, montados todos sobre el mismo sistema de ficheros en red.
   2.197 +  El sistema \texttt{inotify} del kernel no tiene forma de saber
   2.198 +  acerca de los cambios hechos en otro sistema.  La mayoría de
   2.199 +  sistemas de ficheros locales (p.e.~ext3, XFS, ReiserFS) deberían
   2.200 +  funcionar bien.
   2.201  \end{itemize}
   2.202  
   2.203 -The \hgext{inotify} extension is not yet shipped with Mercurial as of
   2.204 -May~2007, so it's a little more involved to set up than other
   2.205 -extensions.  But the performance improvement is worth it!
   2.206 -
   2.207 -The extension currently comes in two parts: a set of patches to the
   2.208 -Mercurial source code, and a library of Python bindings to the
   2.209 -\texttt{inotify} subsystem.
   2.210 +Hacia mayo de 2007 la extensión \hgext{inotify} no venía de forma
   2.211 +predeterminada en Mercurial\ndt{Desde el 2008 para kernels 2.6 viene
   2.212 +  en Mercurial, pero no está activada de forma predeterminada}, y es
   2.213 +un poco más compleja de activar que otras extensiones.  Pero la mejora
   2.214 +en el desempeño bien vale la pena!
   2.215 +
   2.216 +La extensión venía en dos partes: un conjunto de parches al código
   2.217 +fuente de Mercurial, y una librería de interfaces de Python hacia el
   2.218 +subsistema \texttt{inotify}.
   2.219  \begin{note}
   2.220 -  There are \emph{two} Python \texttt{inotify} binding libraries.  One
   2.221 -  of them is called \texttt{pyinotify}, and is packaged by some Linux
   2.222 -  distributions as \texttt{python-inotify}.  This is \emph{not} the
   2.223 -  one you'll need, as it is too buggy and inefficient to be practical.
   2.224 +  Hay \emph{dos} librerías de enlace de Python hacia \texttt{inotify}.
   2.225 +  Una de ellas se llama \texttt{pyinotify}, y en algunas
   2.226 +  distribuciones de Linux se encuentra como \texttt{python-inotify}.
   2.227 +  Esta es la que \emph{no} necesita, puesto que tiene muchos fallos,
   2.228 +  y es ineficiente para ser práctica.
   2.229  \end{note}
   2.230 -To get going, it's best to already have a functioning copy of
   2.231 -Mercurial installed.
   2.232 +Para comenzar, es mejor tener una copia de Mercurial funcional
   2.233 +instalada:
   2.234  \begin{note}
   2.235 -  If you follow the instructions below, you'll be \emph{replacing} and
   2.236 -  overwriting any existing installation of Mercurial that you might
   2.237 -  already have, using the latest ``bleeding edge'' Mercurial code.
   2.238 -  Don't say you weren't warned!
   2.239 +  Si sigue las instrucciones a continuación, estará
   2.240 +  \emph{reemplazando} y sobreescribiendo cualquier instalación previa
   2.241 +  de Mercurial que pudiera tener, con el código de Mercurial ``más
   2.242 +  reciente y peligrosa''.  No diga que no se le advirtio!
   2.243  \end{note}
   2.244  \begin{enumerate}
   2.245 -\item Clone the Python \texttt{inotify} binding repository.  Build and
   2.246 -  install it.
   2.247 +\item Clone el repositorio de interfaz entre Python e
   2.248 +  \texttt{inotify}. Ármelo e instálelo:
   2.249    \begin{codesample4}
   2.250      hg clone http://hg.kublai.com/python/inotify
   2.251      cd inotify
   2.252      python setup.py build --force
   2.253      sudo python setup.py install --skip-build
   2.254    \end{codesample4}
   2.255 -\item Clone the \dirname{crew} Mercurial repository.  Clone the
   2.256 -  \hgext{inotify} patch repository so that Mercurial Queues will be
   2.257 -  able to apply patches to your cope of the \dirname{crew} repository.
   2.258 +\item Clone el repositorio \dirname{crew} de Mercurial.  Clone el
   2.259 +  repositorio de parches de \hgext{inotify} de forma tal que las colas
   2.260 +  de Mercurial puedan aplicar los parches sobre el repositorio \dirname{crew}.
   2.261    \begin{codesample4}
   2.262      hg clone http://hg.intevation.org/mercurial/crew
   2.263      hg clone crew inotify
   2.264      hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
   2.265    \end{codesample4}
   2.266 -\item Make sure that you have the Mercurial Queues extension,
   2.267 -  \hgext{mq}, enabled.  If you've never used MQ, read
   2.268 -  section~\ref{sec:mq:start} to get started quickly.
   2.269 -\item Go into the \dirname{inotify} repo, and apply all of the
   2.270 -  \hgext{inotify} patches using the \hgxopt{mq}{qpush}{-a} option to
   2.271 -  the \hgxcmd{mq}{qpush} command.
   2.272 +\item Asegúrese de instalar la extensión Colas de Mercurial
   2.273 +  \hgext{mq} y que estén habilitadas.  Si nunca ha usado MQ, lea la
   2.274 +  sección~\ref{sec:mq:start} para poder comenzar rápidamente.
   2.275 +\item Vaya al repositorio de \dirname{inotify} y aplique todos los
   2.276 +  parches de \hgext{inotify} con la opción \hgxopt{mq}{qpush}{-a} de
   2.277 +  la orden \hgxcmd{mq}{qpush}.
   2.278    \begin{codesample4}
   2.279      cd inotify
   2.280      hg qpush -a
   2.281    \end{codesample4}
   2.282 -  If you get an error message from \hgxcmd{mq}{qpush}, you should not
   2.283 -  continue.  Instead, ask for help.
   2.284 -\item Build and install the patched version of Mercurial.
   2.285 +  Si obtiene un mensaje de error de \hgxcmd{mq}{qpush}, no debería
   2.286 +  continuar.  Mejor pida ayuda.
   2.287 +\item Arme e instale la versión parchada de Mercurial.
   2.288    \begin{codesample4}
   2.289      python setup.py build --force
   2.290      sudo python setup.py install --skip-build
   2.291    \end{codesample4}
   2.292  \end{enumerate}
   2.293 -Once you've build a suitably patched version of Mercurial, all you
   2.294 -need to do to enable the \hgext{inotify} extension is add an entry to
   2.295 -your \hgrc.
   2.296 +Una vez que haya armado una versión funcional parchada de Mercurial,
   2.297 +todo lo que necesita es habilitar la extensión \hgext{inotify}
   2.298 +colocando una entrada en su \hgrc.
   2.299  \begin{codesample2}
   2.300    [extensions]
   2.301    inotify =
   2.302  \end{codesample2}
   2.303 -When the \hgext{inotify} extension is enabled, Mercurial will
   2.304 -automatically and transparently start the status daemon the first time
   2.305 -you run a command that needs status in a repository.  It runs one
   2.306 -status daemon per repository.
   2.307 -
   2.308 -The status daemon is started silently, and runs in the background.  If
   2.309 -you look at a list of running processes after you've enabled the
   2.310 -\hgext{inotify} extension and run a few commands in different
   2.311 -repositories, you'll thus see a few \texttt{hg} processes sitting
   2.312 -around, waiting for updates from the kernel and queries from
   2.313 -Mercurial.
   2.314 -
   2.315 -The first time you run a Mercurial command in a repository when you
   2.316 -have the \hgext{inotify} extension enabled, it will run with about the
   2.317 -same performance as a normal Mercurial command.  This is because the
   2.318 -status daemon needs to perform a normal status scan so that it has a
   2.319 -baseline against which to apply later updates from the kernel.
   2.320 -However, \emph{every} subsequent command that does any kind of status
   2.321 -check should be noticeably faster on repositories of even fairly
   2.322 -modest size.  Better yet, the bigger your repository is, the greater a
   2.323 -performance advantage you'll see.  The \hgext{inotify} daemon makes
   2.324 -status operations almost instantaneous on repositories of all sizes!
   2.325 -
   2.326 -If you like, you can manually start a status daemon using the
   2.327 -\hgxcmd{inotify}{inserve} command.  This gives you slightly finer
   2.328 -control over how the daemon ought to run.  This command will of course
   2.329 -only be available when the \hgext{inotify} extension is enabled.
   2.330 -
   2.331 -When you're using the \hgext{inotify} extension, you should notice
   2.332 -\emph{no difference at all} in Mercurial's behaviour, with the sole
   2.333 -exception of status-related commands running a whole lot faster than
   2.334 -they used to.  You should specifically expect that commands will not
   2.335 -print different output; neither should they give different results.
   2.336 -If either of these situations occurs, please report a bug.
   2.337 -
   2.338 -\section{Flexible diff support with the \hgext{extdiff} extension}
   2.339 +Cuando la extensión \hgext{inotify} esté habilitada, Mercurial
   2.340 +iniciará transparente y automáticamente el daemonio de estado la
   2.341 +primera vez que ejecute un comando que requiera estado del
   2.342 +repositorio.  Ejecuta un daemoniot de estado por repositorio.
   2.343 +
   2.344 +El daemonio de estado se inicia silenciosamente y se ejecuta en el
   2.345 +fondo. Si mira a la lista de procesos en ejecución después de
   2.346 +habilitar la extensión \hgext{inotify} y ejecuta unos pocos comandos
   2.347 +en diferentes repositorios, verá que hay algunos procesos de
   2.348 +\texttt{hg} por ahí, esperando actualizaciones del kernel y
   2.349 +solicitudes de Mercurial.
   2.350 +
   2.351 +La primera vez que ejecuta un comando de Mercurial en un repositorio
   2.352 +cuando tiene la extensión \hgext{inotify} habilitada, correrá casi con
   2.353 +el mismo desempeño que una orden usual de Mercurial.  Esto es debido a
   2.354 +que el estado del daemonio necesita aplicar una búsqueda normal sobre
   2.355 +el estado para poder tener una línea de partida frente a la cual
   2.356 +aplicar posteriormente actualizaciones del núcleo.  De todas formas,
   2.357 +\emph{todo} comando posterior que haga cualquier clase de revisión del
   2.358 +estado debería ser notablemente más rápido en repositorios con incluso
   2.359 +un tamaño modesto.  Aún mejor, a medida que su repositorio sea más
   2.360 +grande, mejor desempeño verá.  El daemonio \hgext{inotify} hace
   2.361 +operaciones de estado de forma casi instantánea en repositorios de
   2.362 +todos los tamaños!
   2.363 +
   2.364 +Si lo desea, puede iniciar manualmente un daemonio de estado con la orden
   2.365 +\hgxcmd{inotify}{inserve}.  Esto le da un control un poco más fino
   2.366 +acerca de cómo debería ejecutarse el daemonio.  Esta orden solamente
   2.367 +estará disponible cuando haya habilitado la extensión \hgext{inotify}.
   2.368 +
   2.369 +Cuando esté usando la extensión \hgext{inotify},
   2.370 +\emph{no debería ver diferencia} en el comportamiento de Mercurial,
   2.371 +con la única excepción de que los comandos relacionados con el estado
   2.372 +deberían ejectuarse mucho más rápido que como solían hacerlo.  Debería
   2.373 +esperar específicamente que las órdenes no deberían ofrecer salidas
   2.374 +distintas; ni ofrecer resultados diferentes.  Si alguna de estas
   2.375 +situaciones ocurre, por favor reporte el fallo.
   2.376 +
   2.377 +\section{Soporte flexible de diff con la extensión \hgext{extdiff}}
   2.378  \label{sec:hgext:extdiff}
   2.379  
   2.380 -Mercurial's built-in \hgcmd{diff} command outputs plaintext unified
   2.381 -diffs.
   2.382 +La orden predeterminada \hgcmd{diff} de Mercurial despliega diffs en
   2.383 +texto plano unificadas.
   2.384  \interaction{extdiff.diff}
   2.385 -If you would like to use an external tool to display modifications,
   2.386 -you'll want to use the \hgext{extdiff} extension.  This will let you
   2.387 -use, for example, a graphical diff tool.
   2.388 -
   2.389 -The \hgext{extdiff} extension is bundled with Mercurial, so it's easy
   2.390 -to set up.  In the \rcsection{extensions} section of your \hgrc,
   2.391 -simply add a one-line entry to enable the extension.
   2.392 +Si dese emplear una herramienta externa para desplegar las
   2.393 +modificaciones, querrá usar la extensión \hgext{extdiff}.  Esta le
   2.394 +permitirá usar por ejemplo una herramienta gráfica de diff.
   2.395 +
   2.396 +La extensión \hgext{extdiff} viene con Mercurial, y es fácil
   2.397 +configurarl.  En la sección \rcsection{extensions} de su \hgrc,
   2.398 +basta con añadir una entrada de una línea para habilitar la extensión.
   2.399  \begin{codesample2}
   2.400    [extensions]
   2.401    extdiff =
   2.402  \end{codesample2}
   2.403 -This introduces a command named \hgxcmd{extdiff}{extdiff}, which by
   2.404 -default uses your system's \command{diff} command to generate a
   2.405 -unified diff in the same form as the built-in \hgcmd{diff} command.
   2.406 +Esto introduce una orden llamada \hgxcmd{extdiff}{extdiff}, que de
   2.407 +forma predeterminada usa su orden del sistema \command{diff} para
   2.408 +generar un diff unificado de la misma forma que lo hace el comando
   2.409 +predeterminado \hgcmd{diff}.
   2.410  \interaction{extdiff.extdiff}
   2.411 -The result won't be exactly the same as with the built-in \hgcmd{diff}
   2.412 -variations, because the output of \command{diff} varies from one
   2.413 -system to another, even when passed the same options.
   2.414 +El resultado no será exactamente el mismo que con la orden interna
   2.415 +\hgcmd{diff}, puesto que la salida de \command{diff} varía de un
   2.416 +sistema a otro, incluso pasando las mismas opciones.
   2.417  
   2.418  As the ``\texttt{making snapshot}'' lines of output above imply, the
   2.419  \hgxcmd{extdiff}{extdiff} command works by creating two snapshots of