1.1 --- a/es/undo.tex	Sun Nov 02 19:24:30 2008 -0500
     1.2 +++ b/es/undo.tex	Sun Nov 02 21:00:40 2008 -0500
     1.3 @@ -246,7 +246,7 @@
     1.4  retrocediendo. En este ejemplo, colocamos un mensaje en la
     1.5  consignación usando la opción \hgopt{backout}{-m} .
     1.6  
     1.7 -\subsection{Retroceder el conjunto de cambios tip}
     1.8 +\subsection{Retroceder el conjunto de cambios punta}
     1.9  
    1.10  Comenzamos retrocediendo el último conjunto de cambios que consignamos.
    1.11  \interaction{backout.simple}
    1.12 @@ -267,7 +267,7 @@
    1.13    \label{fig:undo:backout}
    1.14  \end{figure}
    1.15  
    1.16 -\subsection{Retroceso de un cambio que no es tip}
    1.17 +\subsection{Retroceso de un cambio que no es la punta}
    1.18  
    1.19  Si desea retrocede un cambio distinto al último que ha consignado, use
    1.20  la opción \hgopt{backout}{--merge} a la orden \hgcmd{backout}.
    1.21 @@ -296,7 +296,7 @@
    1.22  \begin{figure}[htb]
    1.23    \centering
    1.24    \grafix{undo-non-tip}
    1.25 -  \caption{Retroceso automatizado de un cambio a algo que no es tip con la orden \hgcmd{backout}}
    1.26 +  \caption{Retroceso automatizado de un cambio a algo que no es la punta con la orden \hgcmd{backout}}
    1.27    \label{fig:undo:backout-non-tip}
    1.28  \end{figure}
    1.29  
    1.30 @@ -304,119 +304,122 @@
    1.31  poco de historia adicional que deshace el efecto de un conjunto de
    1.32  cambios que usted quería evitar.
    1.33  
    1.34 -\subsubsection{Always use the \hgopt{backout}{--merge} option}
    1.35 -
    1.36 -In fact, since the \hgopt{backout}{--merge} option will do the ``right
    1.37 -thing'' whether or not the changeset you're backing out is the tip
    1.38 -(i.e.~it won't try to merge if it's backing out the tip, since there's
    1.39 -no need), you should \emph{always} use this option when you run the
    1.40 -\hgcmd{backout} command.
    1.41 -
    1.42 -\subsection{Gaining more control of the backout process}
    1.43 -
    1.44 -While I've recommended that you always use the
    1.45 -\hgopt{backout}{--merge} option when backing out a change, the
    1.46 -\hgcmd{backout} command lets you decide how to merge a backout
    1.47 -changeset.  Taking control of the backout process by hand is something
    1.48 -you will rarely need to do, but it can be useful to understand what
    1.49 -the \hgcmd{backout} command is doing for you automatically.  To
    1.50 -illustrate this, let's clone our first repository, but omit the
    1.51 -backout change that it contains.
    1.52 +\subsubsection{Use siempre la opción \hgopt{backout}{--merge}}
    1.53 +
    1.54 +De hecho, dado que la opción \hgopt{backout}{--merge} siempre hara lo
    1.55 +``correcto'' esté o no retrocediendo el conjunto de cambios punta
    1.56 +(p.e.~no tratará de fusionar si está retrocediendo la punta, dado que
    1.57 +no es necesario), usted debería usar \emph{siempre} esta opción cuando
    1.58 +ejecuta la orden \hgcmd{backout}.
    1.59 +
    1.60 +\subsection{Más control sobre el proceso de retroceso}
    1.61 +
    1.62 +A pesar de que recomiendo usar siempre la opción 
    1.63 +\hgopt{backout}{--merge} cuando está retrocediendo un cambio, la orden
    1.64 +\hgcmd{backout} le permite decidir cómo mezclar un retroceso de un
    1.65 +conjunto de cambios.  Es muy extraño que usted necestite tomar control
    1.66 +del proceso de retroceso de forma manual, pero puede ser útil entender
    1.67 +lo que la orden \hgcmd{backout} está haciendo automáticamente para
    1.68 +usted. Para ilustrarlo, clonemos nuestro primer repositorio, pero
    1.69 +omitamos el retroceso que contiene.
    1.70  
    1.71  \interaction{backout.manual.clone}
    1.72 -As with our earlier example, We'll commit a third changeset, then back
    1.73 -out its parent, and see what happens.
    1.74 +Como en el ejemplo anterior, consignaremos un tercer cambio, después
    1.75 +haremos retroceso de su padre, y veremos qué pasa.
    1.76  \interaction{backout.manual.backout} 
    1.77 -Our new changeset is again a descendant of the changeset we backout
    1.78 -out; it's thus a new head, \emph{not} a descendant of the changeset
    1.79 -that was the tip.  The \hgcmd{backout} command was quite explicit in
    1.80 -telling us this.
    1.81 +Nuestro nuevo conjunto de cambios es de nuevo un descendiente del
    1.82 +conjunto de cambio que retrocedimos; es por lo tanto una nueva cabeza,
    1.83 +\emph{no} un descendiente del conjunto de cambios que era la punta. La
    1.84 +orden \hgcmd{backout} fue muy explícita diciéndolo.
    1.85  \interaction{backout.manual.log}
    1.86  
    1.87 -Again, it's easier to see what has happened by looking at a graph of
    1.88 -the revision history, in figure~\ref{fig:undo:backout-manual}.  This
    1.89 -makes it clear that when we use \hgcmd{backout} to back out a change
    1.90 -other than the tip, Mercurial adds a new head to the repository (the
    1.91 -change it committed is box-shaped).
    1.92 +De nuevo, es más sencillo lo que pasó viendo una gráfica de la
    1.93 +historia de revisiones, en la figura~\ref{fig:undo:backout-manual}.
    1.94 +Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un
    1.95 +cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al
    1.96 +repositorio (el cambio que consignó está encerrado en una caja).
    1.97  
    1.98  \begin{figure}[htb]
    1.99    \centering
   1.100    \grafix{undo-manual}
   1.101 -  \caption{Backing out a change using the \hgcmd{backout} command}
   1.102 +  \caption{Retroceso usando la orden \hgcmd{backout}}
   1.103    \label{fig:undo:backout-manual}
   1.104  \end{figure}
   1.105  
   1.106 -After the \hgcmd{backout} command has completed, it leaves the new
   1.107 -``backout'' changeset as the parent of the working directory.
   1.108 +Después de que la orden \hgcmd{backout} ha terminado, deja un nuevo
   1.109 +conjunto de cambios de ``retroceso'' como el padre del directorio de trabajo.
   1.110  \interaction{backout.manual.parents}
   1.111 -Now we have two isolated sets of changes.
   1.112 +Ahora tenemos dos conjuntos de cambios aislados.
   1.113  \interaction{backout.manual.heads}
   1.114  
   1.115 -Let's think about what we expect to see as the contents of
   1.116 -\filename{myfile} now.  The first change should be present, because
   1.117 -we've never backed it out.  The second change should be missing, as
   1.118 -that's the change we backed out.  Since the history graph shows the
   1.119 -third change as a separate head, we \emph{don't} expect to see the
   1.120 -third change present in \filename{myfile}.
   1.121 +Reflexionemos acerca de lo que esperamos ver como contenidos de
   1.122 +\filename{myfile}.  El primer cambio debería estar presente, porque
   1.123 +nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
   1.124 +puesto que es el que retrocedimos.  Dado que la gráfica de la historia
   1.125 +muestra que el tercer camlio es una cabeza separada, \emph{no}
   1.126 +esperamos ver el tercer cambio presente en \filename{myfile}.
   1.127  \interaction{backout.manual.cat}
   1.128 -To get the third change back into the file, we just do a normal merge
   1.129 -of our two heads.
   1.130 +Para que el tercer cambio esté en el archivo, hacemos una fusión usual
   1.131 +de las dos cabezas.
   1.132  \interaction{backout.manual.merge}
   1.133 -Afterwards, the graphical history of our repository looks like
   1.134 -figure~\ref{fig:undo:backout-manual-merge}.
   1.135 +Después de eso, la historia gráfica de nuestro repositorio luce como
   1.136 +la figura~\ref{fig:undo:backout-manual-merge}.
   1.137  
   1.138  \begin{figure}[htb]
   1.139    \centering
   1.140    \grafix{undo-manual-merge}
   1.141 -  \caption{Manually merging a backout change}
   1.142 +  \caption{Fusión manual de un retroceso}
   1.143    \label{fig:undo:backout-manual-merge}
   1.144  \end{figure}
   1.145  
   1.146 -\subsection{Why \hgcmd{backout} works as it does}
   1.147 -
   1.148 -Here's a brief description of how the \hgcmd{backout} command works.
   1.149 +\subsection{Por qué \hgcmd{backout} hace lo que hace}
   1.150 +
   1.151 +Esta es una descripción corta de cómo trabaja la orden \hgcmd{backout}.
   1.152  \begin{enumerate}
   1.153 -\item It ensures that the working directory is ``clean'', i.e.~that
   1.154 -  the output of \hgcmd{status} would be empty.
   1.155 -\item It remembers the current parent of the working directory.  Let's
   1.156 -  call this changeset \texttt{orig}
   1.157 -\item It does the equivalent of a \hgcmd{update} to sync the working
   1.158 -  directory to the changeset you want to back out.  Let's call this
   1.159 -  changeset \texttt{backout}
   1.160 -\item It finds the parent of that changeset.  Let's call that
   1.161 -  changeset \texttt{parent}.
   1.162 -\item For each file that the \texttt{backout} changeset affected, it
   1.163 -  does the equivalent of a \hgcmdargs{revert}{-r parent} on that file,
   1.164 -  to restore it to the contents it had before that changeset was
   1.165 -  committed.
   1.166 -\item It commits the result as a new changeset.  This changeset has
   1.167 -  \texttt{backout} as its parent.
   1.168 -\item If you specify \hgopt{backout}{--merge} on the command line, it
   1.169 -  merges with \texttt{orig}, and commits the result of the merge.
   1.170 +\item Se asegura de que el directorio de trabajo es ``limpio'', esto
   1.171 +  es, que la salida de \hgcmd{status} debería ser vacía.
   1.172 +\item Recuerda el padre actual del directorio de trabajo. A este
   1.173 +  conjunto de cambio lo llamaremos \texttt{orig}
   1.174 +\item Hace el equivalente de un \hgcmd{update} para sincronizar el
   1.175 +  directorio de trabajo con el conjunto de cambios que usted quiere
   1.176 +  retroceder. Lo llamaremos \texttt{backout}
   1.177 +\item Encuentra el padre del conjunto de cambios. Lo llamaremos
   1.178 +  \texttt{parent}.
   1.179 +\item Para cada archivo del conjunto de cambios que el
   1.180 +  \texttt{retroceso} afecte, hará el equivalente a
   1.181 +  \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a
   1.182 +  los contenidos que tenía antes de que el conjunto de cambios fuera
   1.183 +  consignado.
   1.184 +\item Se consigna el resultado como un nuevo conjunto de cambios y
   1.185 +  tiene a  \texttt{backout} como su padre.
   1.186 +\item Si especifica \hgopt{backout}{--merge} en la línea de comandos,
   1.187 +  se fusiona con \texttt{orig}, y se consigna el resultado de la
   1.188 +  fusión.
   1.189  \end{enumerate}
   1.190  
   1.191 -An alternative way to implement the \hgcmd{backout} command would be
   1.192 -to \hgcmd{export} the to-be-backed-out changeset as a diff, then use
   1.193 -the \cmdopt{patch}{--reverse} option to the \command{patch} command to
   1.194 -reverse the effect of the change without fiddling with the working
   1.195 -directory.  This sounds much simpler, but it would not work nearly as
   1.196 -well.
   1.197 -
   1.198 -The reason that \hgcmd{backout} does an update, a commit, a merge, and
   1.199 -another commit is to give the merge machinery the best chance to do a
   1.200 -good job when dealing with all the changes \emph{between} the change
   1.201 -you're backing out and the current tip.  
   1.202 -
   1.203 -If you're backing out a changeset that's~100 revisions back in your
   1.204 -project's history, the chances that the \command{patch} command will
   1.205 -be able to apply a reverse diff cleanly are not good, because
   1.206 -intervening changes are likely to have ``broken the context'' that
   1.207 -\command{patch} uses to determine whether it can apply a patch (if
   1.208 -this sounds like gibberish, see \ref{sec:mq:patch} for a
   1.209 -discussion of the \command{patch} command).  Also, Mercurial's merge
   1.210 -machinery will handle files and directories being renamed, permission
   1.211 -changes, and modifications to binary files, none of which
   1.212 -\command{patch} can deal with.
   1.213 +Una vía alternativa de implementar la orden \hgcmd{backout} sería usar
   1.214 +\hgcmd{export} sobre el conjunto de cambios a retroceder como un diff
   1.215 +y después usar laa opción \cmdopt{patch}{--reverse} de la orden
   1.216 +\command{patch} para reversar el efecto del cambio sin molestar el
   1.217 +directorio de trabajo.  Suena mucho más simple, pero no funcionaría
   1.218 +bien ni de cerca.
   1.219 +
   1.220 +La razón por la cual \hgcmd{backout} hace una actualización, una
   1.221 +consignación, una fusión y otra consignación es para dar a la
   1.222 +maquinaria de fusión la mayor oportunidad de hacer un buen trabajo
   1.223 +cuando se trata con todos los cambios \emph{entre} el cambio que está
   1.224 +retrocediendo y la punta actual.
   1.225 +
   1.226 +Si está retrocediendo un conjunto de cambios que está a unas ~100
   1.227 +atrás en su historia del proyecto, las posibilidades de que una orden
   1.228 +\command{patch} sea capaz de ser aplicada a un diff reverso,
   1.229 +claramente no son altas, porque los cambios que intervienen podrían
   1.230 +``no coincidir con el contexto'' que \command{patch} usa  para
   1.231 +determinar si puede aplicar un parche (si esto suena como cháchara,
   1.232 +vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}).
   1.233 +Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros
   1.234 +y directorios renombrados, cambios de permisos, y modificaciones a
   1.235 +archivos binarios, nada de lo cual la orden \command{patch} puede manejar.
   1.236  
   1.237  \section{Changes that should never have been}
   1.238  \label{sec:undo:aaaiiieee}