1.1 --- a/es/Leame.1st	Mon Dec 08 23:53:54 2008 -0500
     1.2 +++ b/es/Leame.1st	Wed Dec 10 22:51:01 2008 -0500
     1.3 @@ -106,7 +106,7 @@
     1.4  || collab.tex      || Igor Támara   ||    100%    || 10/11/2008 ||  06/12/2008 ||
     1.5  || filenames.tex   || Javier Rojas  ||     72%    || 27/11/2008 ||             ||
     1.6  || hook.tex        || Javier Rojas  ||     26%    || 01/12/2008 ||             ||
     1.7 -|| mq.tex          || Igor Támara   ||     53%    || 06/12/2008 ||             ||
     1.8 +|| mq.tex          || Igor Támara   ||     63%    || 06/12/2008 ||             ||
     1.9  || hgext.tex       || Igor Támara   ||      0%    ||            ||             ||
    1.10  
    1.11  == Archivos en proceso de revisión ==

     2.1 --- a/es/mq.tex	Mon Dec 08 23:53:54 2008 -0500
     2.2 +++ b/es/mq.tex	Wed Dec 10 22:51:01 2008 -0500
     2.3 @@ -594,105 +594,111 @@
     2.4  \end{itemize}
     2.5  \subsection{Cuidado con los difusos}
     2.6  
     2.7 -While applying a hunk at an offset, or with a fuzz factor, will often
     2.8 -be completely successful, these inexact techniques naturally leave
     2.9 -open the possibility of corrupting the patched file.  The most common
    2.10 -cases typically involve applying a patch twice, or at an incorrect
    2.11 -location in the file.  If \command{patch} or \hgxcmd{mq}{qpush} ever
    2.12 -mentions an offset or fuzz factor, you should make sure that the
    2.13 -modified files are correct afterwards.  
    2.14 -
    2.15 -It's often a good idea to refresh a patch that has applied with an
    2.16 -offset or fuzz factor; refreshing the patch generates new context
    2.17 -information that will make it apply cleanly.  I say ``often,'' not
    2.18 -``always,'' because sometimes refreshing a patch will make it fail to
    2.19 -apply against a different revision of the underlying files.  In some
    2.20 -cases, such as when you're maintaining a patch that must sit on top of
    2.21 -multiple versions of a source tree, it's acceptable to have a patch
    2.22 -apply with some fuzz, provided you've verified the results of the
    2.23 -patching process in such cases.
    2.24 -
    2.25 -\subsection{Handling rejection}
    2.26 -
    2.27 -If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error
    2.28 -message and exit.  If it has left \sfilename{.rej} files behind, it is
    2.29 -usually best to fix up the rejected hunks before you push more patches
    2.30 -or do any further work.
    2.31 -
    2.32 -If your patch \emph{used to} apply cleanly, and no longer does because
    2.33 -you've changed the underlying code that your patches are based on,
    2.34 -Mercurial Queues can help; see section~\ref{sec:mq:merge} for details.
    2.35 -
    2.36 -Unfortunately, there aren't any great techniques for dealing with
    2.37 -rejected hunks.  Most often, you'll need to view the \sfilename{.rej}
    2.38 -file and edit the target file, applying the rejected hunks by hand.
    2.39 -
    2.40 -If you're feeling adventurous, Neil Brown, a Linux kernel hacker,
    2.41 -wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more
    2.42 -vigorous than \command{patch} in its attempts to make a patch apply.
    2.43 -
    2.44 -Another Linux kernel hacker, Chris Mason (the author of Mercurial
    2.45 -Queues), wrote a similar tool called
    2.46 -\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to
    2.47 -automating the application of hunks rejected by \command{patch}.  The
    2.48 -\command{mpatch} command can help with four common reasons that a hunk
    2.49 -may be rejected:
    2.50 +Cuando aplique un trozo con un corrimiento, o con un factor difuso,
    2.51 +aveces será taotalmente exitoso, tales técnicas inexactas dejan
    2.52 +claramente la posibilidad de corromper el archivo parchado.  Los casos
    2.53 +más típicos involucran aplicar un parche dos veces o en un sitio
    2.54 +incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan
    2.55 +a mencionar un corrimiento o un factor difuso, debería asegurarse que
    2.56 +los ficheros modificados estén correctos después del suceso.
    2.57 +
    2.58 +Casi siempre es buena idea refrescar un parche que fue aplicado con un
    2.59 +corrimiento o un factor difuso; refrescar el parche genera nueva
    2.60 +información de contexto que permitirá aplicarlo limpiamente.  Digo
    2.61 +``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones
    2.62 +refrescar un parche lo hará fallar frente a una revisión diferente del
    2.63 +fichero.  En algunos casos, como por ejemplo, cuando usted está
    2.64 +manteniendo un parche que debe estar encima de múltiples revisiones de
    2.65 +un árbol de fuentes, es aceptable tener un parche aplicado algo
    2.66 +difuso, siempre que haya verificado los resultados del proceso de
    2.67 +parchar.
    2.68 +
    2.69 +\subsection{Manejo de descartes}
    2.70 +
    2.71 +Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de
    2.72 +error y saldrá.  Si ha dejado ficheros \sfilename{.rej}, es mejor
    2.73 +arreglar los trozos descartados antes de introducir parches
    2.74 +adicionales o hacer cualquier otra cosa.
    2.75 +
    2.76 +Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace
    2.77 +porque ha cambiado código subyacente en el cual se basa su parche, las
    2.78 +Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}.
    2.79 +
    2.80 +Desafortunadamente, no hay grandes técnicas para tratar los trozos
    2.81 +descartados.  Casi siempre deberá consultar el fichero
    2.82 +\sfilename{.rej} y editar el fichero objetivo, aplicando los trozos
    2.83 +descartados a mano.
    2.84 +
    2.85 +Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una
    2.86 +herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más
    2.87 +vigorosa que \command{patch} en su intento de hacer que se aplique un
    2.88 +parche.
    2.89 +
    2.90 +Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de
    2.91 +Mercurial), escribió una herramienta similar llamada
    2.92 +\command{mpatch}~\cite{web:mpatch}, que sigue una aproximación
    2.93 +sencilla para automatizar la aplicación de trozos descartados por
    2.94 +\command{patch}.  La orden \command{mpatch} puede ayudar con cuatro
    2.95 +razones comunes por las cuales un parche ha sido descartado:
    2.96  
    2.97  \begin{itemize}
    2.98 -\item The context in the middle of a hunk has changed.
    2.99 -\item A hunk is missing some context at the beginning or end.
   2.100 -\item A large hunk might apply better---either entirely or in
   2.101 -  part---if it was broken up into smaller hunks.
   2.102 -\item A hunk removes lines with slightly different content than those
   2.103 -  currently present in the file.
   2.104 +\item El contexto en la mitad de un trozo ha cambiado.
   2.105 +\item Un trozo ha perdido cierto contexto al principio o al final.
   2.106 +\item Un trozo largo podría aplicarse mejor---por completo o una
   2.107 +  parte---si estaba cortado en trozos más pequeños.
   2.108 +\item Un trozo remueve líneas con contenido ligeramente diferente que
   2.109 +  aquellas que están presentes en el fichero.
   2.110  \end{itemize}
   2.111  
   2.112 -If you use \command{wiggle} or \command{mpatch}, you should be doubly
   2.113 -careful to check your results when you're done.  In fact,
   2.114 -\command{mpatch} enforces this method of double-checking the tool's
   2.115 -output, by automatically dropping you into a merge program when it has
   2.116 -done its job, so that you can verify its work and finish off any
   2.117 -remaining merges.
   2.118 -
   2.119 -\section{Getting the best performance out of MQ}
   2.120 +Si usted usa \command{wiggle} o \command{mpatch}, debería ser
   2.121 +doblemente cuidadoso al revisar sus resultados cuando haya terminado.
   2.122 +De hecho, \command{mpatch} refuerza este método de revisar por partida
   2.123 +doble su salida, dejándolo a usted en un programa de fusión cuando la
   2.124 +herramienta haya terminado su trabajo, de tal forma que usted pueda
   2.125 +verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión
   2.126 +faltante.
   2.127 +
   2.128 +\section{Contar con el máximo rendimiento de MQ}
   2.129  \label{sec:mq:perf}
   2.130  
   2.131 -MQ is very efficient at handling a large number of patches.  I ran
   2.132 -some performance experiments in mid-2006 for a talk that I gave at the
   2.133 -2006 EuroPython conference~\cite{web:europython}.  I used as my data
   2.134 -set the Linux 2.6.17-mm1 patch series, which consists of 1,738
   2.135 -patches.  I applied these on top of a Linux kernel repository
   2.136 -containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux
   2.137 -2.6.17.
   2.138 -
   2.139 -On my old, slow laptop, I was able to
   2.140 -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes,
   2.141 -and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds.  (On a
   2.142 -newer laptop, the time to push all patches dropped to two minutes.)  I
   2.143 -could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779
   2.144 -lines of changes to 287 files) in 6.6 seconds.
   2.145 -
   2.146 -Clearly, MQ is well suited to working in large trees, but there are a
   2.147 -few tricks you can use to get the best performance of it.
   2.148 -
   2.149 -First of all, try to ``batch'' operations together.  Every time you
   2.150 -run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working
   2.151 -directory once to make sure you haven't made some changes and then
   2.152 -forgotten to run \hgxcmd{mq}{qrefresh}.  On a small tree, the time that
   2.153 -this scan takes is unnoticeable.  However, on a medium-sized tree
   2.154 -(containing tens of thousands of files), it can take a second or more.
   2.155 -
   2.156 -The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop
   2.157 -multiple patches at a time.  You can identify the ``destination
   2.158 -patch'' that you want to end up at.  When you \hgxcmd{mq}{qpush} with a
   2.159 -destination specified, it will push patches until that patch is at the
   2.160 -top of the applied stack.  When you \hgxcmd{mq}{qpop} to a destination, MQ
   2.161 -will pop patches until the destination patch is at the top.
   2.162 -
   2.163 -You can identify a destination patch using either the name of the
   2.164 -patch, or by number.  If you use numeric addressing, patches are
   2.165 -counted from zero; this means that the first patch is zero, the second
   2.166 -is one, and so on.
   2.167 +MQ es muy eficiente al tratar con una gran cantidad de parches.  Corrí
   2.168 +unos experimentos de desempeño a mediados del 2006 para una charla que
   2.169 +dí en la conferencia EuroPython 2006~\cite{web:europython}.  Empleé la
   2.170 +serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738
   2.171 +parches.  Los apliqué sobre un repositorio del núcleo de Linux con
   2.172 +todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17.
   2.173 +
   2.174 +En mi viejo y lento portátil, logré aplicar 
   2.175 +\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5
   2.176 +minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos.
   2.177 +(En un portátil más nuevo, el tiempo para introducir todos los
   2.178 +parches, se logró en menos de dos minutos.)  Apliqué
   2.179 +\hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes(que hizo
   2.180 +22.779 líneas de cambios en 287 ficheros) en 6,6 segundos.
   2.181 +
   2.182 +Claramente, MQ funciona adecuadamente en árboles grandes, y además hay
   2.183 +unos trucos que pueden emplearse para obtener el máximo desempeño.
   2.184 +
   2.185 +En primer lugar, trate de hacer ``en lote'' las operaciones.  Cada vez
   2.186 +que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes
   2.187 +revisan el directorio de trabajo para asegurarse de que usted no ha
   2.188 +hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}.  En un
   2.189 +árbol pequeño, el tiempo de esta revisión puede ser mínimo,  Pero en
   2.190 +un árbol mediano(con decenas de miles de ficheros), puede tomar un
   2.191 +segundo o más.
   2.192 +
   2.193 +Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten
   2.194 +introducir o sustraer varios parches en una operación.  Puede
   2.195 +identificar el ``parche destino'' que desee.  Cuando aplique
   2.196 +\hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea
   2.197 +necesario hasta que el especificado esté en el tope de la pila.
   2.198 +Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches
   2.199 +hasta que el parche destino esté en el tope.
   2.200 +
   2.201 +Puede identificar un parche destino con el nombre del parche o con el
   2.202 +número.  Si se refiere al número, los parches se contarán desde cero;
   2.203 +esto significa que el primer parche es cero, el segundo es uno y así
   2.204 +sucesivamente.
   2.205  
   2.206  \section{Updating your patches when the underlying code changes}
   2.207  \label{sec:mq:merge}