1.1 --- a/es/undo.tex	Mon Nov 03 08:23:10 2008 -0500
     1.2 +++ b/es/undo.tex	Wed Nov 05 23:04:06 2008 -0500
     1.3 @@ -476,101 +476,106 @@
     1.4  \texttt{examples} directory works, but doesn't handle merge
     1.5  changesets.  Kind of an important omission.
     1.6  
     1.7 -\subsection{Protect yourself from ``escaped'' changes}
     1.8 -
     1.9 -If you've committed some changes to your local repository and they've
    1.10 -been pushed or pulled somewhere else, this isn't necessarily a
    1.11 -disaster.  You can protect yourself ahead of time against some classes
    1.12 -of bad changeset.  This is particularly easy if your team usually
    1.13 -pulls changes from a central repository.
    1.14 -
    1.15 -By configuring some hooks on that repository to validate incoming
    1.16 -changesets (see chapter~\ref{chap:hook}), you can automatically
    1.17 -prevent some kinds of bad changeset from being pushed to the central
    1.18 -repository at all.  With such a configuration in place, some kinds of
    1.19 -bad changeset will naturally tend to ``die out'' because they can't
    1.20 -propagate into the central repository.  Better yet, this happens
    1.21 -without any need for explicit intervention.
    1.22 -
    1.23 -For instance, an incoming change hook that verifies that a changeset
    1.24 -will actually compile can prevent people from inadvertantly ``breaking
    1.25 -the build''.
    1.26 -
    1.27 -\section{Finding the source of a bug}
    1.28 +\subsection{Cómo protegerse de cambios que han ``escapado''}
    1.29 +
    1.30 +Si ha consignado cambios a su repositorio local y estos han sido
    1.31 +publicados o jalados en cualquier otro sitio, no es necesariamente un
    1.32 +desastre. Puede protegerse de antemano de ciertas clases de conjuntos
    1.33 +de cambios malos. Esto es particularmente sencillo si su equipo de
    1.34 +trabajo jala cambios de un repositorio central.
    1.35 +
    1.36 +Al configura algunos ganchos en el repositorio central para validar
    1.37 +conjuntos de cambios(ver capítulo~\ref{chap:hook}), puede prevenir la
    1.38 +publicación automáticamente de cierta clase de cambios malos.  Con tal
    1.39 +configuración, cierta clase de conjuntos de cambios malos tenderán
    1.40 +naturalmente a``morir'' debido a que no pueden propagarse al
    1.41 +repositorio central.  Esto sucederá sin necesidad de intervención
    1.42 +explícita.
    1.43 +
    1.44 +Por ejemplo, un gancho de cambios de entrada que verifique que un
    1.45 +conjunto de cambios compila, puede prevenir que la gente ``rompa 
    1.46 +la compilación'' inadvertidamente.
    1.47 +
    1.48 +\section{Al encuentro de la fuente de un fallo}
    1.49  \label{sec:undo:bisect}
    1.50  
    1.51 -While it's all very well to be able to back out a changeset that
    1.52 -introduced a bug, this requires that you know which changeset to back
    1.53 -out.  Mercurial provides an invaluable command, called
    1.54 -\hgcmd{bisect}, that helps you to automate this process and accomplish
    1.55 -it very efficiently.
    1.56 -
    1.57 -The idea behind the \hgcmd{bisect} command is that a changeset has
    1.58 -introduced some change of behaviour that you can identify with a
    1.59 -simple binary test.  You don't know which piece of code introduced the
    1.60 -change, but you know how to test for the presence of the bug.  The
    1.61 -\hgcmd{bisect} command uses your test to direct its search for the
    1.62 -changeset that introduced the code that caused the bug.
    1.63 -
    1.64 -Here are a few scenarios to help you understand how you might apply
    1.65 -this command.
    1.66 +Aunque es muy bueno poder retroceder el conjunto de cambios que
    1.67 +originó un fallo, se requiere que usted sepa cual conjunto de cambios
    1.68 +retroceder.  Mercurial brinda una orden invaluable, llamada
    1.69 +\hgcmd{bisect}, que ayuda a automatizar este proceso y a alcanzarlo
    1.70 +muy eficientemente.
    1.71 +
    1.72 +La idea tras la orden \hgcmd{bisect} es que el conjunto de cambios que
    1.73 +ha introducido un cambio de comportamiento pueda identificarse con una
    1.74 +prueba binaria sencilla. No tiene que saber qué pieza de código
    1.75 +introdujo el cambio, pero si requiere que sepa cómo probar la
    1.76 +existencia de un fallo. La orden \hgcmd{bisect} usa su prueba para
    1.77 +dirigir su búsqueda del conjunto de cambios que introdujo el código
    1.78 +causante del fallo.
    1.79 +
    1.80 +A continuación un conjunto de escenarios que puede ayudarle a entender
    1.81 +cómo puede aplicar esta orden.
    1.82  \begin{itemize}
    1.83 -\item The most recent version of your software has a bug that you
    1.84 -  remember wasn't present a few weeks ago, but you don't know when it
    1.85 -  was introduced.  Here, your binary test checks for the presence of
    1.86 -  that bug.
    1.87 -\item You fixed a bug in a rush, and now it's time to close the entry
    1.88 -  in your team's bug database.  The bug database requires a changeset
    1.89 -  ID when you close an entry, but you don't remember which changeset
    1.90 -  you fixed the bug in.  Once again, your binary test checks for the
    1.91 -  presence of the bug.
    1.92 -\item Your software works correctly, but runs~15\% slower than the
    1.93 -  last time you measured it.  You want to know which changeset
    1.94 -  introduced the performance regression.  In this case, your binary
    1.95 -  test measures the performance of your software, to see whether it's
    1.96 -  ``fast'' or ``slow''.
    1.97 -\item The sizes of the components of your project that you ship
    1.98 -  exploded recently, and you suspect that something changed in the way
    1.99 -  you build your project.
   1.100 +\item La versión más reciente de su programa tiene un fallo que usted
   1.101 +  recuerda no estaba hace unas semanas, pero no sabe cuándo fue
   1.102 +  introducido. En este caso, su prueba binaria busca la presencia de
   1.103 +  tal fallo.
   1.104 +\item Usted arregló un fallo en un apurto, y es hora de dar por
   1.105 +  cerrado el caso en la base de datos de fallos de su equipo de
   1.106 +  trabajo.   La base de datos de fallos requiere el ID del conjunto de
   1.107 +  cambios que permita dar por cerrado el caso, pero usted no recuerda
   1.108 +  qué conjunto de cambios arregló tal fallo.  De nuevo la prueba
   1.109 +  binaria revisa la presencia del fallo.
   1.110 +\item Su programa funciona correctamente, pero  core ~15\% más lento
   1.111 +  que la última vez que lo midió. Usted desea saber qué conjunto de
   1.112 +  cambios introdujo esta disminución de desempeño.  En este caso su
   1.113 +  prueba binaria mide el desempeño de su programa, para ver dónde es
   1.114 +  ``rápido'' y dónde es ``lento''.
   1.115 +\item Los tamaños de los componentes del proyecto que usted lleva se
   1.116 +  expandieron recientemente, y sospecha que algo cambio en la forma en
   1.117 +  que se construye su proyecto.
   1.118  \end{itemize}
   1.119  
   1.120 -From these examples, it should be clear that the \hgcmd{bisect}
   1.121 -command is not useful only for finding the sources of bugs.  You can
   1.122 -use it to find any ``emergent property'' of a repository (anything
   1.123 -that you can't find from a simple text search of the files in the
   1.124 -tree) for which you can write a binary test.
   1.125 -
   1.126 -We'll introduce a little bit of terminology here, just to make it
   1.127 -clear which parts of the search process are your responsibility, and
   1.128 -which are Mercurial's.  A \emph{test} is something that \emph{you} run
   1.129 -when \hgcmd{bisect} chooses a changeset.  A \emph{probe} is what
   1.130 -\hgcmd{bisect} runs to tell whether a revision is good.  Finally,
   1.131 -we'll use the word ``bisect'', as both a noun and a verb, to stand in
   1.132 -for the phrase ``search using the \hgcmd{bisect} command.
   1.133 -
   1.134 -One simple way to automate the searching process would be simply to
   1.135 -probe every changeset.  However, this scales poorly.  If it took ten
   1.136 -minutes to test a single changeset, and you had 10,000 changesets in
   1.137 -your repository, the exhaustive approach would take on average~35
   1.138 -\emph{days} to find the changeset that introduced a bug.  Even if you
   1.139 -knew that the bug was introduced by one of the last 500 changesets,
   1.140 -and limited your search to those, you'd still be looking at over 40
   1.141 -hours to find the changeset that introduced your bug.
   1.142 -
   1.143 -What the \hgcmd{bisect} command does is use its knowledge of the
   1.144 -``shape'' of your project's revision history to perform a search in
   1.145 -time proportional to the \emph{logarithm} of the number of changesets
   1.146 -to check (the kind of search it performs is called a dichotomic
   1.147 -search).  With this approach, searching through 10,000 changesets will
   1.148 -take less than three hours, even at ten minutes per test (the search
   1.149 -will require about 14 tests).  Limit your search to the last hundred
   1.150 -changesets, and it will take only about an hour (roughly seven tests).
   1.151 -
   1.152 -The \hgcmd{bisect} command is aware of the ``branchy'' nature of a
   1.153 -Mercurial project's revision history, so it has no problems dealing
   1.154 -with branches, merges, or multiple heads in a repoository.  It can
   1.155 -prune entire branches of history with a single probe, which is how it
   1.156 -operates so efficiently.
   1.157 +Para estos ejemplos debería ser claro que la orden \hgcmd{bisect}
   1.158 +es útil no solamente para encontrar la fuente de los fallos. Puede
   1.159 +usarla para encontrar cualquier ``propiedad emergente'' de un
   1.160 +repositorio(Cualquier cosa que usted no pueda encontrar con una
   1.161 +búsqueda de texto sencilla sobre los archivos en el árbol) para la
   1.162 +cual pueda escribir una prueba binaria.
   1.163 +
   1.164 +A continuación introduciremos algo terminología, para aclarar qué
   1.165 +partes del proceso de búsqueda son su responsabilidad y cuáles de
   1.166 +Mercurial.  Una \emph{prueba} es algo que \emph{usted} ejecuta cuando
   1.167 +\hgcmd{bisect} elige un conjunto de cambios.  Un \emph{sondeo} es lo que
   1.168 +\hgcmd{bisect} ejecuta para decidir si una revisión es buena.  Finalmente,
   1.169 +usaremos la palabra ``biseccionar', en frases como ``buscar con la
   1.170 +orden \hgcmd{bisect}''.
   1.171 +
   1.172 +Una forma sencilla de automatizar el proceso de búsqueda sería probar
   1.173 +cada conjunto de cambios.  Lo cual escala muy poco. Si le tomó diez
   1.174 +minutos hacer pruebas sobre un conjunto de cambios y tiene 10.000
   1.175 +conjuntos de cambios en su repositorio, esta aproximación exhaustiva
   1.176 +tomaría en promedio~35 \emph{días} para encontrar el conjunto de
   1.177 +cambios que introdujo el fallo. Incluso si supiera que el fallo se
   1.178 +introdujo en un de los últimos 500 conjuntos de cambios y limitara la
   1.179 +búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
   1.180 +conjunto de cambios culpable.
   1.181 +
   1.182 +La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la
   1.183 +historia de revisiones de su proyecto para hacer una búsqueda
   1.184 +proporcional al \emph{logaritmo} del número de conjunto de cambios a
   1.185 +revisar( el tipo de búsqueda que realiza se llama búsqueda
   1.186 +binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
   1.187 +cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La
   1.188 +búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
   1.189 +última centena de conjuntos de cambios, tomará a lo sumo una
   1.190 +hora(Apenas unas 7 pruebas).
   1.191 +
   1.192 +La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
   1.193 +de la historia de revisiones del proyecto con Mercurial, así que no
   1.194 +hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
   1.195 +repositorio.  Puede evitar ramas enteras de historia con un solo
   1.196 +sondeo.
   1.197  
   1.198  \subsection{Using the \hgcmd{bisect} command}
   1.199