1.1 --- a/es/undo.tex	Sun Dec 21 12:03:26 2008 -0500
     1.2 +++ b/es/undo.tex	Sun Jan 18 21:37:11 2009 -0500
     1.3 @@ -8,7 +8,7 @@
     1.4  tiene unas características poderosas que le ayudarán a isolar las
     1.5  fuentes de los problemas, y a dar cuenta de ellas apropiadamente.
     1.6  
     1.7 -\section{Borrar la historia local}
     1.8 +\section{Borrar el historial local}
     1.9  
    1.10  \subsection{La consignación accidental}
    1.11  
    1.12 @@ -51,7 +51,7 @@
    1.13  el conjunto de cambios.  Uso la orden \hgcmd{rollback}, y Mercurial
    1.14  hace desaparecer el último conjunto de cambios.
    1.15  \interaction{rollback.rollback}
    1.16 -El conjunto de cambios ya no está en la historia del repositorio, y el
    1.17 +El conjunto de cambios ya no está en el historial del repositorio, y el
    1.18  directorio de trabajo cree que el fichero \filename{a} ha sido
    1.19  modificado.  La consignación y el roll back dejaron el directorio de
    1.20  trabajo exactamente como estaba antes de la consignación; el conjunto
    1.21 @@ -88,7 +88,7 @@
    1.22  El valor de \hgcmd{rollback} se anula cuando ha publicado sus cambios
    1.23  a otro repositorio.  Un cambio desaparece totalmente al hacer roll back,
    1.24  pero \emph{solamente} en el repositorio en el cual aplica
    1.25 -\hgcmd{rollback}.  Debido a que un roll back elimina la historia,
    1.26 +\hgcmd{rollback}.  Debido a que un roll back elimina el historial,
    1.27  no hay forma de que la desaparición de un cambio se propague entre
    1.28  repositorios.
    1.29  
    1.30 @@ -220,7 +220,7 @@
    1.31  parte de un conjunto de cambios a mano.
    1.32  
    1.33  Antes de leer esta sección, hay algo para tener en cuenta: la orden
    1.34 -\hgcmd{backout} deshace cambios \emph{adicionando} a la historia, sin
    1.35 +\hgcmd{backout} deshace cambios \emph{adicionando} a el historial, sin
    1.36  modificar o borrar.  Es la herramienta correcta si está arreglando
    1.37  fallos, pero no si está tratando de deshacer algún cambio que tiene
    1.38  consecuencias catastróficas.  Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}.
    1.39 @@ -228,7 +228,7 @@
    1.40  \subsection{Retroceder un conjunto de cambios}
    1.41  
    1.42  La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo
    1.43 -un conjunto de cambios de forma automatizada.  Dado que la historia de
    1.44 +un conjunto de cambios de forma automatizada.  Dado que el historial de
    1.45  Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto
    1.46  de cambios que usted desea deshacer.  En cambio, crea un nuevo
    1.47  conjunto de cambios que \emph{reversa} el conjunto de cambios que
    1.48 @@ -257,8 +257,8 @@
    1.49  Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
    1.50  un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
    1.51  ver en la figura~\ref{fig:undo:backout}, que presenta una vista
    1.52 -gráfica de la historia de cambios.  Como puede ver, la historia es
    1.53 -bonita y lineal.
    1.54 +gráfica de el historial de cambios.  Como puede ver, el historial es
    1.55 +bonito y lineal.
    1.56  
    1.57  \begin{figure}[htb]
    1.58    \centering
    1.59 @@ -281,7 +281,7 @@
    1.60  presentes, pero no el segundo.
    1.61  \interaction{backout.non-tip.cat}
    1.62  
    1.63 -Como lo muestra la historia gráfica en la
    1.64 +Como lo muestra el historial gráfico en la
    1.65  figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna
    1.66  \emph{dos} cambios en estas situaciones (los nodos encerrados en una
    1.67  caja son aquellos que Mercurial consigna automaticamente).  Antes de
    1.68 @@ -301,7 +301,7 @@
    1.69  \end{figure}
    1.70  
    1.71  El resultado es que usted termina ``donde estaba'', solamente con un
    1.72 -poco de historia adicional que deshace el efecto de un conjunto de
    1.73 +poco de historial adicional que deshace el efecto de un conjunto de
    1.74  cambios que usted quería evitar.
    1.75  
    1.76  \subsubsection{Use siempre la opción \hgopt{backout}{--merge}}
    1.77 @@ -333,8 +333,8 @@
    1.78  orden \hgcmd{backout} fue muy explícita diciéndolo.
    1.79  \interaction{backout.manual.log}
    1.80  
    1.81 -De nuevo, es más sencillo lo que pasó viendo una gráfica de la
    1.82 -historia de revisiones, en la figura~\ref{fig:undo:backout-manual}.
    1.83 +De nuevo, es más sencillo lo que pasó viendo una gráfica del
    1.84 +historial de revisiones, en la figura~\ref{fig:undo:backout-manual}.
    1.85  Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un
    1.86  cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al
    1.87  repositorio (el cambio que consignó está encerrado en una caja).
    1.88 @@ -355,14 +355,14 @@
    1.89  Reflexionemos acerca de lo que esperamos ver como contenidos de
    1.90  \filename{myfile}.  El primer cambio debería estar presente, porque
    1.91  nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
    1.92 -puesto que es el que retrocedimos.  Dado que la gráfica de la historia
    1.93 +puesto que es el que retrocedimos.  Dado que la gráfica de el historial
    1.94  muestra que el tercer camlio es una cabeza separada, \emph{no}
    1.95  esperamos ver el tercer cambio presente en \filename{myfile}.
    1.96  \interaction{backout.manual.cat}
    1.97  Para que el tercer cambio esté en el fichero, hacemos una fusión usual
    1.98  de las dos cabezas.
    1.99  \interaction{backout.manual.merge}
   1.100 -Después de eso, la historia gráfica de nuestro repositorio luce como
   1.101 +Después de eso, el historial gráfica de nuestro repositorio luce como
   1.102  la figura~\ref{fig:undo:backout-manual-merge}.
   1.103  
   1.104  \begin{figure}[htb]
   1.105 @@ -411,7 +411,7 @@
   1.106  retrocediendo y la punta actual.
   1.107  
   1.108  Si está retrocediendo un conjunto de cambios que está a unas ~100
   1.109 -atrás en su historia del proyecto, las posibilidades de que una orden
   1.110 +atrás en su historial del proyecto, las posibilidades de que una orden
   1.111  \command{patch} sea capaz de ser aplicada a un diff reverso,
   1.112  claramente no son altas, porque los cambios que intervienen podrían
   1.113  ``no coincidir con el contexto'' que \command{patch} usa  para
   1.114 @@ -442,13 +442,13 @@
   1.115  colocarse una bolsa de papel desechable en su cabeza), permítame
   1.116  discutir primero unas aproximaciones que probablemente no funcionen.
   1.117  
   1.118 -Dado que Mercurial trata de forma acumulativa la historia---cada
   1.119 -cambio se coloca encima de todos los cambios que leo
   1.120 -preceden---usualmente usted no puede hacer que unos cambios desastros
   1.121 +Dado que Mercurial trata de forma acumulativa al historial---cada
   1.122 +cambio se coloca encima de todos los cambios que le
   1.123 +preceden---usualmente usted no puede hacer que unos cambios desastrosos
   1.124  desaparezcan. La única excepción es cuando usted ha acabado de
   1.125  consignar un cambio y este no ha sido publicado o jalado en otro
   1.126  repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con
   1.127 -seguridad, Como detallé en la sección~\ref{sec:undo:rollback}.
   1.128 +seguridad, como detallé en la sección~\ref{sec:undo:rollback}.
   1.129  
   1.130  Después de que usted haya publicado un cambio en otro repositorio, usted
   1.131  \emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia
   1.132 @@ -466,7 +466,7 @@
   1.133  
   1.134  Si ha consignado uno o más cambios \emph{después} del cambio que desea
   1.135  desaparecer, sus opciones son aún más reducidas. Mercurial no provee
   1.136 -una forma de ``cabar un hueco'' en la historia, dejando los conjuntos
   1.137 +una forma de ``cabar un hueco'' en el historial, dejando los conjuntos
   1.138  de cambios intactos.
   1.139  
   1.140  %Dejamos de traducir lo que viene a continuación, porque será
   1.141 @@ -561,20 +561,20 @@
   1.142  búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
   1.143  conjunto de cambios culpable.
   1.144  
   1.145 -La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la
   1.146 -historia de revisiones de su proyecto para hacer una búsqueda
   1.147 +La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' del
   1.148 +historial de revisiones de su proyecto para hacer una búsqueda
   1.149  proporcional al \emph{logaritmo} del número de conjunto de cambios a
   1.150 -revisar( el tipo de búsqueda que realiza se llama búsqueda
   1.151 +revisar (el tipo de búsqueda que realiza se llama búsqueda
   1.152  binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
   1.153 -cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La
   1.154 +cambios tomará menos de 3 horas, incluso a diez minutos por prueba (La
   1.155  búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
   1.156  última centena de conjuntos de cambios, tomará a lo sumo una
   1.157 -hora(Apenas unas 7 pruebas).
   1.158 +hora (Apenas unas 7 pruebas).
   1.159  
   1.160  La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
   1.161 -de la historia de revisiones del proyecto con Mercurial, así que no
   1.162 +de el historial de revisiones del proyecto con Mercurial, así que no
   1.163  hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
   1.164 -repositorio.  Puede evitar ramas enteras de historia con un solo
   1.165 +repositorio.  Puede evitar ramas enteras de historial con un solo
   1.166  sondeo.
   1.167  
   1.168  \subsection{Uso de la orden \hgcmd{bisect}}
   1.169 @@ -790,7 +790,7 @@
   1.170  otro fallo puede enmascararlo(como se discutió anteriormente).
   1.171  
   1.172  Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
   1.173 -meses de historia, solamente estaŕa adicionando unas pruebas contadas
   1.174 +meses de historial, solamente estaŕa adicionando unas pruebas contadas
   1.175  para \hgcmd{bisect}, gracias al comportamiento logarítmico.
   1.176  
   1.177  %%% Local Variables: