hgbook
changeset 451:f4904a9b4fdb
Started translating hgext
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Sat Dec 13 23:55:07 2008 -0500 (2008-12-13) |
parents | f05b05fe12fc |
children | 5a0401ba9faa |
files | es/Leame.1st es/hgext.tex |
line diff
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