hgbook
changeset 401:3e78daaad99b
Finished undo chapter
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Fri Nov 07 21:33:22 2008 -0500 (2008-11-07) |
parents | f89ee6f63ea2 |
children | b05e35d641e4 |
files | es/Leame.1st es/undo.tex |
line diff
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