1.1 --- a/es/Leame.1st	Mon Dec 08 20:42:11 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Dec 08 23:53:54 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   ||     41%    || 06/12/2008 ||             ||
     1.8 +|| mq.tex          || Igor Támara   ||     53%    || 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 20:42:11 2008 -0500
     2.2 +++ b/es/mq.tex	Mon Dec 08 23:53:54 2008 -0500
     2.3 @@ -496,95 +496,103 @@
     2.4  modificado estaría al frente de la porción derecha de la ruta del
     2.5  archivo.
     2.6  
     2.7 -Since someone receiving a patch from the Alices of the net would be
     2.8 -unlikely to have unmodified and modified directories with exactly the
     2.9 -same names, the \command{patch} command has a \cmdopt{patch}{-p}
    2.10 -option that indicates the number of leading path name components to
    2.11 -strip when trying to apply a patch.  This number is called the
    2.12 -\emph{strip count}.
    2.13 -
    2.14 -An option of ``\texttt{-p1}'' means ``use a strip count of one''.  If
    2.15 -\command{patch} sees a file name \filename{foo/bar/baz} in a file
    2.16 -header, it will strip \filename{foo} and try to patch a file named
    2.17 -\filename{bar/baz}.  (Strictly speaking, the strip count refers to the
    2.18 -number of \emph{path separators} (and the components that go with them
    2.19 -) to strip.  A strip count of one will turn \filename{foo/bar} into
    2.20 -\filename{bar}, but \filename{/foo/bar} (notice the extra leading
    2.21 -slash) into \filename{foo/bar}.)
    2.22 -
    2.23 -The ``standard'' strip count for patches is one; almost all patches
    2.24 -contain one leading path name component that needs to be stripped.
    2.25 -Mercurial's \hgcmd{diff} command generates path names in this form,
    2.26 -and the \hgcmd{import} command and MQ expect patches to have a strip
    2.27 -count of one.
    2.28 -
    2.29 -If you receive a patch from someone that you want to add to your patch
    2.30 -queue, and the patch needs a strip count other than one, you cannot
    2.31 -just \hgxcmd{mq}{qimport} the patch, because \hgxcmd{mq}{qimport} does not yet
    2.32 -have a \texttt{-p} option (see~\bug{311}).  Your best bet is to
    2.33 -\hgxcmd{mq}{qnew} a patch of your own, then use \cmdargs{patch}{-p\emph{N}}
    2.34 -to apply their patch, followed by \hgcmd{addremove} to pick up any
    2.35 -files added or removed by the patch, followed by \hgxcmd{mq}{qrefresh}.
    2.36 -This complexity may become unnecessary; see~\bug{311} for details.
    2.37 -\subsection{Strategies for applying a patch}
    2.38 -
    2.39 -When \command{patch} applies a hunk, it tries a handful of
    2.40 -successively less accurate strategies to try to make the hunk apply.
    2.41 -This falling-back technique often makes it possible to take a patch
    2.42 -that was generated against an old version of a file, and apply it
    2.43 -against a newer version of that file.
    2.44 -
    2.45 -First, \command{patch} tries an exact match, where the line numbers,
    2.46 -the context, and the text to be modified must apply exactly.  If it
    2.47 -cannot make an exact match, it tries to find an exact match for the
    2.48 -context, without honouring the line numbering information.  If this
    2.49 -succeeds, it prints a line of output saying that the hunk was applied,
    2.50 -but at some \emph{offset} from the original line number.
    2.51 -
    2.52 -If a context-only match fails, \command{patch} removes the first and
    2.53 -last lines of the context, and tries a \emph{reduced} context-only
    2.54 -match.  If the hunk with reduced context succeeds, it prints a message
    2.55 -saying that it applied the hunk with a \emph{fuzz factor} (the number
    2.56 -after the fuzz factor indicates how many lines of context
    2.57 -\command{patch} had to trim before the patch applied).
    2.58 -
    2.59 -When neither of these techniques works, \command{patch} prints a
    2.60 -message saying that the hunk in question was rejected.  It saves
    2.61 -rejected hunks (also simply called ``rejects'') to a file with the
    2.62 -same name, and an added \sfilename{.rej} extension.  It also saves an
    2.63 -unmodified copy of the file with a \sfilename{.orig} extension; the
    2.64 -copy of the file without any extensions will contain any changes made
    2.65 -by hunks that \emph{did} apply cleanly.  If you have a patch that
    2.66 -modifies \filename{foo} with six hunks, and one of them fails to
    2.67 -apply, you will have: an unmodified \filename{foo.orig}, a
    2.68 -\filename{foo.rej} containing one hunk, and \filename{foo}, containing
    2.69 -the changes made by the five successful five hunks.
    2.70 -
    2.71 -\subsection{Some quirks of patch representation}
    2.72 -
    2.73 -There are a few useful things to know about how \command{patch} works
    2.74 -with files.
    2.75 +Como alguien que reciba un parche de Alicia en la red podría obtener
    2.76 +dos directorios, uno original y el otro modificado con exactamente los
    2.77 +mismos nombres, la orden \command{patch} tiene la opción
    2.78 +\cmdopt{patch}{-p} que indica la cantidad de componentes de la ruta
    2.79 +a eliminar cuando se vaya a aplicar el parche.  Este número se
    2.80 +llama la \emph{cantidad de eliminaciones}.
    2.81 +
    2.82 +La opción con ``\texttt{-p1}'' significa ``elimine uno''.  Si
    2.83 +\command{patch} ve un nombre de fichero \filename{foo/bar/baz} en el
    2.84 +encabezado del fichero, eliminará \filename{foo} y tratará de parchar
    2.85 +un fichero llamado \filename{bar/baz}.  (Hablando estrictamente, la
    2.86 +cantidad de eliminaciones se refiere a la cantidad de \emph{separadores de
    2.87 + ruta} (y los componentes que vayan con ellos) a eliminar.  Si el
    2.88 +contador es uno volverá \filename{foo/bar} en \filename{bar}, pero
    2.89 +\filename{/foo/bar} (note la barra extra) en \filename{foo/bar}.)
    2.90 +
    2.91 +La cantidad a eliminar``estándar'' para parches es uno; casi todos los
    2.92 +parches contienen un componente inicial de la ruta que necesita ser
    2.93 +eliminado.  La orden \hgcmd{diff} de Mercurial genera nombres de ruta
    2.94 +de esta forma, y la orden \hgcmd{import} y MQ esperan parches que
    2.95 +tengan a uno como cuenta de eliminaciones.
    2.96 +
    2.97 +Si recibe un parche de alguien de quien desea adicionar adicionar a su
    2.98 +cola de parches, y el parche necesita una cuenta de eliminación que no
    2.99 +sea uno, no podrá aplicar \hgxcmd{mq}{qimport} en primera medida,
   2.100 +porque \hgxcmd{mq}{qimport} no tiene todavía una opción \texttt{-p}
   2.101 +option (ver~\bug{311}).  Lo mejor que puede hacer es aplicar
   2.102 +\hgxcmd{mq}{qnew} por su cuenta, y después usar \cmdargs{patch}{-p\emph{N}}
   2.103 +para aplicar tal parche, seguido de \hgcmd{addremove} para tener en
   2.104 +cuenta cualquier fichero adicionado o eliminado por el parche, seguido
   2.105 +de \hgxcmd{mq}{qrefresh}.  Esta complejidad puede ser innecesaria;
   2.106 +consulte~\bug{311} para más información.
   2.107 +
   2.108 +\subsection{Estrategias para aplicar parches}
   2.109 +
   2.110 +Cuando \command{patch} aplica un trozo, intenta varias estrategias
   2.111 +sucesivas que decrecen en precisión para intentar aplicarlo.  Esta
   2.112 +técnica de pruebas y error aveces permite que un parche que fue
   2.113 +generado contra una versión anterior de un fichero, sea aplicada sobre
   2.114 +una versión más nueva del mismo.
   2.115 +
   2.116 +Primero \command{patch} intenta una correspondencia perfecta donde los
   2.117 +números de línea, el contexto y el texto a modificar deben coincidir
   2.118 +perfectamente.  Si no lo logra, intenta encontrar una correspondencia
   2.119 +exacta del contexto, sin tener en cuenta el número de línea.  Si es
   2.120 +exitoso, imprime una línea indicando que el trozo fue aplicado, pero a
   2.121 +un \emph{corrimiento} del número de línea original.
   2.122 +
   2.123 +Si falla la correspondencia por contexto, \command{patch} elimina la
   2.124 +primera y la última línea del contexto, e intenta una correspondencia
   2.125 +\emph{reducida} del contexto.  Si el trozo con contexto reducido es
   2.126 +exitoso, imprime un mensaje indicando que aplicó el trozo con un
   2.127 +\emph{factor difuso} (el número después del factor difuso indica
   2.128 +cuántas líneas de contexto \command{patch} tuvo que eliminar antes de
   2.129 +aplicar el parche).
   2.130 +
   2.131 +Cuando ninguna de estas técnicas funciona, \command{patch} imprime un
   2.132 +mensaje indicando que el trozo en cuestión se desechó.  Almacena los
   2.133 +trozos desechados(también llamados ``descartados'') en un fichero con
   2.134 +el mismo nombre, y la extensión \sfilename{.rej} añadida.  También
   2.135 +almacena una copia igual al fichero original con la extensión
   2.136 +\sfilename{.orig}; la copia del fichero sin extensión contendrá
   2.137 +cualquier cambio hecho por los trozos que \emph{sí} se aplicaron sin
   2.138 +problema.  Si usted tiene un parche que modifica \filename{foo} con
   2.139 +seis trozos, y uno de ellos falla al aplicarse, tendrá : un fichero
   2.140 +original \filename{foo.orig}, un fichero \filename{foo.rej} que
   2.141 +contiene el trozo, y \filename{foo}, que contiene los cambios que se
   2.142 +aplicaron por los cinco trozos exitosos.
   2.143 +
   2.144 +\subsection{Algunos detalles de la representación de parches}
   2.145 +
   2.146 +Hay ciertas cosas útiles por saber acerca de cómo trabaja
   2.147 +\command{patch} con los ficheros:
   2.148  \begin{itemize}
   2.149 -\item This should already be obvious, but \command{patch} cannot
   2.150 -  handle binary files.
   2.151 -\item Neither does it care about the executable bit; it creates new
   2.152 -  files as readable, but not executable.
   2.153 -\item \command{patch} treats the removal of a file as a diff between
   2.154 -  the file to be removed and the empty file.  So your idea of ``I
   2.155 -  deleted this file'' looks like ``every line of this file was
   2.156 -  deleted'' in a patch.
   2.157 -\item It treats the addition of a file as a diff between the empty
   2.158 -  file and the file to be added.  So in a patch, your idea of ``I
   2.159 -  added this file'' looks like ``every line of this file was added''.
   2.160 -\item It treats a renamed file as the removal of the old name, and the
   2.161 -  addition of the new name.  This means that renamed files have a big
   2.162 -  footprint in patches.  (Note also that Mercurial does not currently
   2.163 -  try to infer when files have been renamed or copied in a patch.)
   2.164 -\item \command{patch} cannot represent empty files, so you cannot use
   2.165 -  a patch to represent the notion ``I added this empty file to the
   2.166 -  tree''.
   2.167 +\item Debería ser obvio que \command{patch} no puede manipular
   2.168 +  ficheros binarios.
   2.169 +\item No se preocupa por el bit ejecutable; crea ficheros nuevos en
   2.170 +  modo lectura, pero no ejecutable.
   2.171 +\item \command{patch} intenta eliminar un fichero como una diferencia
   2.172 +  entre el fichero a eliminar y un fichero vacío.  Y por lo tanto su
   2.173 +  idea de ``Borré este fichero'' debería pensarse como ``toda línea de
   2.174 +  este fichero fue eliminada'' en un parche.
   2.175 +\item Trata la adición de un fichero como un diff entre un fichero
   2.176 +  vacío y el fichero a ser adicionado.  Por lo tanto en un parche su
   2.177 +  idea de ``Añadí este fichero'' se vería como ``toda línea de este
   2.178 +  fichero fue añadida''.
   2.179 +\item Trata el renombramiento de un fichero como la eliminación del
   2.180 +  nombre anterior y la adición del nuevo nombre.  Esto significa que
   2.181 +  los ficheros renombrados dejan un rastro grande en los parches.
   2.182 +  (Tenga en cuenta que Mercurial no trata de inferir cuando los
   2.183 +  archivos han sido renombrados o copiados en un parche en este
   2.184 +  momento.)
   2.185 +\item \command{patch} no puede representar ficheros vacíos, por lo
   2.186 +  tanto no puede usar un parche para representar la noción ``Añadí
   2.187 +  este fichero vacío al árbol''.
   2.188  \end{itemize}
   2.189 -\subsection{Beware the fuzz}
   2.190 +\subsection{Cuidado con los difusos}
   2.191  
   2.192  While applying a hunk at an offset, or with a fuzz factor, will often
   2.193  be completely successful, these inexact techniques naturally leave