hgbook
changeset 397:b8d9066abcea
Translated initial paragraphs regarding bisect command
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Wed Nov 05 23:04:06 2008 -0500 (2008-11-05) |
parents | b7d4d66c3ae5 |
children | c368e324eeb2 |
files | es/undo.tex |
line diff
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