hgbook
changeset 394:b286919e0d61
merged changes from Igor
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Mon Nov 03 21:04:25 2008 -0500 (2008-11-03) |
parents | 2c2c86824c61 b7d4d66c3ae5 |
children | 149ea8ae39c4 |
files | es/Leame.1st |
line diff
1.1 --- a/es/Leame.1st Mon Nov 03 21:00:32 2008 -0500 1.2 +++ b/es/Leame.1st Mon Nov 03 21:04:25 2008 -0500 1.3 @@ -99,15 +99,17 @@ 1.4 || preface.tex || Javier Rojas || 100% || 18/10/2008 || 19/10/2008 || 1.5 || daily.tex || Igor Támara || 100% || 19/10/2008 || 26/10/2008 || 1.6 || tour-basic.tex || Javier Rojas || 100% || 19/10/2008 || 27/10/2008 || 1.7 -|| undo.tex || Igor Támara || 15% || 26/10/2008 || || 1.8 +|| undo.tex || Igor Támara || 60% || 26/10/2008 || || 1.9 || tour-merge.tex || Javier Rojas || 100% || 28/10/2008 || 03/11/2008 || 1.10 || concepts.tex || Javier Rojas || 4% || 03/11/2008 || || 1.11 1.12 == Archivos en proceso de revisión == 1.13 -||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''|| '''Fin''' || 1.14 -|| 00book.tex || || || || || 1.15 -|| branch.tex || || || || || 1.16 -|| preface.tex || || || || || 1.17 +||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''|| '''Fin''' || 1.18 +|| 00book.tex || || || || || 1.19 +|| branch.tex || || || || || 1.20 +|| preface.tex || || || || || 1.21 +|| daily.tex || || || || || 1.22 +|| tour-basic.tex || || || || || 1.23 1.24 == Archivos terminados == 1.25 1.26 @@ -129,6 +131,7 @@ 1.27 versión traducida, y una pequeña explicación como justificación. 1.28 1.29 Anne: Ana 1.30 + Back out: Retroceder 1.31 Bob : Roberto 1.32 Branch: Rama 1.33 Bug: Fallo 1.34 @@ -154,6 +157,7 @@ 1.35 Roll back: NO se traduce Ver más abajo 1.36 Snapshot: instantánea 1.37 Tip: punta 1.38 + Update: actualización 1.39 1.40 abort -> cancelar 1.41
2.1 --- a/es/undo.tex Mon Nov 03 21:00:32 2008 -0500 2.2 +++ b/es/undo.tex Mon Nov 03 21:04:25 2008 -0500 2.3 @@ -121,346 +121,356 @@ 2.4 repositorio, no podrá volver a hacer rollback hasta que haga una 2.5 consignación o haya jalado. 2.6 2.7 -\section{Reverting the mistaken change} 2.8 - 2.9 -If you make a modification to a file, and decide that you really 2.10 -didn't want to change the file at all, and you haven't yet committed 2.11 -your changes, the \hgcmd{revert} command is the one you'll need. It 2.12 -looks at the changeset that's the parent of the working directory, and 2.13 -restores the contents of the file to their state as of that changeset. 2.14 -(That's a long-winded way of saying that, in the normal case, it 2.15 -undoes your modifications.) 2.16 - 2.17 -Let's illustrate how the \hgcmd{revert} command works with yet another 2.18 -small example. We'll begin by modifying a file that Mercurial is 2.19 -already tracking. 2.20 +\section{Revertir un cambio equivocado} 2.21 + 2.22 +Si modifica un fichero y se da cuenta que no quería realmente cambiar 2.23 +tal fichero, y todavía no ha consignado los cambios, la orden 2.24 +necesaria es \hgcmd{revert}. Observa el conjunto de cambios padre del 2.25 +directorio y restaura los contenidos del fichero al estado de tal 2.26 +conjunto de cambios. (Es una forma larga de decirlo, usualmente 2.27 +deshace sus modificaciones.) 2.28 + 2.29 +Ilustremos como actúa la orden \hgcmd{revert} con un ejemplo 2.30 +pequeño. Comenzaremos modificando un fichero al cual Mercurial ya está 2.31 +siguiendo. 2.32 \interaction{daily.revert.modify} 2.33 -If we don't want that change, we can simply \hgcmd{revert} the file. 2.34 +Si no queremos ese cambio, podemos aplicar \hgcmd{revert} al fichero. 2.35 \interaction{daily.revert.unmodify} 2.36 -The \hgcmd{revert} command provides us with an extra degree of safety 2.37 -by saving our modified file with a \filename{.orig} extension. 2.38 +La orden \hgcmd{revert} nos brinda un grado adicional de seguridad 2.39 +guardando nuestro fichero modificado con la extensión \filename{.orig}. 2.40 \interaction{daily.revert.status} 2.41 2.42 -Here is a summary of the cases that the \hgcmd{revert} command can 2.43 -deal with. We will describe each of these in more detail in the 2.44 -section that follows. 2.45 +Este es un resumen de casos en los cuales la orden \hgcmd{revert} es 2.46 +de utilidad. Describiremos cada uno de ellos con más detalle en la 2.47 +sección siguiente. 2.48 \begin{itemize} 2.49 -\item If you modify a file, it will restore the file to its unmodified 2.50 - state. 2.51 -\item If you \hgcmd{add} a file, it will undo the ``added'' state of 2.52 - the file, but leave the file itself untouched. 2.53 -\item If you delete a file without telling Mercurial, it will restore 2.54 - the file to its unmodified contents. 2.55 -\item If you use the \hgcmd{remove} command to remove a file, it will 2.56 - undo the ``removed'' state of the file, and restore the file to its 2.57 - unmodified contents. 2.58 +\item Si usted modifica un fichero, lo restaurará a su estado sin 2.59 + modificación previo. 2.60 +\item Si usted hace \hgcmd{add} a un fichero, revertirá el estado de 2.61 + ``adicionado'' del fichero, pero no lo tocará 2.62 +\item Si borra un fichero sin decirle a Mercurial, restaurará el 2.63 + fichero con sus contenidos sin modificación. 2.64 +\item Si usa la orden \hgcmd{remove} para eliminar un fichero, deshará 2.65 + el estado ``removido'' del fichero, y lo restaurará con sus 2.66 + contenidos sin modificación. 2.67 \end{itemize} 2.68 2.69 -\subsection{File management errors} 2.70 +\subsection{Errores al administrar ficheros} 2.71 \label{sec:undo:mgmt} 2.72 2.73 -The \hgcmd{revert} command is useful for more than just modified 2.74 -files. It lets you reverse the results of all of Mercurial's file 2.75 -management commands---\hgcmd{add}, \hgcmd{remove}, and so on. 2.76 - 2.77 -If you \hgcmd{add} a file, then decide that in fact you don't want 2.78 -Mercurial to track it, use \hgcmd{revert} to undo the add. Don't 2.79 -worry; Mercurial will not modify the file in any way. It will just 2.80 -``unmark'' the file. 2.81 +La orden \hgcmd{revert} es útil para más que ficheros modificados. Le 2.82 +permite reversar los resultados de todas las órdenes de administración 2.83 +de ficheros que provee Mercurial---\hgcmd{add}, \hgcmd{remove}, y las 2.84 +demás. 2.85 + 2.86 +Si usted hace \hgcmd{add} a un fichero, y no deseaba que Mercurial le 2.87 +diera seguimiento, use \hgcmd{revert} para deshacer la adición. No se 2.88 +preocupe; Mercurial no modificará de forma alguna el fichero. 2.89 +Solamente lo ``desmarcará''. 2.90 \interaction{daily.revert.add} 2.91 2.92 -Similarly, if you ask Mercurial to \hgcmd{remove} a file, you can use 2.93 -\hgcmd{revert} to restore it to the contents it had as of the parent 2.94 -of the working directory. 2.95 +De forma similar, Si le solicita a Mercurial hacer \hgcmd{remove} a un 2.96 +fichero, puede usar \hgcmd{revert} para restarurarlo a los contenidos 2.97 +que tenía la revisión padre del directorio de trabajo. 2.98 \interaction{daily.revert.remove} 2.99 -This works just as well for a file that you deleted by hand, without 2.100 -telling Mercurial (recall that in Mercurial terminology, this kind of 2.101 -file is called ``missing''). 2.102 +Funciona de la misma manera para un fichero que usted haya eliminado 2.103 +manualmente, sin decirle a Mercurial (recuerde que en la terminología 2.104 +de Mercurial esta clase de fichero se llama ``faltante''). 2.105 \interaction{daily.revert.missing} 2.106 2.107 -If you revert a \hgcmd{copy}, the copied-to file remains in your 2.108 -working directory afterwards, untracked. Since a copy doesn't affect 2.109 -the copied-from file in any way, Mercurial doesn't do anything with 2.110 -the copied-from file. 2.111 +Si usted revierte un \hgcmd{copy}, el fichero a donde se copió 2.112 +permanece en su directorio de trabajo, pero sin seguimiento. Dado que 2.113 +una copia no afecta el fichero fuente de copiado de ninguna maner, 2.114 +Mercurial no hace nada con este. 2.115 \interaction{daily.revert.copy} 2.116 2.117 -\subsubsection{A slightly special case: reverting a rename} 2.118 - 2.119 -If you \hgcmd{rename} a file, there is one small detail that 2.120 -you should remember. When you \hgcmd{revert} a rename, it's not 2.121 -enough to provide the name of the renamed-to file, as you can see 2.122 -here. 2.123 +\subsubsection{Un caso ligeramente especial:revertir un renombramiento} 2.124 + 2.125 +Si hace \hgcmd{rename} a un fichero, hay un detalle que debe tener en 2.126 +cuenta. Cuando aplica \hgcmd{revert} a un cambio de nombre, no es 2.127 +suficiente proveer el nombre del fichero destino, como puede verlo en 2.128 +el siguiente ejemplo. 2.129 \interaction{daily.revert.rename} 2.130 -As you can see from the output of \hgcmd{status}, the renamed-to file 2.131 -is no longer identified as added, but the renamed-\emph{from} file is 2.132 -still removed! This is counter-intuitive (at least to me), but at 2.133 -least it's easy to deal with. 2.134 +Como puede ver en la salida de \hgcmd{status}, el fichero con el nuevo 2.135 +nombre no se identifica más como agregado, pero el fichero con el 2.136 +nombre-\emph{inicial} se elimna! Esto es contra-intuitivo (por lo 2.137 +menos para mí), pero por lo menos es fácil arreglarlo. 2.138 \interaction{daily.revert.rename-orig} 2.139 -So remember, to revert a \hgcmd{rename}, you must provide \emph{both} 2.140 -the source and destination names. 2.141 +Por lo tanto, recuerde, para revertir un \hgcmd{rename}, debe proveer 2.142 +\emph{ambos} nombres, la fuente y el destino. 2.143 2.144 % TODO: the output doesn't look like it will be removed! 2.145 2.146 -(By the way, if you rename a file, then modify the renamed-to file, 2.147 -then revert both components of the rename, when Mercurial restores the 2.148 -file that was removed as part of the rename, it will be unmodified. 2.149 -If you need the modifications in the renamed-to file to show up in the 2.150 -renamed-from file, don't forget to copy them over.) 2.151 - 2.152 -These fiddly aspects of reverting a rename arguably constitute a small 2.153 -bug in Mercurial. 2.154 - 2.155 -\section{Dealing with committed changes} 2.156 - 2.157 -Consider a case where you have committed a change $a$, and another 2.158 -change $b$ on top of it; you then realise that change $a$ was 2.159 -incorrect. Mercurial lets you ``back out'' an entire changeset 2.160 -automatically, and building blocks that let you reverse part of a 2.161 -changeset by hand. 2.162 - 2.163 -Before you read this section, here's something to keep in mind: the 2.164 -\hgcmd{backout} command undoes changes by \emph{adding} history, not 2.165 -by modifying or erasing it. It's the right tool to use if you're 2.166 -fixing bugs, but not if you're trying to undo some change that has 2.167 -catastrophic consequences. To deal with those, see 2.168 -section~\ref{sec:undo:aaaiiieee}. 2.169 - 2.170 -\subsection{Backing out a changeset} 2.171 - 2.172 -The \hgcmd{backout} command lets you ``undo'' the effects of an entire 2.173 -changeset in an automated fashion. Because Mercurial's history is 2.174 -immutable, this command \emph{does not} get rid of the changeset you 2.175 -want to undo. Instead, it creates a new changeset that 2.176 -\emph{reverses} the effect of the to-be-undone changeset. 2.177 - 2.178 -The operation of the \hgcmd{backout} command is a little intricate, so 2.179 -let's illustrate it with some examples. First, we'll create a 2.180 -repository with some simple changes. 2.181 +(A propósito, si elimina un fichero, y modifica el fichero con el 2.182 +nuevo nombre, al revertir ambos componentes del renombramiento, cuando 2.183 +Mercurial restaure el fichero que fue eliminado como parte del 2.184 +renombramiento, no será modificado. 2.185 +Si necesita que las modificaciones en el archivo destino del 2.186 +renombramiento se muestren, no olvide copiarlas encima.) 2.187 + 2.188 +Estos aspectos engorrosos al revertir un renombramiento se constituyen 2.189 +discutiblemente en un fallo de Mercurial. 2.190 + 2.191 +\section{Tratar cambios consignados} 2.192 + 2.193 +Considere un caso en el que ha consignado el cambio $a$, y otro cambio 2.194 +$b$ sobre este; se ha dado cuenta que el cambio $a$ era 2.195 +incorrecto. Mercurial le permite ``retroceder'' un conjunto de cambios 2.196 +completo automáticamente, y construir bloques que le permitan revertir 2.197 +parte de un conjunto de cambios a mano. 2.198 + 2.199 +Antes de leer esta sección, hay algo para tener en cuenta: la orden 2.200 +\hgcmd{backout} deshace cambios \emph{adicionando} a la historia, sin 2.201 +modificar o borrar. Es la herramienta correcta si está arreglando 2.202 +fallos, pero no si está tratando de deshacer algún cambio que tiene 2.203 +consecuencias catastróficas. Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}. 2.204 + 2.205 +\subsection{Retroceder un conjunto de cambios} 2.206 + 2.207 +La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo 2.208 +un conjunto de cambios de forma automatizada. Dado que la historia de 2.209 +Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto 2.210 +de cambios que usted desea deshacer. En cambio, crea un nuevo 2.211 +conjunto de cambios que \emph{reversa} el conjunto de cambios que 2.212 +usted indique. 2.213 + 2.214 +La operación de la orden \hgcmd{backout} es un poco intrincada, y lo 2.215 +ilustraremos con algunos ejemplos. Primero crearemos un repositorio 2.216 +con algunos cambios sencillos. 2.217 \interaction{backout.init} 2.218 2.219 -The \hgcmd{backout} command takes a single changeset ID as its 2.220 -argument; this is the changeset to back out. Normally, 2.221 -\hgcmd{backout} will drop you into a text editor to write a commit 2.222 -message, so you can record why you're backing the change out. In this 2.223 -example, we provide a commit message on the command line using the 2.224 -\hgopt{backout}{-m} option. 2.225 - 2.226 -\subsection{Backing out the tip changeset} 2.227 - 2.228 -We're going to start by backing out the last changeset we committed. 2.229 +La orden \hgcmd{backout} toma un ID de conjunto de cambios como su 2.230 +argumento; el conjunto de cambios a retroceder. Normalmente 2.231 +\hgcmd{backout} le ofrecerá un editor de texto para escribir el 2.232 +mensaje de la consignación, para dejar un registro de por qué está 2.233 +retrocediendo. En este ejemplo, colocamos un mensaje en la 2.234 +consignación usando la opción \hgopt{backout}{-m} . 2.235 + 2.236 +\subsection{Retroceder el conjunto de cambios punta} 2.237 + 2.238 +Comenzamos retrocediendo el último conjunto de cambios que consignamos. 2.239 \interaction{backout.simple} 2.240 -You can see that the second line from \filename{myfile} is no longer 2.241 -present. Taking a look at the output of \hgcmd{log} gives us an idea 2.242 -of what the \hgcmd{backout} command has done. 2.243 +Puede ver que la segunda línea de \filename{myfile} ya no está 2.244 +presente. La salida de \hgcmd{log} nos da una idea de lo que la orden 2.245 +\hgcmd{backout} ha hecho. 2.246 \interaction{backout.simple.log} 2.247 -Notice that the new changeset that \hgcmd{backout} has created is a 2.248 -child of the changeset we backed out. It's easier to see this in 2.249 -figure~\ref{fig:undo:backout}, which presents a graphical view of the 2.250 -change history. As you can see, the history is nice and linear. 2.251 +Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es 2.252 +un hijo del conjunto de cambios que retrocedimos. Es más sencillo de 2.253 +ver en la figura~\ref{fig:undo:backout}, que presenta una vista 2.254 +gráfica de la historia de cambios. Como puede ver, la historia es 2.255 +bonita y lineal. 2.256 2.257 \begin{figure}[htb] 2.258 \centering 2.259 \grafix{undo-simple} 2.260 - \caption{Backing out a change using the \hgcmd{backout} command} 2.261 + \caption{Retroceso de un cambio con la orden \hgcmd{backout}} 2.262 \label{fig:undo:backout} 2.263 \end{figure} 2.264 2.265 -\subsection{Backing out a non-tip change} 2.266 - 2.267 -If you want to back out a change other than the last one you 2.268 -committed, pass the \hgopt{backout}{--merge} option to the 2.269 -\hgcmd{backout} command. 2.270 +\subsection{Retroceso de un cambio que no es la punta} 2.271 + 2.272 +Si desea retrocede un cambio distinto al último que ha consignado, use 2.273 +la opción \hgopt{backout}{--merge} a la orden \hgcmd{backout}. 2.274 \interaction{backout.non-tip.clone} 2.275 -This makes backing out any changeset a ``one-shot'' operation that's 2.276 -usually simple and fast. 2.277 +Que resulta en un retroceso de un conjunto de cambios ``en un sólo 2.278 +tiro'', una operación que resulta normalmente rápida y sencilla. 2.279 \interaction{backout.non-tip.backout} 2.280 2.281 -If you take a look at the contents of \filename{myfile} after the 2.282 -backout finishes, you'll see that the first and third changes are 2.283 -present, but not the second. 2.284 +Si ve los contenidos del fichero \filename{myfile} después de 2.285 +finalizar el retroceso, verá que el primer y el tercer cambio están 2.286 +presentes, pero no el segundo. 2.287 \interaction{backout.non-tip.cat} 2.288 2.289 -As the graphical history in figure~\ref{fig:undo:backout-non-tip} 2.290 -illustrates, Mercurial actually commits \emph{two} changes in this 2.291 -kind of situation (the box-shaped nodes are the ones that Mercurial 2.292 -commits automatically). Before Mercurial begins the backout process, 2.293 -it first remembers what the current parent of the working directory 2.294 -is. It then backs out the target changeset, and commits that as a 2.295 -changeset. Finally, it merges back to the previous parent of the 2.296 -working directory, and commits the result of the merge. 2.297 +Como lo muestra la historia gráfica en la 2.298 +figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna 2.299 +\emph{dos} cambios en estas situaciones (los nodos encerrados en una 2.300 +caja son aquellos que Mercurial consigna automaticamente). Antes de 2.301 +que Mercurial comience el proceso de retroceso, primero recuerda cuál 2.302 +es el padre del directorio de trabajo. Posteriormente hace un 2.303 +retroceso al conjunto de cambios objetivo y lo consigna como un 2.304 +conjunto de cambios. Finalmente, fusiona con el padre anterior del 2.305 +directorio de trabajo, y consigna el resultado de la fusión. 2.306 2.307 % TODO: to me it looks like mercurial doesn't commit the second merge automatically! 2.308 2.309 \begin{figure}[htb] 2.310 \centering 2.311 \grafix{undo-non-tip} 2.312 - \caption{Automated backout of a non-tip change using the \hgcmd{backout} command} 2.313 + \caption{Retroceso automatizado de un cambio a algo que no es la punta con la orden \hgcmd{backout}} 2.314 \label{fig:undo:backout-non-tip} 2.315 \end{figure} 2.316 2.317 -The result is that you end up ``back where you were'', only with some 2.318 -extra history that undoes the effect of the changeset you wanted to 2.319 -back out. 2.320 - 2.321 -\subsubsection{Always use the \hgopt{backout}{--merge} option} 2.322 - 2.323 -In fact, since the \hgopt{backout}{--merge} option will do the ``right 2.324 -thing'' whether or not the changeset you're backing out is the tip 2.325 -(i.e.~it won't try to merge if it's backing out the tip, since there's 2.326 -no need), you should \emph{always} use this option when you run the 2.327 -\hgcmd{backout} command. 2.328 - 2.329 -\subsection{Gaining more control of the backout process} 2.330 - 2.331 -While I've recommended that you always use the 2.332 -\hgopt{backout}{--merge} option when backing out a change, the 2.333 -\hgcmd{backout} command lets you decide how to merge a backout 2.334 -changeset. Taking control of the backout process by hand is something 2.335 -you will rarely need to do, but it can be useful to understand what 2.336 -the \hgcmd{backout} command is doing for you automatically. To 2.337 -illustrate this, let's clone our first repository, but omit the 2.338 -backout change that it contains. 2.339 +El resultado es que usted termina ``donde estaba'', solamente con un 2.340 +poco de historia adicional que deshace el efecto de un conjunto de 2.341 +cambios que usted quería evitar. 2.342 + 2.343 +\subsubsection{Use siempre la opción \hgopt{backout}{--merge}} 2.344 + 2.345 +De hecho, dado que la opción \hgopt{backout}{--merge} siempre hara lo 2.346 +``correcto'' esté o no retrocediendo el conjunto de cambios punta 2.347 +(p.e.~no tratará de fusionar si está retrocediendo la punta, dado que 2.348 +no es necesario), usted debería usar \emph{siempre} esta opción cuando 2.349 +ejecuta la orden \hgcmd{backout}. 2.350 + 2.351 +\subsection{Más control sobre el proceso de retroceso} 2.352 + 2.353 +A pesar de que recomiendo usar siempre la opción 2.354 +\hgopt{backout}{--merge} cuando está retrocediendo un cambio, la orden 2.355 +\hgcmd{backout} le permite decidir cómo mezclar un retroceso de un 2.356 +conjunto de cambios. Es muy extraño que usted necestite tomar control 2.357 +del proceso de retroceso de forma manual, pero puede ser útil entender 2.358 +lo que la orden \hgcmd{backout} está haciendo automáticamente para 2.359 +usted. Para ilustrarlo, clonemos nuestro primer repositorio, pero 2.360 +omitamos el retroceso que contiene. 2.361 2.362 \interaction{backout.manual.clone} 2.363 -As with our earlier example, We'll commit a third changeset, then back 2.364 -out its parent, and see what happens. 2.365 +Como en el ejemplo anterior, consignaremos un tercer cambio, después 2.366 +haremos retroceso de su padre, y veremos qué pasa. 2.367 \interaction{backout.manual.backout} 2.368 -Our new changeset is again a descendant of the changeset we backout 2.369 -out; it's thus a new head, \emph{not} a descendant of the changeset 2.370 -that was the tip. The \hgcmd{backout} command was quite explicit in 2.371 -telling us this. 2.372 +Nuestro nuevo conjunto de cambios es de nuevo un descendiente del 2.373 +conjunto de cambio que retrocedimos; es por lo tanto una nueva cabeza, 2.374 +\emph{no} un descendiente del conjunto de cambios que era la punta. La 2.375 +orden \hgcmd{backout} fue muy explícita diciéndolo. 2.376 \interaction{backout.manual.log} 2.377 2.378 -Again, it's easier to see what has happened by looking at a graph of 2.379 -the revision history, in figure~\ref{fig:undo:backout-manual}. This 2.380 -makes it clear that when we use \hgcmd{backout} to back out a change 2.381 -other than the tip, Mercurial adds a new head to the repository (the 2.382 -change it committed is box-shaped). 2.383 +De nuevo, es más sencillo lo que pasó viendo una gráfica de la 2.384 +historia de revisiones, en la figura~\ref{fig:undo:backout-manual}. 2.385 +Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un 2.386 +cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al 2.387 +repositorio (el cambio que consignó está encerrado en una caja). 2.388 2.389 \begin{figure}[htb] 2.390 \centering 2.391 \grafix{undo-manual} 2.392 - \caption{Backing out a change using the \hgcmd{backout} command} 2.393 + \caption{Retroceso usando la orden \hgcmd{backout}} 2.394 \label{fig:undo:backout-manual} 2.395 \end{figure} 2.396 2.397 -After the \hgcmd{backout} command has completed, it leaves the new 2.398 -``backout'' changeset as the parent of the working directory. 2.399 +Después de que la orden \hgcmd{backout} ha terminado, deja un nuevo 2.400 +conjunto de cambios de ``retroceso'' como el padre del directorio de trabajo. 2.401 \interaction{backout.manual.parents} 2.402 -Now we have two isolated sets of changes. 2.403 +Ahora tenemos dos conjuntos de cambios aislados. 2.404 \interaction{backout.manual.heads} 2.405 2.406 -Let's think about what we expect to see as the contents of 2.407 -\filename{myfile} now. The first change should be present, because 2.408 -we've never backed it out. The second change should be missing, as 2.409 -that's the change we backed out. Since the history graph shows the 2.410 -third change as a separate head, we \emph{don't} expect to see the 2.411 -third change present in \filename{myfile}. 2.412 +Reflexionemos acerca de lo que esperamos ver como contenidos de 2.413 +\filename{myfile}. El primer cambio debería estar presente, porque 2.414 +nunca le hicimos retroceso. El segundo cambio debió desaparecer, 2.415 +puesto que es el que retrocedimos. Dado que la gráfica de la historia 2.416 +muestra que el tercer camlio es una cabeza separada, \emph{no} 2.417 +esperamos ver el tercer cambio presente en \filename{myfile}. 2.418 \interaction{backout.manual.cat} 2.419 -To get the third change back into the file, we just do a normal merge 2.420 -of our two heads. 2.421 +Para que el tercer cambio esté en el archivo, hacemos una fusión usual 2.422 +de las dos cabezas. 2.423 \interaction{backout.manual.merge} 2.424 -Afterwards, the graphical history of our repository looks like 2.425 -figure~\ref{fig:undo:backout-manual-merge}. 2.426 +Después de eso, la historia gráfica de nuestro repositorio luce como 2.427 +la figura~\ref{fig:undo:backout-manual-merge}. 2.428 2.429 \begin{figure}[htb] 2.430 \centering 2.431 \grafix{undo-manual-merge} 2.432 - \caption{Manually merging a backout change} 2.433 + \caption{Fusión manual de un retroceso} 2.434 \label{fig:undo:backout-manual-merge} 2.435 \end{figure} 2.436 2.437 -\subsection{Why \hgcmd{backout} works as it does} 2.438 - 2.439 -Here's a brief description of how the \hgcmd{backout} command works. 2.440 +\subsection{Por qué \hgcmd{backout} hace lo que hace} 2.441 + 2.442 +Esta es una descripción corta de cómo trabaja la orden \hgcmd{backout}. 2.443 \begin{enumerate} 2.444 -\item It ensures that the working directory is ``clean'', i.e.~that 2.445 - the output of \hgcmd{status} would be empty. 2.446 -\item It remembers the current parent of the working directory. Let's 2.447 - call this changeset \texttt{orig} 2.448 -\item It does the equivalent of a \hgcmd{update} to sync the working 2.449 - directory to the changeset you want to back out. Let's call this 2.450 - changeset \texttt{backout} 2.451 -\item It finds the parent of that changeset. Let's call that 2.452 - changeset \texttt{parent}. 2.453 -\item For each file that the \texttt{backout} changeset affected, it 2.454 - does the equivalent of a \hgcmdargs{revert}{-r parent} on that file, 2.455 - to restore it to the contents it had before that changeset was 2.456 - committed. 2.457 -\item It commits the result as a new changeset. This changeset has 2.458 - \texttt{backout} as its parent. 2.459 -\item If you specify \hgopt{backout}{--merge} on the command line, it 2.460 - merges with \texttt{orig}, and commits the result of the merge. 2.461 +\item Se asegura de que el directorio de trabajo es ``limpio'', esto 2.462 + es, que la salida de \hgcmd{status} debería ser vacía. 2.463 +\item Recuerda el padre actual del directorio de trabajo. A este 2.464 + conjunto de cambio lo llamaremos \texttt{orig} 2.465 +\item Hace el equivalente de un \hgcmd{update} para sincronizar el 2.466 + directorio de trabajo con el conjunto de cambios que usted quiere 2.467 + retroceder. Lo llamaremos \texttt{backout} 2.468 +\item Encuentra el padre del conjunto de cambios. Lo llamaremos 2.469 + \texttt{parent}. 2.470 +\item Para cada archivo del conjunto de cambios que el 2.471 + \texttt{retroceso} afecte, hará el equivalente a 2.472 + \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a 2.473 + los contenidos que tenía antes de que el conjunto de cambios fuera 2.474 + consignado. 2.475 +\item Se consigna el resultado como un nuevo conjunto de cambios y 2.476 + tiene a \texttt{backout} como su padre. 2.477 +\item Si especifica \hgopt{backout}{--merge} en la línea de comandos, 2.478 + se fusiona con \texttt{orig}, y se consigna el resultado de la 2.479 + fusión. 2.480 \end{enumerate} 2.481 2.482 -An alternative way to implement the \hgcmd{backout} command would be 2.483 -to \hgcmd{export} the to-be-backed-out changeset as a diff, then use 2.484 -the \cmdopt{patch}{--reverse} option to the \command{patch} command to 2.485 -reverse the effect of the change without fiddling with the working 2.486 -directory. This sounds much simpler, but it would not work nearly as 2.487 -well. 2.488 - 2.489 -The reason that \hgcmd{backout} does an update, a commit, a merge, and 2.490 -another commit is to give the merge machinery the best chance to do a 2.491 -good job when dealing with all the changes \emph{between} the change 2.492 -you're backing out and the current tip. 2.493 - 2.494 -If you're backing out a changeset that's~100 revisions back in your 2.495 -project's history, the chances that the \command{patch} command will 2.496 -be able to apply a reverse diff cleanly are not good, because 2.497 -intervening changes are likely to have ``broken the context'' that 2.498 -\command{patch} uses to determine whether it can apply a patch (if 2.499 -this sounds like gibberish, see \ref{sec:mq:patch} for a 2.500 -discussion of the \command{patch} command). Also, Mercurial's merge 2.501 -machinery will handle files and directories being renamed, permission 2.502 -changes, and modifications to binary files, none of which 2.503 -\command{patch} can deal with. 2.504 - 2.505 -\section{Changes that should never have been} 2.506 +Una vía alternativa de implementar la orden \hgcmd{backout} sería usar 2.507 +\hgcmd{export} sobre el conjunto de cambios a retroceder como un diff 2.508 +y después usar laa opción \cmdopt{patch}{--reverse} de la orden 2.509 +\command{patch} para reversar el efecto del cambio sin molestar el 2.510 +directorio de trabajo. Suena mucho más simple, pero no funcionaría 2.511 +bien ni de cerca. 2.512 + 2.513 +La razón por la cual \hgcmd{backout} hace una actualización, una 2.514 +consignación, una fusión y otra consignación es para dar a la 2.515 +maquinaria de fusión la mayor oportunidad de hacer un buen trabajo 2.516 +cuando se trata con todos los cambios \emph{entre} el cambio que está 2.517 +retrocediendo y la punta actual. 2.518 + 2.519 +Si está retrocediendo un conjunto de cambios que está a unas ~100 2.520 +atrás en su historia del proyecto, las posibilidades de que una orden 2.521 +\command{patch} sea capaz de ser aplicada a un diff reverso, 2.522 +claramente no son altas, porque los cambios que intervienen podrían 2.523 +``no coincidir con el contexto'' que \command{patch} usa para 2.524 +determinar si puede aplicar un parche (si esto suena como cháchara, 2.525 +vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}). 2.526 +Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros 2.527 +y directorios renombrados, cambios de permisos, y modificaciones a 2.528 +archivos binarios, nada de lo cual la orden \command{patch} puede manejar. 2.529 + 2.530 +\section{Cambios que nunca debieron ocurrir} 2.531 \label{sec:undo:aaaiiieee} 2.532 2.533 -Most of the time, the \hgcmd{backout} command is exactly what you need 2.534 -if you want to undo the effects of a change. It leaves a permanent 2.535 -record of exactly what you did, both when committing the original 2.536 -changeset and when you cleaned up after it. 2.537 - 2.538 -On rare occasions, though, you may find that you've committed a change 2.539 -that really should not be present in the repository at all. For 2.540 -example, it would be very unusual, and usually considered a mistake, 2.541 -to commit a software project's object files as well as its source 2.542 -files. Object files have almost no intrinsic value, and they're 2.543 -\emph{big}, so they increase the size of the repository and the amount 2.544 -of time it takes to clone or pull changes. 2.545 - 2.546 -Before I discuss the options that you have if you commit a ``brown 2.547 -paper bag'' change (the kind that's so bad that you want to pull a 2.548 -brown paper bag over your head), let me first discuss some approaches 2.549 -that probably won't work. 2.550 - 2.551 -Since Mercurial treats history as accumulative---every change builds 2.552 -on top of all changes that preceded it---you generally can't just make 2.553 -disastrous changes disappear. The one exception is when you've just 2.554 -committed a change, and it hasn't been pushed or pulled into another 2.555 -repository. That's when you can safely use the \hgcmd{rollback} 2.556 -command, as I detailed in section~\ref{sec:undo:rollback}. 2.557 - 2.558 -After you've pushed a bad change to another repository, you 2.559 -\emph{could} still use \hgcmd{rollback} to make your local copy of the 2.560 -change disappear, but it won't have the consequences you want. The 2.561 -change will still be present in the remote repository, so it will 2.562 -reappear in your local repository the next time you pull. 2.563 - 2.564 -If a situation like this arises, and you know which repositories your 2.565 -bad change has propagated into, you can \emph{try} to get rid of the 2.566 -changeefrom \emph{every} one of those repositories. This is, of 2.567 -course, not a satisfactory solution: if you miss even a single 2.568 -repository while you're expunging, the change is still ``in the 2.569 -wild'', and could propagate further. 2.570 - 2.571 -If you've committed one or more changes \emph{after} the change that 2.572 -you'd like to see disappear, your options are further reduced. 2.573 -Mercurial doesn't provide a way to ``punch a hole'' in history, 2.574 -leaving changesets intact. 2.575 +En la mayoría de los casos, la orden \hgcmd{backout} es exactamente lo 2.576 +que necesita para deshacer los efectos de un cambio. Deja un registro 2.577 +permanente y exacto de lo que usted hizo, cuando se consignó el 2.578 +conjunto de cambios original y cuando se hizo la limpieza. 2.579 + 2.580 +En ocasiones particulares, puede haber consignado un cambio que no 2.581 +debería estar de ninguna forma en el repositorio. Por ejemplo, sería 2.582 +muy inusual, y considerado como una equivocación, consignar los 2.583 +archivos objeto junto con el código fuente. los ficheros objeto no 2.584 +tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el 2.585 +tamaño del repositorio y la cantidad de tiempo que se emplea al clonar 2.586 +o jalar cambios. 2.587 + 2.588 +Antes de discutir las opciones que tiene si consignó cambio del tipo 2.589 +``bolsa de papel deschable'' (el tipo que es tan malo que le gustaría 2.590 +colocarse una bolsa de papel desechable en su cabeza), permítame 2.591 +discutir primero unas aproximaciones que probablemente no funcionen. 2.592 + 2.593 +Dado que Mercurial trata de forma acumulativa la historia---cada 2.594 +cambio se coloca encima de todos los cambios que leo 2.595 +preceden---usualmente usted no puede hacer que unos cambios desastros 2.596 +desaparezcan. La única excepción es cuando usted ha acabado de 2.597 +consignar un cambio y este no ha sido publicado o jalado en otro 2.598 +repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con 2.599 +seguridad, Como detallé en la sección~\ref{sec:undo:rollback}. 2.600 + 2.601 +Después de que usted haya publicado un cambio en otro repositorio, usted 2.602 +\emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia 2.603 +local desaparezca el cambio, pero no tendrá las consecuencias que 2.604 +desea. El cambio estará presente en un repositorio remoto, y 2.605 +reaparecerá en su repositorio local la próxima vez que jale 2.606 + 2.607 +Si una situación como esta se presenta, y usted sabe en qué 2.608 +repositorios su mal cambio se ha propagado, puede \emph{intentar} 2.609 +deshacerse del conjunto de cambios de \emph{todos} los repositorios en 2.610 +los que se pueda encontrar. Esta por supuesto, no es una solución 2.611 +satisfactoria: si usted deja de hacerlo en un solo repositorio, 2.612 +mientras esté eliminándolo, el cambio todavía estará ``allí afuera'', 2.613 +y podría propagarse más tarde. 2.614 + 2.615 +Si ha consignado uno o más cambios \emph{después} del cambio que desea 2.616 +desaparecer, sus opciones son aún más reducidas. Mercurial no provee 2.617 +una forma de ``cabar un hueco'' en la historia, dejando los conjuntos 2.618 +de cambios intactos. 2.619 + 2.620 +%Dejamos de traducir lo que viene a continuación, porque será 2.621 +%modificado por upstream... 2.622 2.623 XXX This needs filling out. The \texttt{hg-replay} script in the 2.624 \texttt{examples} directory works, but doesn't handle merge