1.1 --- a/es/Leame.1st	Thu Nov 06 23:09:47 2008 -0500
     1.2 +++ b/es/Leame.1st	Fri Nov 07 21:33:22 2008 -0500
     1.3 @@ -99,7 +99,7 @@
     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   ||     85%    || 26/10/2008 ||             ||
     1.8 +|| undo.tex        || Igor Támara   ||    100%    || 26/10/2008 ||  07/11/2008 ||
     1.9  || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
    1.10  || concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
    1.11  

     2.1 --- a/es/undo.tex	Thu Nov 06 23:09:47 2008 -0500
     2.2 +++ b/es/undo.tex	Fri Nov 07 21:33:22 2008 -0500
     2.3 @@ -686,104 +686,112 @@
     2.4  no aplique \hgcmdargs{bisect}{reset}.
     2.5  \interaction{bisect.search.reset}
     2.6  
     2.7 -\section{Tips for finding bugs effectively}
     2.8 -
     2.9 -\subsection{Give consistent input}
    2.10 -
    2.11 -The \hgcmd{bisect} command requires that you correctly report the
    2.12 -result of every test you perform.  If you tell it that a test failed
    2.13 -when it really succeeded, it \emph{might} be able to detect the
    2.14 -inconsistency.  If it can identify an inconsistency in your reports,
    2.15 -it will tell you that a particular changeset is both good and bad.
    2.16 -However, it can't do this perfectly; it's about as likely to report
    2.17 -the wrong changeset as the source of the bug.
    2.18 -
    2.19 -\subsection{Automate as much as possible}
    2.20 -
    2.21 -When I started using the \hgcmd{bisect} command, I tried a few times
    2.22 -to run my tests by hand, on the command line.  This is an approach
    2.23 -that I, at least, am not suited to.  After a few tries, I found that I
    2.24 -was making enough mistakes that I was having to restart my searches
    2.25 -several times before finally getting correct results.
    2.26 -
    2.27 -My initial problems with driving the \hgcmd{bisect} command by hand
    2.28 -occurred even with simple searches on small repositories; if the
    2.29 -problem you're looking for is more subtle, or the number of tests that
    2.30 -\hgcmd{bisect} must perform increases, the likelihood of operator
    2.31 -error ruining the search is much higher.  Once I started automating my
    2.32 -tests, I had much better results.
    2.33 -
    2.34 -The key to automated testing is twofold:
    2.35 +\section{Consejos para encontrar fallos efectivamente}
    2.36 +
    2.37 +\subsection{Dar una entrada consistente}
    2.38 +
    2.39 +La orden \hgcmd{bisect} requiere que usted ofrezca un reporte correcto
    2.40 +del resultado de cada prueba que aplique.  Si usted le dice que una
    2.41 +prueba falla cuando en realidad era acertada, \emph{podría} detectar
    2.42 +la inconsistencia. Si puede identificar una inconsistencia en sus
    2.43 +reportes, le dirá que un conjunto de cambios particular es a la vez
    2.44 +bueno y malo.  Aunque puede no hacerlo; estaría tratando de reportar
    2.45 +un conjunto de cambios como el responsable de un fallo aunque no lo
    2.46 +sea.
    2.47 +
    2.48 +\subsection{Automatizar tanto como se pueda}
    2.49 +
    2.50 +Cuando comencé a usar la orden \hgcmd{bisect}, intenté ejecutar
    2.51 +algunas veces las pruebas a mano desde la línea de comandos. Es una
    2.52 +aproximación a la cual no esta acostumbrado. Después de algunos
    2.53 +intentos, me di cuenta que estaba cometiendo tantas equivocaciones que
    2.54 +tenía que comenzar de nuevo con mis búsquedas varias veces antes de
    2.55 +llegar a los resultados deseados.
    2.56 +
    2.57 +Mi problema inicial al dirigir a la orden \hgcmd{bisect} manualmente
    2.58 +ocurrieron incluso con búsquedas en repositorios pequeños; si el
    2.59 +problema que está buscando es más sutil, o el número de pruebas que
    2.60 +\hgcmd{bisect} debe aplicar, la posibilidad de errar es mucho más
    2.61 +alta. Una vez que comencé a automatizar mis pruebas, obtuve mejores
    2.62 +resultados.
    2.63 +
    2.64 +La clave para las pruebas automatizadas se puede resumir en:
    2.65  \begin{itemize}
    2.66 -\item always test for the same symptom, and
    2.67 -\item always feed consistent input to the \hgcmd{bisect} command.
    2.68 +\item pruebe siempre buscando el mismo síntoma y
    2.69 +\item ofrezca siempre datos consistentes a la orden \hgcmd{bisect}.
    2.70  \end{itemize}
    2.71 -In my tutorial example above, the \command{grep} command tests for the
    2.72 -symptom, and the \texttt{if} statement takes the result of this check
    2.73 -and ensures that we always feed the same input to the \hgcmd{bisect}
    2.74 -command.  The \texttt{mytest} function marries these together in a
    2.75 -reproducible way, so that every test is uniform and consistent.
    2.76 -
    2.77 -\subsection{Check your results}
    2.78 -
    2.79 -Because the output of a \hgcmd{bisect} search is only as good as the
    2.80 -input you give it, don't take the changeset it reports as the
    2.81 -absolute truth.  A simple way to cross-check its report is to manually
    2.82 -run your test at each of the following changesets:
    2.83 +En mi tutorial de ejemplo anterior, la orden \command{grep} busca el
    2.84 +síntoma, y la construcción \texttt{if} toma el resultado de esta
    2.85 +prueba y verifica que siempre alimentamos con los mismos datos a la
    2.86 +orden \hgcmd{bisect}. La función \texttt{mytest} los une de una forma
    2.87 +reproducible, logrando que cada prueba sea uniforme y consistente.
    2.88 +
    2.89 +\subsection{Verificar los resultados}
    2.90 +
    2.91 +Dado que la salida de la búsqueda de \hgcmd{bisect} es tan buena como
    2.92 +los datos ofrecidos por usted, no confíe en esto como si fuera la
    2.93 +verdad absoluta. Una forma sencilla de asegurarse es ejecutar
    2.94 +manualmente su prueba a cada uno de los siguientes conjuntos de
    2.95 +cambios:
    2.96  \begin{itemize}
    2.97 -\item The changeset that it reports as the first bad revision.  Your
    2.98 -  test should still report this as bad.
    2.99 -\item The parent of that changeset (either parent, if it's a merge).
   2.100 -  Your test should report this changeset as good.
   2.101 -\item A child of that changeset.  Your test should report this
   2.102 -  changeset as bad.
   2.103 +\item El conjunto de cambios que se reportó como la primera versión
   2.104 +  erronea. Su prueba debería dar un reporte de fallo.
   2.105 +\item El conjunto de cambios padre (cada padre, si es una fusión).
   2.106 +  Su prueba debería reportar este(os) conjunto(s) de cambios como
   2.107 +  bueno(s).
   2.108 +\item Un hijo del conjunto de cambios. Su prueba debería reportar al
   2.109 +  conjunto de cambios hijo como malo.
   2.110  \end{itemize}
   2.111  
   2.112 -\subsection{Beware interference between bugs}
   2.113 -
   2.114 -It's possible that your search for one bug could be disrupted by the
   2.115 -presence of another.  For example, let's say your software crashes at
   2.116 -revision 100, and worked correctly at revision 50.  Unknown to you,
   2.117 -someone else introduced a different crashing bug at revision 60, and
   2.118 -fixed it at revision 80.  This could distort your results in one of
   2.119 -several ways.
   2.120 -
   2.121 -It is possible that this other bug completely ``masks'' yours, which
   2.122 -is to say that it occurs before your bug has a chance to manifest
   2.123 -itself.  If you can't avoid that other bug (for example, it prevents
   2.124 -your project from building), and so can't tell whether your bug is
   2.125 -present in a particular changeset, the \hgcmd{bisect} command cannot
   2.126 -help you directly.  Instead, you can mark a changeset as untested by
   2.127 -running \hgcmdargs{bisect}{--skip}.
   2.128 -
   2.129 -A different problem could arise if your test for a bug's presence is
   2.130 -not specific enough.  If you check for ``my program crashes'', then
   2.131 -both your crashing bug and an unrelated crashing bug that masks it
   2.132 -will look like the same thing, and mislead \hgcmd{bisect}.
   2.133 -
   2.134 -Another useful situation in which to use \hgcmdargs{bisect}{--skip} is
   2.135 -if you can't test a revision because your project was in a broken and
   2.136 -hence untestable state at that revision, perhaps because someone
   2.137 -checked in a change that prevented the project from building.
   2.138 -
   2.139 -\subsection{Bracket your search lazily}
   2.140 -
   2.141 -Choosing the first ``good'' and ``bad'' changesets that will mark the
   2.142 -end points of your search is often easy, but it bears a little
   2.143 -discussion nevertheless.  From the perspective of \hgcmd{bisect}, the
   2.144 -``newest'' changeset is conventionally ``bad'', and the older
   2.145 -changeset is ``good''.
   2.146 -
   2.147 -If you're having trouble remembering when a suitable ``good'' change
   2.148 -was, so that you can tell \hgcmd{bisect}, you could do worse than
   2.149 -testing changesets at random.  Just remember to eliminate contenders
   2.150 -that can't possibly exhibit the bug (perhaps because the feature with
   2.151 -the bug isn't present yet) and those where another problem masks the
   2.152 -bug (as I discussed above).
   2.153 -
   2.154 -Even if you end up ``early'' by thousands of changesets or months of
   2.155 -history, you will only add a handful of tests to the total number that
   2.156 -\hgcmd{bisect} must perform, thanks to its logarithmic behaviour.
   2.157 +\subsection{Tener en cuenta la interferencia entre fallos}
   2.158 +
   2.159 +Es posible que su búsqueda de un fallo pueda viciarse por la presencia
   2.160 +de otro. Por ejemplo, digamos que su programa se revienta en la
   2.161 +revisión 100, y que funcionó correctamente en la revisión 50.  Sin su
   2.162 +conocimiento, alguien introdujo un fallo con consecuencias grandes en
   2.163 +la revisión 60, y lo arregló en la revisión 80. Sus resultados
   2.164 +estarían distorcionados de una o muchas formas.
   2.165 +
   2.166 +Es posible que este fallo ``enmascare'' completamente al suyo, y que
   2.167 +podría haberse revelado antes de que su propio fallo haya tenido
   2.168 +oportunidad de manifestarse. Si no puede saltar el otro fallo(por
   2.169 +ejemplo, este evita que su proyecto se arme o compile), y de esta
   2.170 +forma no se pueda revisar si su fallo esté presente en un conjunto
   2.171 +particular de cambios, la orden \hgcmd{bisect} no podrá ayudarle
   2.172 +directamente. En cambio, puede marcar este conjunto de cambios como
   2.173 +al ejecutar \hgcmdargs{bisect}{--skip}.
   2.174 +
   2.175 +Un problema distinto podría surgir si su prueba de la presencia de un
   2.176 +fallo no es suficientemente específica. Si usted busca ``mi programa
   2.177 +se revienta'', entonces tanto su fallo como el otro fallo sin relación
   2.178 +que terminan presentando síntomas distintos, podría terminar
   2.179 +confundiendo a \hgcmd{bisect}.
   2.180 +
   2.181 +Otra situación en la cual sería de mucha utilidad emplear a
   2.182 +\hgcmdargs{bisect}{--skip} surge cuando usted no puede probar una
   2.183 +revisión porque su proyecto estaba en una situación de rompimiento y
   2.184 +por lo tanto en un estado en el cual era imposible hacer la prueba en
   2.185 +esa revisión, tal vez porque alguien consignó un cambio que hacía
   2.186 +imposible la construcción del proyecto.
   2.187 +
   2.188 +\subsection{Acotar la búsqueda perezosamente}
   2.189 +
   2.190 +Elegir los primeros ``buenos'' y ``malos'' conjuntos de cambios que
   2.191 +marcarán los límites de su búsqueda en general es sencillo, pero vale
   2.192 +la pena discutirlo.  Desde la perspectiva de \hgcmd{bisect}, el
   2.193 +conjunto de cambios ``más nuevo'' por convención es el ``malo'', y el
   2.194 +otro conjunto de cambios es el ``bueno''.
   2.195 +
   2.196 +Si no recuerda cuál podría ser el cambio ``bueno'', para informar a
   2.197 +\hgcmd{bisect}, podría hacer pruebas aleatorias en el peor de los
   2.198 +casos. Pero recuerde eliminar aquellos conjuntos de cambios que
   2.199 +podrían no exhibir el fallo(tal vez porque la característica donde se
   2.200 +presenta el fallo todavía no está presente) y aquellos en los cuales
   2.201 +otro fallo puede enmascararlo(como se discutió anteriormente).
   2.202 +
   2.203 +Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
   2.204 +meses de historia, solamente estaŕa adicionando unas pruebas contadas
   2.205 +para \hgcmd{bisect}, gracias al comportamiento logarítmico.
   2.206  
   2.207  %%% Local Variables: 
   2.208  %%% mode: latex