1.1 --- a/es/Leame.1st	Wed Dec 10 22:51:01 2008 -0500
     1.2 +++ b/es/Leame.1st	Fri Dec 12 07:45:58 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   ||     63%    || 06/12/2008 ||             ||
     1.8 +|| mq.tex          || Igor Támara   ||     74%    || 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	Wed Dec 10 22:51:01 2008 -0500
     2.2 +++ b/es/mq.tex	Fri Dec 12 07:45:58 2008 -0500
     2.3 @@ -668,7 +668,7 @@
     2.4  parches.  Los apliqué sobre un repositorio del núcleo de Linux con
     2.5  todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17.
     2.6  
     2.7 -En mi viejo y lento portátil, logré aplicar 
     2.8 +En mi portátil antiguo y lento, logré aplicar 
     2.9  \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5
    2.10  minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos.
    2.11  (En un portátil más nuevo, el tiempo para introducir todos los
    2.12 @@ -700,100 +700,104 @@
    2.13  esto significa que el primer parche es cero, el segundo es uno y así
    2.14  sucesivamente.
    2.15  
    2.16 -\section{Updating your patches when the underlying code changes}
    2.17 +\section{Actualiar los parches cuando el código cambia}
    2.18  \label{sec:mq:merge}
    2.19  
    2.20 -It's common to have a stack of patches on top of an underlying
    2.21 -repository that you don't modify directly.  If you're working on
    2.22 -changes to third-party code, or on a feature that is taking longer to
    2.23 -develop than the rate of change of the code beneath, you will often
    2.24 -need to sync up with the underlying code, and fix up any hunks in your
    2.25 -patches that no longer apply.  This is called \emph{rebasing} your
    2.26 -patch series.
    2.27 -
    2.28 -The simplest way to do this is to \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}}
    2.29 -your patches, then \hgcmd{pull} changes into the underlying
    2.30 -repository, and finally \hgcmdargs{qpush}{\hgxopt{mq}{qpop}{-a}} your
    2.31 -patches again.  MQ will stop pushing any time it runs across a patch
    2.32 -that fails to apply during conflicts, allowing you to fix your
    2.33 -conflicts, \hgxcmd{mq}{qrefresh} the affected patch, and continue pushing
    2.34 -until you have fixed your entire stack.
    2.35 -
    2.36 -This approach is easy to use and works well if you don't expect
    2.37 -changes to the underlying code to affect how well your patches apply.
    2.38 -If your patch stack touches code that is modified frequently or
    2.39 -invasively in the underlying repository, however, fixing up rejected
    2.40 -hunks by hand quickly becomes tiresome.
    2.41 -
    2.42 -It's possible to partially automate the rebasing process.  If your
    2.43 -patches apply cleanly against some revision of the underlying repo, MQ
    2.44 -can use this information to help you to resolve conflicts between your
    2.45 -patches and a different revision.
    2.46 -
    2.47 -The process is a little involved.
    2.48 +Es común contar con una pila de parches sobre un repositorio que usted
    2.49 +no modifica directamente.  Si está trabajando en cambios de código de
    2.50 +otros, o en una característica que tarda bastante en desarrollarse
    2.51 +comparada con la tasa de cambio del código sobre la cual se está
    2.52 +trabajando, necesitará sincronizarse con el código, y ajustar
    2.53 +cualquier trozo en sus parches que ya no estén al día.  A esto se le
    2.54 +llama hacer \emph{rebase} a su serie de parches.
    2.55 +
    2.56 +La vía más sencilla de hacerlo es con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}}
    2.57 +sobre sus parches, después hacer \hgcmd{pull} de los cambios en el
    2.58 +repositorio, y finalmente hacer
    2.59 +\hgcmdargs{qpush}{\hgxopt{mq}{qpop}{-a}} con sus parches de nuevo.  MQ
    2.60 +dejará de de introducir parches siempre que llegue a un parche que no se pueda
    2.61 +aplicar debido a un conflicto, permitiéndole a usted arreglarlo,
    2.62 +aplicar \hgxcmd{mq}{qrefresh} al parche afectado y continuar
    2.63 +introduciendo hasta que haya arreglado la pila completa.
    2.64 +
    2.65 +Esta aproximación es sencilla y funciona bien si no espera cambios en
    2.66 +el código original que afecte en gran medida los parches que usted
    2.67 +esté aplicando. Si su pila de parches toca código que es modificado
    2.68 +frecuentemente o de forma invasiva sobre el código subyacente,
    2.69 +arreglar trozos manualmente se vuelve desgastante.
    2.70 +
    2.71 +Es posible automatizar de forma parcial el proceso de rebase.  Si sus
    2.72 +parches se aplican limpiamente sobre algunas revisiones del
    2.73 +repositorio subyacente, MQ puede usar esta información para ayudarle a
    2.74 +a resolver conflictos entre sus parches y una revisión distinta.
    2.75 +
    2.76 +El proceso resulta un poco complejo:
    2.77  \begin{enumerate}
    2.78 -\item To begin, \hgcmdargs{qpush}{-a} all of your patches on top of
    2.79 -  the revision where you know that they apply cleanly.
    2.80 -\item Save a backup copy of your patch directory using
    2.81 -  \hgcmdargs{qsave}{\hgxopt{mq}{qsave}{-e} \hgxopt{mq}{qsave}{-c}}.  This prints
    2.82 -  the name of the directory that it has saved the patches in.  It will
    2.83 -  save the patches to a directory called
    2.84 -  \sdirname{.hg/patches.\emph{N}}, where \texttt{\emph{N}} is a small
    2.85 -  integer.  It also commits a ``save changeset'' on top of your
    2.86 -  applied patches; this is for internal book-keeping, and records the
    2.87 -  states of the \sfilename{series} and \sfilename{status} files.
    2.88 -\item Use \hgcmd{pull} to bring new changes into the underlying
    2.89 -  repository.  (Don't run \hgcmdargs{pull}{-u}; see below for why.)
    2.90 -\item Update to the new tip revision, using
    2.91 -  \hgcmdargs{update}{\hgopt{update}{-C}} to override the patches you
    2.92 -  have pushed.
    2.93 -\item Merge all patches using \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}
    2.94 -    \hgxopt{mq}{qpush}{-a}}.  The \hgxopt{mq}{qpush}{-m} option to \hgxcmd{mq}{qpush}
    2.95 -  tells MQ to perform a three-way merge if the patch fails to apply.
    2.96 +\item Para comenzar, haga \hgcmdargs{qpush}{-a} sobre todos los
    2.97 +  parches que usted sepa se aplican limpiamente.
    2.98 +\item Guarde una copia de seguridad de su directorio de parches  con
    2.99 +  \hgcmdargs{qsave}{\hgxopt{mq}{qsave}{-e} \hgxopt{mq}{qsave}{-c}}.
   2.100 +  Esto imprime el nombre del directorio en el cual se han guardado los
   2.101 +  parches.  Guardará los parches en un directorio llamado
   2.102 +  \sdirname{.hg/patches.\emph{N}}, donde \texttt{\emph{N}} es un
   2.103 +  entero pequeño.  También consigna un ``conjunto de cambios de
   2.104 +  seguridad'' sobre sus parches aplicados; esto es para mantener el
   2.105 +  histórico, y guarda los estados de los ficheros  \sfilename{series}
   2.106 +  y \sfilename{status}.
   2.107 +\item Use \hgcmd{pull} para traer los nuevos cambios en el repositorio
   2.108 +  subyacente. (No ejecute \hgcmdargs{pull}{-u}; vea más adelante por qué.)
   2.109 +\item Actualice a la nueva revisión punta con 
   2.110 +  \hgcmdargs{update}{\hgopt{update}{-C}} para sobreescribir los
   2.111 +  parches que haya introducido.
   2.112 +\item Fusione todos los parches con \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}
   2.113 +    \hgxopt{mq}{qpush}{-a}}.  La opción \hgxopt{mq}{qpush}{-m} de \hgxcmd{mq}{qpush}
   2.114 +  le indica a MQ que haga una fusión que involucra tres fuentes si el
   2.115 +  parche falla al aplicarse.
   2.116  \end{enumerate}
   2.117  
   2.118 -During the \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}}, each patch in the
   2.119 -\sfilename{series} file is applied normally.  If a patch applies with
   2.120 -fuzz or rejects, MQ looks at the queue you \hgxcmd{mq}{qsave}d, and
   2.121 -performs a three-way merge with the corresponding changeset.  This
   2.122 -merge uses Mercurial's normal merge machinery, so it may pop up a GUI
   2.123 -merge tool to help you to resolve problems.
   2.124 -
   2.125 -When you finish resolving the effects of a patch, MQ refreshes your
   2.126 -patch based on the result of the merge.
   2.127 -
   2.128 -At the end of this process, your repository will have one extra head
   2.129 -from the old patch queue, and a copy of the old patch queue will be in
   2.130 -\sdirname{.hg/patches.\emph{N}}. You can remove the extra head using
   2.131 -\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a} \hgxopt{mq}{qpop}{-n} patches.\emph{N}}
   2.132 -or \hgcmd{strip}.  You can delete \sdirname{.hg/patches.\emph{N}} once
   2.133 -you are sure that you no longer need it as a backup.
   2.134 -
   2.135 -\section{Identifying patches}
   2.136 -
   2.137 -MQ commands that work with patches let you refer to a patch either by
   2.138 -using its name or by a number.  By name is obvious enough; pass the
   2.139 -name \filename{foo.patch} to \hgxcmd{mq}{qpush}, for example, and it will
   2.140 -push patches until \filename{foo.patch} is applied.  
   2.141 -
   2.142 -As a shortcut, you can refer to a patch using both a name and a
   2.143 -numeric offset; \texttt{foo.patch-2} means ``two patches before
   2.144 -\texttt{foo.patch}'', while \texttt{bar.patch+4} means ``four patches
   2.145 -after \texttt{bar.patch}''.
   2.146 -
   2.147 -Referring to a patch by index isn't much different.  The first patch
   2.148 -printed in the output of \hgxcmd{mq}{qseries} is patch zero (yes, it's one
   2.149 -of those start-at-zero counting systems); the second is patch one; and
   2.150 -so on.
   2.151 -
   2.152 -MQ also makes it easy to work with patches when you are using normal
   2.153 -Mercurial commands.  Every command that accepts a changeset ID will
   2.154 -also accept the name of an applied patch.  MQ augments the tags
   2.155 -normally in the repository with an eponymous one for each applied
   2.156 -patch.  In addition, the special tags \index{tags!special tag
   2.157 -  names!\texttt{qbase}}\texttt{qbase} and \index{tags!special tag
   2.158 -  names!\texttt{qtip}}\texttt{qtip} identify the ``bottom-most'' and
   2.159 -topmost applied patches, respectively.
   2.160 +Durante el \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}}, cada parche en
   2.161 +el fichero \sfilename{series} se aplica normalmente.  Si un parche se
   2.162 +aplica difusamente o se niea a aplicarse, MQ consulta la cola que
   2.163 +usted guardó con \hgxcmd{mq}{qsave}, y aplica una fusión de tres con
   2.164 +el correspondiente conjunto de cambios.  Esta fusión usa la maquinaria
   2.165 +de Mercurial, por lo tanto puede mostrar una herramienta de fusión GUI
   2.166 +para ayudarle a resolver los problemas.
   2.167 +
   2.168 +Cuando termine de resolver los efectos de un parche, MQ refrescará su
   2.169 +parche basado en el resultado de la fusión.
   2.170 +
   2.171 +Al final de este proceso, su repositorio tendrá una cabeza extra de la
   2.172 +antigua cola de parches, y una copia de la cola de parches anterio
   2.173 +estará en \sdirname{.hg/patches.\emph{N}}. Puede eliminar la cabeza
   2.174 +extra con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a} \hgxopt{mq}{qpop}{-n} patches.\emph{N}}
   2.175 +o \hgcmd{strip}.  Puede eliminar \sdirname{.hg/patches.\emph{N}} una
   2.176 +vez que esté seguro de que no lo necesita más como copia de seguridad.
   2.177 +
   2.178 +\section{Identificar parches}
   2.179 +
   2.180 +Las órdenes de MQ le permiten trabajar refiriéndose al nombre del
   2.181 +parche o al número.  Es obvio hacerlo por el nombre; por ejemplo se
   2.182 +pasa el nombre \filename{foo.patch} a \hgxcmd{mq}{qpush}, que
   2.183 +introducirá los parches hasta que \filename{foo.patch} se aplique.  
   2.184 +
   2.185 +Para hacerlo más corto, puede referirse a un parche con un nombre y un
   2.186 +corrimiento de número; por ejemplo,  \texttt{foo.patch-2} significa
   2.187 +``dos parches antes de \texttt{foo.patch}'', mientras que
   2.188 +\texttt{bar.patch+4} significa ``cuatro parches después de \texttt{bar.patch}''.
   2.189 +
   2.190 +Referirse a un parche por su índice no es muy diferente.  El primer
   2.191 +parche que se imprime en la salida de \hgxcmd{mq}{qseries} es el
   2.192 +parche cero(si, es el primero en los sistemas que comienzan su conteo
   2.193 +en cero); el segundo parche es uno y así sucesivamente.
   2.194 +
   2.195 +MQ facilita el trabajo cuando está usando órdenes normales de
   2.196 +Mercurial.  Cada comando que acepte Identificadores de conjuntos de
   2.197 +cambios también aceptará el nombre de un parche aplicado.  MQ aumenta
   2.198 +los tags normalmente en el repositorio con un distintivo para cada
   2.199 +parche aplicado.  Adicionalmente, los tags especiales \index{tags!special tag
   2.200 +  names!\texttt{qbase}}\texttt{qbase} y \index{tags!special tag
   2.201 +  names!\texttt{qtip}}\texttt{qtip} identifican los parches
   2.202 +``primero'' y último, respectivamente.
   2.203  
   2.204  These additions to Mercurial's normal tagging capabilities make
   2.205  dealing with patches even more of a breeze.