1.1 --- a/es/undo.tex	Thu Nov 06 23:09:47 2008 -0500
     1.2 +++ b/es/undo.tex	Fri Dec 05 22:09:05 2008 -0500
     1.3 @@ -686,104 +686,112 @@
     1.4  no aplique \hgcmdargs{bisect}{reset}.
     1.5  \interaction{bisect.search.reset}
     1.6  
     1.7 -\section{Tips for finding bugs effectively}
     1.8 -
     1.9 -\subsection{Give consistent input}
    1.10 -
    1.11 -The \hgcmd{bisect} command requires that you correctly report the
    1.12 -result of every test you perform.  If you tell it that a test failed
    1.13 -when it really succeeded, it \emph{might} be able to detect the
    1.14 -inconsistency.  If it can identify an inconsistency in your reports,
    1.15 -it will tell you that a particular changeset is both good and bad.
    1.16 -However, it can't do this perfectly; it's about as likely to report
    1.17 -the wrong changeset as the source of the bug.
    1.18 -
    1.19 -\subsection{Automate as much as possible}
    1.20 -
    1.21 -When I started using the \hgcmd{bisect} command, I tried a few times
    1.22 -to run my tests by hand, on the command line.  This is an approach
    1.23 -that I, at least, am not suited to.  After a few tries, I found that I
    1.24 -was making enough mistakes that I was having to restart my searches
    1.25 -several times before finally getting correct results.
    1.26 -
    1.27 -My initial problems with driving the \hgcmd{bisect} command by hand
    1.28 -occurred even with simple searches on small repositories; if the
    1.29 -problem you're looking for is more subtle, or the number of tests that
    1.30 -\hgcmd{bisect} must perform increases, the likelihood of operator
    1.31 -error ruining the search is much higher.  Once I started automating my
    1.32 -tests, I had much better results.
    1.33 -
    1.34 -The key to automated testing is twofold:
    1.35 +\section{Consejos para encontrar fallos efectivamente}
    1.36 +
    1.37 +\subsection{Dar una entrada consistente}
    1.38 +
    1.39 +La orden \hgcmd{bisect} requiere que usted ofrezca un reporte correcto
    1.40 +del resultado de cada prueba que aplique.  Si usted le dice que una
    1.41 +prueba falla cuando en realidad era acertada, \emph{podría} detectar
    1.42 +la inconsistencia. Si puede identificar una inconsistencia en sus
    1.43 +reportes, le dirá que un conjunto de cambios particular es a la vez
    1.44 +bueno y malo.  Aunque puede no hacerlo; estaría tratando de reportar
    1.45 +un conjunto de cambios como el responsable de un fallo aunque no lo
    1.46 +sea.
    1.47 +
    1.48 +\subsection{Automatizar tanto como se pueda}
    1.49 +
    1.50 +Cuando comencé a usar la orden \hgcmd{bisect}, intenté ejecutar
    1.51 +algunas veces las pruebas a mano desde la línea de comandos. Es una
    1.52 +aproximación a la cual no esta acostumbrado. Después de algunos
    1.53 +intentos, me di cuenta que estaba cometiendo tantas equivocaciones que
    1.54 +tenía que comenzar de nuevo con mis búsquedas varias veces antes de
    1.55 +llegar a los resultados deseados.
    1.56 +
    1.57 +Mi problema inicial al dirigir a la orden \hgcmd{bisect} manualmente
    1.58 +ocurrieron incluso con búsquedas en repositorios pequeños; si el
    1.59 +problema que está buscando es más sutil, o el número de pruebas que
    1.60 +\hgcmd{bisect} debe aplicar, la posibilidad de errar es mucho más
    1.61 +alta. Una vez que comencé a automatizar mis pruebas, obtuve mejores
    1.62 +resultados.
    1.63 +
    1.64 +La clave para las pruebas automatizadas se puede resumir en:
    1.65  \begin{itemize}
    1.66 -\item always test for the same symptom, and
    1.67 -\item always feed consistent input to the \hgcmd{bisect} command.
    1.68 +\item pruebe siempre buscando el mismo síntoma y
    1.69 +\item ofrezca siempre datos consistentes a la orden \hgcmd{bisect}.
    1.70  \end{itemize}
    1.71 -In my tutorial example above, the \command{grep} command tests for the
    1.72 -symptom, and the \texttt{if} statement takes the result of this check
    1.73 -and ensures that we always feed the same input to the \hgcmd{bisect}
    1.74 -command.  The \texttt{mytest} function marries these together in a
    1.75 -reproducible way, so that every test is uniform and consistent.
    1.76 -
    1.77 -\subsection{Check your results}
    1.78 -
    1.79 -Because the output of a \hgcmd{bisect} search is only as good as the
    1.80 -input you give it, don't take the changeset it reports as the
    1.81 -absolute truth.  A simple way to cross-check its report is to manually
    1.82 -run your test at each of the following changesets:
    1.83 +En mi tutorial de ejemplo anterior, la orden \command{grep} busca el
    1.84 +síntoma, y la construcción \texttt{if} toma el resultado de esta
    1.85 +prueba y verifica que siempre alimentamos con los mismos datos a la
    1.86 +orden \hgcmd{bisect}. La función \texttt{mytest} los une de una forma
    1.87 +reproducible, logrando que cada prueba sea uniforme y consistente.
    1.88 +
    1.89 +\subsection{Verificar los resultados}
    1.90 +
    1.91 +Dado que la salida de la búsqueda de \hgcmd{bisect} es tan buena como
    1.92 +los datos ofrecidos por usted, no confíe en esto como si fuera la
    1.93 +verdad absoluta. Una forma sencilla de asegurarse es ejecutar
    1.94 +manualmente su prueba a cada uno de los siguientes conjuntos de
    1.95 +cambios:
    1.96  \begin{itemize}
    1.97 -\item The changeset that it reports as the first bad revision.  Your
    1.98 -  test should still report this as bad.
    1.99 -\item The parent of that changeset (either parent, if it's a merge).
   1.100 -  Your test should report this changeset as good.
   1.101 -\item A child of that changeset.  Your test should report this
   1.102 -  changeset as bad.
   1.103 +\item El conjunto de cambios que se reportó como la primera versión
   1.104 +  erronea. Su prueba debería dar un reporte de fallo.
   1.105 +\item El conjunto de cambios padre (cada padre, si es una fusión).
   1.106 +  Su prueba debería reportar este(os) conjunto(s) de cambios como
   1.107 +  bueno(s).
   1.108 +\item Un hijo del conjunto de cambios. Su prueba debería reportar al
   1.109 +  conjunto de cambios hijo como malo.
   1.110  \end{itemize}
   1.111  
   1.112 -\subsection{Beware interference between bugs}
   1.113 -
   1.114 -It's possible that your search for one bug could be disrupted by the
   1.115 -presence of another.  For example, let's say your software crashes at
   1.116 -revision 100, and worked correctly at revision 50.  Unknown to you,
   1.117 -someone else introduced a different crashing bug at revision 60, and
   1.118 -fixed it at revision 80.  This could distort your results in one of
   1.119 -several ways.
   1.120 -
   1.121 -It is possible that this other bug completely ``masks'' yours, which
   1.122 -is to say that it occurs before your bug has a chance to manifest
   1.123 -itself.  If you can't avoid that other bug (for example, it prevents
   1.124 -your project from building), and so can't tell whether your bug is
   1.125 -present in a particular changeset, the \hgcmd{bisect} command cannot
   1.126 -help you directly.  Instead, you can mark a changeset as untested by
   1.127 -running \hgcmdargs{bisect}{--skip}.
   1.128 -
   1.129 -A different problem could arise if your test for a bug's presence is
   1.130 -not specific enough.  If you check for ``my program crashes'', then
   1.131 -both your crashing bug and an unrelated crashing bug that masks it
   1.132 -will look like the same thing, and mislead \hgcmd{bisect}.
   1.133 -
   1.134 -Another useful situation in which to use \hgcmdargs{bisect}{--skip} is
   1.135 -if you can't test a revision because your project was in a broken and
   1.136 -hence untestable state at that revision, perhaps because someone
   1.137 -checked in a change that prevented the project from building.
   1.138 -
   1.139 -\subsection{Bracket your search lazily}
   1.140 -
   1.141 -Choosing the first ``good'' and ``bad'' changesets that will mark the
   1.142 -end points of your search is often easy, but it bears a little
   1.143 -discussion nevertheless.  From the perspective of \hgcmd{bisect}, the
   1.144 -``newest'' changeset is conventionally ``bad'', and the older
   1.145 -changeset is ``good''.
   1.146 -
   1.147 -If you're having trouble remembering when a suitable ``good'' change
   1.148 -was, so that you can tell \hgcmd{bisect}, you could do worse than
   1.149 -testing changesets at random.  Just remember to eliminate contenders
   1.150 -that can't possibly exhibit the bug (perhaps because the feature with
   1.151 -the bug isn't present yet) and those where another problem masks the
   1.152 -bug (as I discussed above).
   1.153 -
   1.154 -Even if you end up ``early'' by thousands of changesets or months of
   1.155 -history, you will only add a handful of tests to the total number that
   1.156 -\hgcmd{bisect} must perform, thanks to its logarithmic behaviour.
   1.157 +\subsection{Tener en cuenta la interferencia entre fallos}
   1.158 +
   1.159 +Es posible que su búsqueda de un fallo pueda viciarse por la presencia
   1.160 +de otro. Por ejemplo, digamos que su programa se revienta en la
   1.161 +revisión 100, y que funcionó correctamente en la revisión 50.  Sin su
   1.162 +conocimiento, alguien introdujo un fallo con consecuencias grandes en
   1.163 +la revisión 60, y lo arregló en la revisión 80. Sus resultados
   1.164 +estarían distorcionados de una o muchas formas.
   1.165 +
   1.166 +Es posible que este fallo ``enmascare'' completamente al suyo, y que
   1.167 +podría haberse revelado antes de que su propio fallo haya tenido
   1.168 +oportunidad de manifestarse. Si no puede saltar el otro fallo(por
   1.169 +ejemplo, este evita que su proyecto se arme o compile), y de esta
   1.170 +forma no se pueda revisar si su fallo esté presente en un conjunto
   1.171 +particular de cambios, la orden \hgcmd{bisect} no podrá ayudarle
   1.172 +directamente. En cambio, puede marcar este conjunto de cambios como
   1.173 +al ejecutar \hgcmdargs{bisect}{--skip}.
   1.174 +
   1.175 +Un problema distinto podría surgir si su prueba de la presencia de un
   1.176 +fallo no es suficientemente específica. Si usted busca ``mi programa
   1.177 +se revienta'', entonces tanto su fallo como el otro fallo sin relación
   1.178 +que terminan presentando síntomas distintos, podría terminar
   1.179 +confundiendo a \hgcmd{bisect}.
   1.180 +
   1.181 +Otra situación en la cual sería de mucha utilidad emplear a
   1.182 +\hgcmdargs{bisect}{--skip} surge cuando usted no puede probar una
   1.183 +revisión porque su proyecto estaba en una situación de rompimiento y
   1.184 +por lo tanto en un estado en el cual era imposible hacer la prueba en
   1.185 +esa revisión, tal vez porque alguien consignó un cambio que hacía
   1.186 +imposible la construcción del proyecto.
   1.187 +
   1.188 +\subsection{Acotar la búsqueda perezosamente}
   1.189 +
   1.190 +Elegir los primeros ``buenos'' y ``malos'' conjuntos de cambios que
   1.191 +marcarán los límites de su búsqueda en general es sencillo, pero vale
   1.192 +la pena discutirlo.  Desde la perspectiva de \hgcmd{bisect}, el
   1.193 +conjunto de cambios ``más nuevo'' por convención es el ``malo'', y el
   1.194 +otro conjunto de cambios es el ``bueno''.
   1.195 +
   1.196 +Si no recuerda cuál podría ser el cambio ``bueno'', para informar a
   1.197 +\hgcmd{bisect}, podría hacer pruebas aleatorias en el peor de los
   1.198 +casos. Pero recuerde eliminar aquellos conjuntos de cambios que
   1.199 +podrían no exhibir el fallo(tal vez porque la característica donde se
   1.200 +presenta el fallo todavía no está presente) y aquellos en los cuales
   1.201 +otro fallo puede enmascararlo(como se discutió anteriormente).
   1.202 +
   1.203 +Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
   1.204 +meses de historia, solamente estaŕa adicionando unas pruebas contadas
   1.205 +para \hgcmd{bisect}, gracias al comportamiento logarítmico.
   1.206  
   1.207  %%% Local Variables: 
   1.208  %%% mode: latex