hgbook
diff es/undo.tex @ 389:b7d4d66c3ae5
Aiiiiiee section translated
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Mon Nov 03 08:23:10 2008 -0500 (2008-11-03) |
parents | 9fdb45b994d4 |
children | b8d9066abcea |
line diff
1.1 --- a/es/undo.tex Sun Nov 02 21:00:40 2008 -0500 1.2 +++ b/es/undo.tex Mon Nov 03 08:23:10 2008 -0500 1.3 @@ -421,51 +421,56 @@ 1.4 y directorios renombrados, cambios de permisos, y modificaciones a 1.5 archivos binarios, nada de lo cual la orden \command{patch} puede manejar. 1.6 1.7 -\section{Changes that should never have been} 1.8 +\section{Cambios que nunca debieron ocurrir} 1.9 \label{sec:undo:aaaiiieee} 1.10 1.11 -Most of the time, the \hgcmd{backout} command is exactly what you need 1.12 -if you want to undo the effects of a change. It leaves a permanent 1.13 -record of exactly what you did, both when committing the original 1.14 -changeset and when you cleaned up after it. 1.15 - 1.16 -On rare occasions, though, you may find that you've committed a change 1.17 -that really should not be present in the repository at all. For 1.18 -example, it would be very unusual, and usually considered a mistake, 1.19 -to commit a software project's object files as well as its source 1.20 -files. Object files have almost no intrinsic value, and they're 1.21 -\emph{big}, so they increase the size of the repository and the amount 1.22 -of time it takes to clone or pull changes. 1.23 - 1.24 -Before I discuss the options that you have if you commit a ``brown 1.25 -paper bag'' change (the kind that's so bad that you want to pull a 1.26 -brown paper bag over your head), let me first discuss some approaches 1.27 -that probably won't work. 1.28 - 1.29 -Since Mercurial treats history as accumulative---every change builds 1.30 -on top of all changes that preceded it---you generally can't just make 1.31 -disastrous changes disappear. The one exception is when you've just 1.32 -committed a change, and it hasn't been pushed or pulled into another 1.33 -repository. That's when you can safely use the \hgcmd{rollback} 1.34 -command, as I detailed in section~\ref{sec:undo:rollback}. 1.35 - 1.36 -After you've pushed a bad change to another repository, you 1.37 -\emph{could} still use \hgcmd{rollback} to make your local copy of the 1.38 -change disappear, but it won't have the consequences you want. The 1.39 -change will still be present in the remote repository, so it will 1.40 -reappear in your local repository the next time you pull. 1.41 - 1.42 -If a situation like this arises, and you know which repositories your 1.43 -bad change has propagated into, you can \emph{try} to get rid of the 1.44 -changeefrom \emph{every} one of those repositories. This is, of 1.45 -course, not a satisfactory solution: if you miss even a single 1.46 -repository while you're expunging, the change is still ``in the 1.47 -wild'', and could propagate further. 1.48 - 1.49 -If you've committed one or more changes \emph{after} the change that 1.50 -you'd like to see disappear, your options are further reduced. 1.51 -Mercurial doesn't provide a way to ``punch a hole'' in history, 1.52 -leaving changesets intact. 1.53 +En la mayoría de los casos, la orden \hgcmd{backout} es exactamente lo 1.54 +que necesita para deshacer los efectos de un cambio. Deja un registro 1.55 +permanente y exacto de lo que usted hizo, cuando se consignó el 1.56 +conjunto de cambios original y cuando se hizo la limpieza. 1.57 + 1.58 +En ocasiones particulares, puede haber consignado un cambio que no 1.59 +debería estar de ninguna forma en el repositorio. Por ejemplo, sería 1.60 +muy inusual, y considerado como una equivocación, consignar los 1.61 +archivos objeto junto con el código fuente. los ficheros objeto no 1.62 +tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el 1.63 +tamaño del repositorio y la cantidad de tiempo que se emplea al clonar 1.64 +o jalar cambios. 1.65 + 1.66 +Antes de discutir las opciones que tiene si consignó cambio del tipo 1.67 +``bolsa de papel deschable'' (el tipo que es tan malo que le gustaría 1.68 +colocarse una bolsa de papel desechable en su cabeza), permítame 1.69 +discutir primero unas aproximaciones que probablemente no funcionen. 1.70 + 1.71 +Dado que Mercurial trata de forma acumulativa la historia---cada 1.72 +cambio se coloca encima de todos los cambios que leo 1.73 +preceden---usualmente usted no puede hacer que unos cambios desastros 1.74 +desaparezcan. La única excepción es cuando usted ha acabado de 1.75 +consignar un cambio y este no ha sido publicado o jalado en otro 1.76 +repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con 1.77 +seguridad, Como detallé en la sección~\ref{sec:undo:rollback}. 1.78 + 1.79 +Después de que usted haya publicado un cambio en otro repositorio, usted 1.80 +\emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia 1.81 +local desaparezca el cambio, pero no tendrá las consecuencias que 1.82 +desea. El cambio estará presente en un repositorio remoto, y 1.83 +reaparecerá en su repositorio local la próxima vez que jale 1.84 + 1.85 +Si una situación como esta se presenta, y usted sabe en qué 1.86 +repositorios su mal cambio se ha propagado, puede \emph{intentar} 1.87 +deshacerse del conjunto de cambios de \emph{todos} los repositorios en 1.88 +los que se pueda encontrar. Esta por supuesto, no es una solución 1.89 +satisfactoria: si usted deja de hacerlo en un solo repositorio, 1.90 +mientras esté eliminándolo, el cambio todavía estará ``allí afuera'', 1.91 +y podría propagarse más tarde. 1.92 + 1.93 +Si ha consignado uno o más cambios \emph{después} del cambio que desea 1.94 +desaparecer, sus opciones son aún más reducidas. Mercurial no provee 1.95 +una forma de ``cabar un hueco'' en la historia, dejando los conjuntos 1.96 +de cambios intactos. 1.97 + 1.98 +%Dejamos de traducir lo que viene a continuación, porque será 1.99 +%modificado por upstream... 1.100 1.101 XXX This needs filling out. The \texttt{hg-replay} script in the 1.102 \texttt{examples} directory works, but doesn't handle merge