1.1 --- a/es/mq.tex	Mon Dec 08 23:53:54 2008 -0500
     1.2 +++ b/es/mq.tex	Wed Dec 10 22:51:01 2008 -0500
     1.3 @@ -594,105 +594,111 @@
     1.4  \end{itemize}
     1.5  \subsection{Cuidado con los difusos}
     1.6  
     1.7 -While applying a hunk at an offset, or with a fuzz factor, will often
     1.8 -be completely successful, these inexact techniques naturally leave
     1.9 -open the possibility of corrupting the patched file.  The most common
    1.10 -cases typically involve applying a patch twice, or at an incorrect
    1.11 -location in the file.  If \command{patch} or \hgxcmd{mq}{qpush} ever
    1.12 -mentions an offset or fuzz factor, you should make sure that the
    1.13 -modified files are correct afterwards.  
    1.14 -
    1.15 -It's often a good idea to refresh a patch that has applied with an
    1.16 -offset or fuzz factor; refreshing the patch generates new context
    1.17 -information that will make it apply cleanly.  I say ``often,'' not
    1.18 -``always,'' because sometimes refreshing a patch will make it fail to
    1.19 -apply against a different revision of the underlying files.  In some
    1.20 -cases, such as when you're maintaining a patch that must sit on top of
    1.21 -multiple versions of a source tree, it's acceptable to have a patch
    1.22 -apply with some fuzz, provided you've verified the results of the
    1.23 -patching process in such cases.
    1.24 -
    1.25 -\subsection{Handling rejection}
    1.26 -
    1.27 -If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error
    1.28 -message and exit.  If it has left \sfilename{.rej} files behind, it is
    1.29 -usually best to fix up the rejected hunks before you push more patches
    1.30 -or do any further work.
    1.31 -
    1.32 -If your patch \emph{used to} apply cleanly, and no longer does because
    1.33 -you've changed the underlying code that your patches are based on,
    1.34 -Mercurial Queues can help; see section~\ref{sec:mq:merge} for details.
    1.35 -
    1.36 -Unfortunately, there aren't any great techniques for dealing with
    1.37 -rejected hunks.  Most often, you'll need to view the \sfilename{.rej}
    1.38 -file and edit the target file, applying the rejected hunks by hand.
    1.39 -
    1.40 -If you're feeling adventurous, Neil Brown, a Linux kernel hacker,
    1.41 -wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more
    1.42 -vigorous than \command{patch} in its attempts to make a patch apply.
    1.43 -
    1.44 -Another Linux kernel hacker, Chris Mason (the author of Mercurial
    1.45 -Queues), wrote a similar tool called
    1.46 -\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to
    1.47 -automating the application of hunks rejected by \command{patch}.  The
    1.48 -\command{mpatch} command can help with four common reasons that a hunk
    1.49 -may be rejected:
    1.50 +Cuando aplique un trozo con un corrimiento, o con un factor difuso,
    1.51 +aveces será taotalmente exitoso, tales técnicas inexactas dejan
    1.52 +claramente la posibilidad de corromper el archivo parchado.  Los casos
    1.53 +más típicos involucran aplicar un parche dos veces o en un sitio
    1.54 +incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan
    1.55 +a mencionar un corrimiento o un factor difuso, debería asegurarse que
    1.56 +los ficheros modificados estén correctos después del suceso.
    1.57 +
    1.58 +Casi siempre es buena idea refrescar un parche que fue aplicado con un
    1.59 +corrimiento o un factor difuso; refrescar el parche genera nueva
    1.60 +información de contexto que permitirá aplicarlo limpiamente.  Digo
    1.61 +``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones
    1.62 +refrescar un parche lo hará fallar frente a una revisión diferente del
    1.63 +fichero.  En algunos casos, como por ejemplo, cuando usted está
    1.64 +manteniendo un parche que debe estar encima de múltiples revisiones de
    1.65 +un árbol de fuentes, es aceptable tener un parche aplicado algo
    1.66 +difuso, siempre que haya verificado los resultados del proceso de
    1.67 +parchar.
    1.68 +
    1.69 +\subsection{Manejo de descartes}
    1.70 +
    1.71 +Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de
    1.72 +error y saldrá.  Si ha dejado ficheros \sfilename{.rej}, es mejor
    1.73 +arreglar los trozos descartados antes de introducir parches
    1.74 +adicionales o hacer cualquier otra cosa.
    1.75 +
    1.76 +Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace
    1.77 +porque ha cambiado código subyacente en el cual se basa su parche, las
    1.78 +Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}.
    1.79 +
    1.80 +Desafortunadamente, no hay grandes técnicas para tratar los trozos
    1.81 +descartados.  Casi siempre deberá consultar el fichero
    1.82 +\sfilename{.rej} y editar el fichero objetivo, aplicando los trozos
    1.83 +descartados a mano.
    1.84 +
    1.85 +Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una
    1.86 +herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más
    1.87 +vigorosa que \command{patch} en su intento de hacer que se aplique un
    1.88 +parche.
    1.89 +
    1.90 +Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de
    1.91 +Mercurial), escribió una herramienta similar llamada
    1.92 +\command{mpatch}~\cite{web:mpatch}, que sigue una aproximación
    1.93 +sencilla para automatizar la aplicación de trozos descartados por
    1.94 +\command{patch}.  La orden \command{mpatch} puede ayudar con cuatro
    1.95 +razones comunes por las cuales un parche ha sido descartado:
    1.96  
    1.97  \begin{itemize}
    1.98 -\item The context in the middle of a hunk has changed.
    1.99 -\item A hunk is missing some context at the beginning or end.
   1.100 -\item A large hunk might apply better---either entirely or in
   1.101 -  part---if it was broken up into smaller hunks.
   1.102 -\item A hunk removes lines with slightly different content than those
   1.103 -  currently present in the file.
   1.104 +\item El contexto en la mitad de un trozo ha cambiado.
   1.105 +\item Un trozo ha perdido cierto contexto al principio o al final.
   1.106 +\item Un trozo largo podría aplicarse mejor---por completo o una
   1.107 +  parte---si estaba cortado en trozos más pequeños.
   1.108 +\item Un trozo remueve líneas con contenido ligeramente diferente que
   1.109 +  aquellas que están presentes en el fichero.
   1.110  \end{itemize}
   1.111  
   1.112 -If you use \command{wiggle} or \command{mpatch}, you should be doubly
   1.113 -careful to check your results when you're done.  In fact,
   1.114 -\command{mpatch} enforces this method of double-checking the tool's
   1.115 -output, by automatically dropping you into a merge program when it has
   1.116 -done its job, so that you can verify its work and finish off any
   1.117 -remaining merges.
   1.118 -
   1.119 -\section{Getting the best performance out of MQ}
   1.120 +Si usted usa \command{wiggle} o \command{mpatch}, debería ser
   1.121 +doblemente cuidadoso al revisar sus resultados cuando haya terminado.
   1.122 +De hecho, \command{mpatch} refuerza este método de revisar por partida
   1.123 +doble su salida, dejándolo a usted en un programa de fusión cuando la
   1.124 +herramienta haya terminado su trabajo, de tal forma que usted pueda
   1.125 +verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión
   1.126 +faltante.
   1.127 +
   1.128 +\section{Contar con el máximo rendimiento de MQ}
   1.129  \label{sec:mq:perf}
   1.130  
   1.131 -MQ is very efficient at handling a large number of patches.  I ran
   1.132 -some performance experiments in mid-2006 for a talk that I gave at the
   1.133 -2006 EuroPython conference~\cite{web:europython}.  I used as my data
   1.134 -set the Linux 2.6.17-mm1 patch series, which consists of 1,738
   1.135 -patches.  I applied these on top of a Linux kernel repository
   1.136 -containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux
   1.137 -2.6.17.
   1.138 -
   1.139 -On my old, slow laptop, I was able to
   1.140 -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes,
   1.141 -and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds.  (On a
   1.142 -newer laptop, the time to push all patches dropped to two minutes.)  I
   1.143 -could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779
   1.144 -lines of changes to 287 files) in 6.6 seconds.
   1.145 -
   1.146 -Clearly, MQ is well suited to working in large trees, but there are a
   1.147 -few tricks you can use to get the best performance of it.
   1.148 -
   1.149 -First of all, try to ``batch'' operations together.  Every time you
   1.150 -run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working
   1.151 -directory once to make sure you haven't made some changes and then
   1.152 -forgotten to run \hgxcmd{mq}{qrefresh}.  On a small tree, the time that
   1.153 -this scan takes is unnoticeable.  However, on a medium-sized tree
   1.154 -(containing tens of thousands of files), it can take a second or more.
   1.155 -
   1.156 -The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop
   1.157 -multiple patches at a time.  You can identify the ``destination
   1.158 -patch'' that you want to end up at.  When you \hgxcmd{mq}{qpush} with a
   1.159 -destination specified, it will push patches until that patch is at the
   1.160 -top of the applied stack.  When you \hgxcmd{mq}{qpop} to a destination, MQ
   1.161 -will pop patches until the destination patch is at the top.
   1.162 -
   1.163 -You can identify a destination patch using either the name of the
   1.164 -patch, or by number.  If you use numeric addressing, patches are
   1.165 -counted from zero; this means that the first patch is zero, the second
   1.166 -is one, and so on.
   1.167 +MQ es muy eficiente al tratar con una gran cantidad de parches.  Corrí
   1.168 +unos experimentos de desempeño a mediados del 2006 para una charla que
   1.169 +dí en la conferencia EuroPython 2006~\cite{web:europython}.  Empleé la
   1.170 +serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738
   1.171 +parches.  Los apliqué sobre un repositorio del núcleo de Linux con
   1.172 +todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17.
   1.173 +
   1.174 +En mi viejo y lento portátil, logré aplicar 
   1.175 +\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5
   1.176 +minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos.
   1.177 +(En un portátil más nuevo, el tiempo para introducir todos los
   1.178 +parches, se logró en menos de dos minutos.)  Apliqué
   1.179 +\hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes(que hizo
   1.180 +22.779 líneas de cambios en 287 ficheros) en 6,6 segundos.
   1.181 +
   1.182 +Claramente, MQ funciona adecuadamente en árboles grandes, y además hay
   1.183 +unos trucos que pueden emplearse para obtener el máximo desempeño.
   1.184 +
   1.185 +En primer lugar, trate de hacer ``en lote'' las operaciones.  Cada vez
   1.186 +que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes
   1.187 +revisan el directorio de trabajo para asegurarse de que usted no ha
   1.188 +hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}.  En un
   1.189 +árbol pequeño, el tiempo de esta revisión puede ser mínimo,  Pero en
   1.190 +un árbol mediano(con decenas de miles de ficheros), puede tomar un
   1.191 +segundo o más.
   1.192 +
   1.193 +Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten
   1.194 +introducir o sustraer varios parches en una operación.  Puede
   1.195 +identificar el ``parche destino'' que desee.  Cuando aplique
   1.196 +\hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea
   1.197 +necesario hasta que el especificado esté en el tope de la pila.
   1.198 +Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches
   1.199 +hasta que el parche destino esté en el tope.
   1.200 +
   1.201 +Puede identificar un parche destino con el nombre del parche o con el
   1.202 +número.  Si se refiere al número, los parches se contarán desde cero;
   1.203 +esto significa que el primer parche es cero, el segundo es uno y así
   1.204 +sucesivamente.
   1.205  
   1.206  \section{Updating your patches when the underlying code changes}
   1.207  \label{sec:mq:merge}