hgbook

annotate es/undo.tex @ 983:5e1e70fcdfdb

find changesets by author, revision, files, or words in the commit message
Corrected some errors.
- Indentation problems
- Syntax errors (missing </para>,...)
- French mistakes
author Frédéric Bouquet <youshe.jaalon@gmail.com>
date Tue Sep 08 23:42:42 2009 +0200 (2009-09-08)
parents 4af39acbb3cf
children
rev   line source
igor@374 1 \chapter{Encontrar y arreglar sus equivocaciones}
jerojasro@343 2 \label{chap:undo}
jerojasro@343 3
igor@374 4 Errar es humano, pero tratar adecuadamente las consecuencias requiere
igor@374 5 un sistema de control de revisiones de primera categoría. En este
igor@374 6 capítulo, discutiremos algunas técnicas que puede usar cuando
igor@374 7 encuentra que hay un problema enraizado en su proyecto. Mercurial
igor@374 8 tiene unas características poderosas que le ayudarán a isolar las
igor@374 9 fuentes de los problemas, y a dar cuenta de ellas apropiadamente.
igor@374 10
jerojasro@516 11 \section{Borrar el historial local}
igor@374 12
igor@374 13 \subsection{La consignación accidental}
igor@374 14
igor@374 15 Tengo el problema ocasional, pero persistente de teclear más rápido de
igor@374 16 lo que pienso, que aveces resulta en consignar un conjunto de cambios
igor@374 17 incompleto o simplemente malo. En mi caso, el conjunto de cambios
igor@378 18 incompleto consiste en que creé un nuevo fichero fuente, pero olvidé
igor@374 19 hacerle \hgcmd{add}. Un conjunto de cambios``simplemente malo'' no es
igor@374 20 tan común, pero sí resulta muy molesto.
igor@374 21
igor@378 22 \subsection{Hacer rollback una transacción}
jerojasro@343 23 \label{sec:undo:rollback}
jerojasro@343 24
igor@374 25 En la sección~\ref{sec:concepts:txn}, mencioné que Mercurial trata
igor@374 26 modificación a un repositorio como una \emph{transacción}. Cada vez
igor@374 27 que consigna un conjunto de cambios o lo jala de otro repositorio,
igor@378 28 Mercurial recuerda lo que hizo. Puede deshacer, o hacer \emph{roll back}\ndt{El significado igual que en los
igor@378 29 ambientes de sistemas manejadores de bases de datos se refiere a
igor@378 30 la atomicidad e integridad al devolver un conjunto de acciones que
igor@378 31 permitan dejar el repositorio en un estado consistente previo},
igor@374 32 exactamente una de tales acciones usando la orden \hgcmd{rollback}.
igor@374 33 (Ver en la sección~\ref{sec:undo:rollback-after-push} una anotación
igor@374 34 importante acerca del uso de esta orden.)
igor@374 35
igor@374 36 A continuación una equivocación que me sucede frecuentemente:
igor@374 37 consignar un cambio en el cual he creado un nuevo fichero, pero he
igor@374 38 olvidado hacerle \hgcmd{add}.
jerojasro@343 39 \interaction{rollback.commit}
igor@374 40 La salida de \hgcmd{status} después de la consignación confirma
igor@374 41 inmediatamente este error.
jerojasro@343 42 \interaction{rollback.status}
igor@378 43 La consignación capturó los cambios en el fichero \filename{a}, pero
igor@374 44 no el nuevo fichero \filename{b}. Si yo publicara este conjunto de
igor@374 45 cambios a un repositorio compartido con un colega, es bastante
igor@374 46 probable que algo en \filename{a} se refiriera a \filename{b}, el cual
igor@374 47 podría no estar presente cuando jalen mis cambios del repositorio. Me
igor@374 48 convertiría el sujeto de cierta indignación.
igor@374 49
igor@374 50 Como sea, la suerte me acompaña---Encontré mi error antes de publicar
igor@374 51 el conjunto de cambios. Uso la orden \hgcmd{rollback}, y Mercurial
igor@374 52 hace desaparecer el último conjunto de cambios.
jerojasro@343 53 \interaction{rollback.rollback}
jerojasro@516 54 El conjunto de cambios ya no está en el historial del repositorio, y el
igor@374 55 directorio de trabajo cree que el fichero \filename{a} ha sido
igor@377 56 modificado. La consignación y el roll back dejaron el directorio de
igor@377 57 trabajo exactamente como estaba antes de la consignación; el conjunto
igor@374 58 de cambios ha sido eliminado totlamente. Ahora puedo hacer \hgcmd{add}
igor@374 59 al fichero \filename{b}, y hacer de nuevo la consignación.
jerojasro@343 60 \interaction{rollback.add}
jerojasro@343 61
igor@374 62 \subsection{Erroneamente jalado}
igor@374 63
igor@374 64 Mantener ramas de desarrollo separadas de un proyecto en distintos
igor@374 65 repositorios es una práctica común con Mercurial. Su equipo de
igor@374 66 desarrollo puede tener un repositorio compartido para la versión ``0.9''
igor@374 67 y otra con cambios distintos para la versión ``1.0''.
igor@374 68
igor@374 69 Con este escenario, puede imaginar las consecuencias si tuviera un
igor@374 70 repositorio local ``0.9'', y jalara accidentalmente los cambios del
igor@374 71 repositorio compartido de la versión ``1.0'' en este. En el peor de
igor@374 72 los casos, por falta de atención, es posible que publique tales
igor@374 73 cambios en el árbol compartido ``0.9'', confundiendo a todo su equipo
jerojasro@520 74 de trabajo (pero no se preocupe, volveremos a este terrorífico
igor@374 75 escenario posteriormente). En todo caso, es muy probable que usted se
igor@374 76 de cuenta inmediatamente, dado que Mercurial mostrará el URL de donde
igor@374 77 está jalando, o que vea jalando una sospechosa gran cantidad de
igor@374 78 cambios en el repositorio.
igor@374 79
igor@377 80 La orden \hgcmd{rollback} excluirá eficientemente los conjuntos de
igor@377 81 cambios que haya acabado de jalar. Mercurial agrupa todos los cambios
igor@377 82 de un \hgcmd{pull} a una única transacción y bastará con un
igor@377 83 \hgcmd{rollback} para deshacer esta equivocación.
igor@377 84
igor@377 85 \subsection{Después de publicar, un roll back es futil}
jerojasro@343 86 \label{sec:undo:rollback-after-push}
jerojasro@343 87
igor@377 88 El valor de \hgcmd{rollback} se anula cuando ha publicado sus cambios
igor@377 89 a otro repositorio. Un cambio desaparece totalmente al hacer roll back,
igor@377 90 pero \emph{solamente} en el repositorio en el cual aplica
jerojasro@516 91 \hgcmd{rollback}. Debido a que un roll back elimina el historial,
igor@377 92 no hay forma de que la desaparición de un cambio se propague entre
igor@377 93 repositorios.
igor@377 94
igor@377 95 Si ha publicado un cambio en otro repositorio---particularmente si es
igor@377 96 un repositorio público---esencialmente está ``en terreno agreste,''
igor@377 97 y tendrá que reparar la equivocación de un modo distinto. Lo que
igor@377 98 pasará si publica un conjunto de cambios en algún sitio, hacer
igor@377 99 rollback y después volver a jalar del repositorio del cual había
igor@377 100 publicado, es que el conjunto de cambios reaparecerá en su repositorio.
igor@377 101
igor@377 102 (Si está absolutamente segruro de que el conjunto de cambios al que
igor@377 103 desea hacer rollback es el cambio más reciente del repositorio en el
igor@377 104 cual publicó, \emph{y} sabe que nadie más pudo haber jalado de tal
igor@377 105 repositorio, puede hacer rollback del conjunto de cambios allí, pero
igor@377 106 es mejor no confiar en una solución de este estilo. Si lo hace, tarde
igor@377 107 o temprano un conjunto de cambios logrará colarse en un repositorio
jerojasro@520 108 que usted no controle directamente (o del cual se ha olvidado), y
igor@377 109 volverá a hostigarle.)
igor@377 110
igor@377 111 \subsection{Solamente hay un roll back}
igor@377 112
igor@377 113 Mercurial almacena exactamente una transacción en su bitácora de
igor@377 114 transacciones; tal transacción es la más reciente de las que haya
igor@377 115 ocurrido en el repositorio. Esto significa que solamente puede hacer
igor@377 116 roll back a una transacción. Si espera poder hacer roll back a una
igor@377 117 transacción después al antecesor, observará que no es el
igor@377 118 comportamiento que obtendrá.
jerojasro@343 119 \interaction{rollback.twice}
igor@377 120 Una vez que haya aplicado un rollback en una transacción a un
igor@377 121 repositorio, no podrá volver a hacer rollback hasta que haga una
igor@377 122 consignación o haya jalado.
jerojasro@343 123
igor@386 124 \section{Revertir un cambio equivocado}
igor@386 125
igor@386 126 Si modifica un fichero y se da cuenta que no quería realmente cambiar
igor@386 127 tal fichero, y todavía no ha consignado los cambios, la orden
igor@386 128 necesaria es \hgcmd{revert}. Observa el conjunto de cambios padre del
igor@386 129 directorio y restaura los contenidos del fichero al estado de tal
igor@386 130 conjunto de cambios. (Es una forma larga de decirlo, usualmente
igor@386 131 deshace sus modificaciones.)
igor@386 132
igor@386 133 Ilustremos como actúa la orden \hgcmd{revert} con un ejemplo
igor@386 134 pequeño. Comenzaremos modificando un fichero al cual Mercurial ya está
igor@386 135 siguiendo.
jerojasro@343 136 \interaction{daily.revert.modify}
igor@386 137 Si no queremos ese cambio, podemos aplicar \hgcmd{revert} al fichero.
jerojasro@343 138 \interaction{daily.revert.unmodify}
igor@386 139 La orden \hgcmd{revert} nos brinda un grado adicional de seguridad
igor@386 140 guardando nuestro fichero modificado con la extensión \filename{.orig}.
jerojasro@343 141 \interaction{daily.revert.status}
jerojasro@343 142
igor@386 143 Este es un resumen de casos en los cuales la orden \hgcmd{revert} es
igor@386 144 de utilidad. Describiremos cada uno de ellos con más detalle en la
igor@386 145 sección siguiente.
jerojasro@343 146 \begin{itemize}
igor@386 147 \item Si usted modifica un fichero, lo restaurará a su estado sin
igor@386 148 modificación previo.
igor@386 149 \item Si usted hace \hgcmd{add} a un fichero, revertirá el estado de
igor@386 150 ``adicionado'' del fichero, pero no lo tocará
igor@386 151 \item Si borra un fichero sin decirle a Mercurial, restaurará el
igor@386 152 fichero con sus contenidos sin modificación.
igor@386 153 \item Si usa la orden \hgcmd{remove} para eliminar un fichero, deshará
igor@386 154 el estado ``removido'' del fichero, y lo restaurará con sus
igor@386 155 contenidos sin modificación.
jerojasro@343 156 \end{itemize}
jerojasro@343 157
igor@386 158 \subsection{Errores al administrar ficheros}
jerojasro@343 159 \label{sec:undo:mgmt}
jerojasro@343 160
igor@386 161 La orden \hgcmd{revert} es útil para más que ficheros modificados. Le
igor@386 162 permite reversar los resultados de todas las órdenes de administración
igor@386 163 de ficheros que provee Mercurial---\hgcmd{add}, \hgcmd{remove}, y las
igor@386 164 demás.
igor@386 165
igor@386 166 Si usted hace \hgcmd{add} a un fichero, y no deseaba que Mercurial le
igor@386 167 diera seguimiento, use \hgcmd{revert} para deshacer la adición. No se
igor@386 168 preocupe; Mercurial no modificará de forma alguna el fichero.
igor@386 169 Solamente lo ``desmarcará''.
jerojasro@343 170 \interaction{daily.revert.add}
jerojasro@343 171
igor@386 172 De forma similar, Si le solicita a Mercurial hacer \hgcmd{remove} a un
igor@386 173 fichero, puede usar \hgcmd{revert} para restarurarlo a los contenidos
igor@386 174 que tenía la revisión padre del directorio de trabajo.
jerojasro@343 175 \interaction{daily.revert.remove}
igor@386 176 Funciona de la misma manera para un fichero que usted haya eliminado
igor@386 177 manualmente, sin decirle a Mercurial (recuerde que en la terminología
igor@386 178 de Mercurial esta clase de fichero se llama ``faltante'').
jerojasro@343 179 \interaction{daily.revert.missing}
jerojasro@343 180
igor@386 181 Si usted revierte un \hgcmd{copy}, el fichero a donde se copió
igor@386 182 permanece en su directorio de trabajo, pero sin seguimiento. Dado que
igor@386 183 una copia no afecta el fichero fuente de copiado de ninguna maner,
igor@386 184 Mercurial no hace nada con este.
jerojasro@343 185 \interaction{daily.revert.copy}
jerojasro@343 186
igor@386 187 \subsubsection{Un caso ligeramente especial:revertir un renombramiento}
igor@386 188
igor@386 189 Si hace \hgcmd{rename} a un fichero, hay un detalle que debe tener en
igor@386 190 cuenta. Cuando aplica \hgcmd{revert} a un cambio de nombre, no es
igor@386 191 suficiente proveer el nombre del fichero destino, como puede verlo en
igor@386 192 el siguiente ejemplo.
jerojasro@343 193 \interaction{daily.revert.rename}
igor@386 194 Como puede ver en la salida de \hgcmd{status}, el fichero con el nuevo
igor@386 195 nombre no se identifica más como agregado, pero el fichero con el
igor@386 196 nombre-\emph{inicial} se elimna! Esto es contra-intuitivo (por lo
igor@386 197 menos para mí), pero por lo menos es fácil arreglarlo.
jerojasro@343 198 \interaction{daily.revert.rename-orig}
igor@386 199 Por lo tanto, recuerde, para revertir un \hgcmd{rename}, debe proveer
igor@386 200 \emph{ambos} nombres, la fuente y el destino.
jerojasro@343 201
jerojasro@343 202 % TODO: the output doesn't look like it will be removed!
jerojasro@343 203
igor@386 204 (A propósito, si elimina un fichero, y modifica el fichero con el
igor@386 205 nuevo nombre, al revertir ambos componentes del renombramiento, cuando
igor@386 206 Mercurial restaure el fichero que fue eliminado como parte del
igor@386 207 renombramiento, no será modificado.
igor@400 208 Si necesita que las modificaciones en el fichero destino del
igor@386 209 renombramiento se muestren, no olvide copiarlas encima.)
igor@386 210
igor@387 211 Estos aspectos engorrosos al revertir un renombramiento se constituyen
igor@386 212 discutiblemente en un fallo de Mercurial.
jerojasro@343 213
igor@387 214 \section{Tratar cambios consignados}
igor@387 215
igor@387 216 Considere un caso en el que ha consignado el cambio $a$, y otro cambio
igor@387 217 $b$ sobre este; se ha dado cuenta que el cambio $a$ era
igor@387 218 incorrecto. Mercurial le permite ``retroceder'' un conjunto de cambios
igor@387 219 completo automáticamente, y construir bloques que le permitan revertir
igor@387 220 parte de un conjunto de cambios a mano.
igor@387 221
igor@387 222 Antes de leer esta sección, hay algo para tener en cuenta: la orden
jerojasro@518 223 \hgcmd{backout} deshace cambios \emph{adicionando} al historial, sin
igor@387 224 modificar o borrar. Es la herramienta correcta si está arreglando
igor@387 225 fallos, pero no si está tratando de deshacer algún cambio que tiene
igor@387 226 consecuencias catastróficas. Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}.
igor@387 227
igor@387 228 \subsection{Retroceder un conjunto de cambios}
igor@387 229
igor@387 230 La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo
jerojasro@516 231 un conjunto de cambios de forma automatizada. Dado que el historial de
igor@387 232 Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto
igor@387 233 de cambios que usted desea deshacer. En cambio, crea un nuevo
igor@387 234 conjunto de cambios que \emph{reversa} el conjunto de cambios que
igor@387 235 usted indique.
igor@387 236
igor@387 237 La operación de la orden \hgcmd{backout} es un poco intrincada, y lo
igor@387 238 ilustraremos con algunos ejemplos. Primero crearemos un repositorio
igor@387 239 con algunos cambios sencillos.
jerojasro@343 240 \interaction{backout.init}
jerojasro@343 241
igor@387 242 La orden \hgcmd{backout} toma un ID de conjunto de cambios como su
igor@387 243 argumento; el conjunto de cambios a retroceder. Normalmente
igor@387 244 \hgcmd{backout} le ofrecerá un editor de texto para escribir el
igor@387 245 mensaje de la consignación, para dejar un registro de por qué está
igor@387 246 retrocediendo. En este ejemplo, colocamos un mensaje en la
jerojasro@522 247 consignación usando la opción \hgopt{backout}{-m}.
igor@387 248
igor@388 249 \subsection{Retroceder el conjunto de cambios punta}
igor@387 250
igor@387 251 Comenzamos retrocediendo el último conjunto de cambios que consignamos.
jerojasro@343 252 \interaction{backout.simple}
igor@387 253 Puede ver que la segunda línea de \filename{myfile} ya no está
igor@387 254 presente. La salida de \hgcmd{log} nos da una idea de lo que la orden
igor@387 255 \hgcmd{backout} ha hecho.
jerojasro@343 256 \interaction{backout.simple.log}
igor@387 257 Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
igor@387 258 un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
igor@387 259 ver en la figura~\ref{fig:undo:backout}, que presenta una vista
jerojasro@517 260 gráfica del historial de cambios. Como puede ver, el historial es
jerojasro@516 261 bonito y lineal.
jerojasro@343 262
jerojasro@343 263 \begin{figure}[htb]
jerojasro@343 264 \centering
jerojasro@343 265 \grafix{undo-simple}
igor@387 266 \caption{Retroceso de un cambio con la orden \hgcmd{backout}}
jerojasro@343 267 \label{fig:undo:backout}
jerojasro@343 268 \end{figure}
jerojasro@343 269
igor@388 270 \subsection{Retroceso de un cambio que no es la punta}
igor@387 271
igor@387 272 Si desea retrocede un cambio distinto al último que ha consignado, use
igor@387 273 la opción \hgopt{backout}{--merge} a la orden \hgcmd{backout}.
jerojasro@343 274 \interaction{backout.non-tip.clone}
igor@387 275 Que resulta en un retroceso de un conjunto de cambios ``en un sólo
igor@387 276 tiro'', una operación que resulta normalmente rápida y sencilla.
jerojasro@343 277 \interaction{backout.non-tip.backout}
jerojasro@343 278
igor@387 279 Si ve los contenidos del fichero \filename{myfile} después de
igor@387 280 finalizar el retroceso, verá que el primer y el tercer cambio están
igor@387 281 presentes, pero no el segundo.
jerojasro@343 282 \interaction{backout.non-tip.cat}
jerojasro@343 283
jerojasro@516 284 Como lo muestra el historial gráfico en la
igor@387 285 figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna
igor@387 286 \emph{dos} cambios en estas situaciones (los nodos encerrados en una
igor@387 287 caja son aquellos que Mercurial consigna automaticamente). Antes de
igor@387 288 que Mercurial comience el proceso de retroceso, primero recuerda cuál
igor@387 289 es el padre del directorio de trabajo. Posteriormente hace un
igor@387 290 retroceso al conjunto de cambios objetivo y lo consigna como un
igor@387 291 conjunto de cambios. Finalmente, fusiona con el padre anterior del
igor@387 292 directorio de trabajo, y consigna el resultado de la fusión.
jerojasro@343 293
jerojasro@343 294 % TODO: to me it looks like mercurial doesn't commit the second merge automatically!
jerojasro@343 295
jerojasro@343 296 \begin{figure}[htb]
jerojasro@343 297 \centering
jerojasro@343 298 \grafix{undo-non-tip}
igor@388 299 \caption{Retroceso automatizado de un cambio a algo que no es la punta con la orden \hgcmd{backout}}
jerojasro@343 300 \label{fig:undo:backout-non-tip}
jerojasro@343 301 \end{figure}
jerojasro@343 302
igor@387 303 El resultado es que usted termina ``donde estaba'', solamente con un
jerojasro@516 304 poco de historial adicional que deshace el efecto de un conjunto de
igor@387 305 cambios que usted quería evitar.
jerojasro@343 306
igor@388 307 \subsubsection{Use siempre la opción \hgopt{backout}{--merge}}
igor@388 308
igor@388 309 De hecho, dado que la opción \hgopt{backout}{--merge} siempre hara lo
igor@388 310 ``correcto'' esté o no retrocediendo el conjunto de cambios punta
igor@388 311 (p.e.~no tratará de fusionar si está retrocediendo la punta, dado que
igor@388 312 no es necesario), usted debería usar \emph{siempre} esta opción cuando
igor@388 313 ejecuta la orden \hgcmd{backout}.
igor@388 314
igor@388 315 \subsection{Más control sobre el proceso de retroceso}
igor@388 316
igor@388 317 A pesar de que recomiendo usar siempre la opción
igor@388 318 \hgopt{backout}{--merge} cuando está retrocediendo un cambio, la orden
igor@388 319 \hgcmd{backout} le permite decidir cómo mezclar un retroceso de un
igor@388 320 conjunto de cambios. Es muy extraño que usted necestite tomar control
igor@388 321 del proceso de retroceso de forma manual, pero puede ser útil entender
igor@388 322 lo que la orden \hgcmd{backout} está haciendo automáticamente para
igor@388 323 usted. Para ilustrarlo, clonemos nuestro primer repositorio, pero
igor@388 324 omitamos el retroceso que contiene.
jerojasro@343 325
jerojasro@343 326 \interaction{backout.manual.clone}
igor@388 327 Como en el ejemplo anterior, consignaremos un tercer cambio, después
igor@388 328 haremos retroceso de su padre, y veremos qué pasa.
jerojasro@343 329 \interaction{backout.manual.backout}
igor@388 330 Nuestro nuevo conjunto de cambios es de nuevo un descendiente del
igor@388 331 conjunto de cambio que retrocedimos; es por lo tanto una nueva cabeza,
igor@388 332 \emph{no} un descendiente del conjunto de cambios que era la punta. La
igor@388 333 orden \hgcmd{backout} fue muy explícita diciéndolo.
jerojasro@343 334 \interaction{backout.manual.log}
jerojasro@343 335
jerojasro@516 336 De nuevo, es más sencillo lo que pasó viendo una gráfica del
jerojasro@516 337 historial de revisiones, en la figura~\ref{fig:undo:backout-manual}.
igor@388 338 Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un
igor@388 339 cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al
igor@388 340 repositorio (el cambio que consignó está encerrado en una caja).
jerojasro@343 341
jerojasro@343 342 \begin{figure}[htb]
jerojasro@343 343 \centering
jerojasro@343 344 \grafix{undo-manual}
igor@388 345 \caption{Retroceso usando la orden \hgcmd{backout}}
jerojasro@343 346 \label{fig:undo:backout-manual}
jerojasro@343 347 \end{figure}
jerojasro@343 348
igor@388 349 Después de que la orden \hgcmd{backout} ha terminado, deja un nuevo
igor@388 350 conjunto de cambios de ``retroceso'' como el padre del directorio de trabajo.
jerojasro@343 351 \interaction{backout.manual.parents}
igor@388 352 Ahora tenemos dos conjuntos de cambios aislados.
jerojasro@343 353 \interaction{backout.manual.heads}
jerojasro@343 354
igor@388 355 Reflexionemos acerca de lo que esperamos ver como contenidos de
igor@388 356 \filename{myfile}. El primer cambio debería estar presente, porque
igor@388 357 nunca le hicimos retroceso. El segundo cambio debió desaparecer,
jerojasro@517 358 puesto que es el que retrocedimos. Dado que la gráfica del historial
igor@388 359 muestra que el tercer camlio es una cabeza separada, \emph{no}
igor@388 360 esperamos ver el tercer cambio presente en \filename{myfile}.
jerojasro@343 361 \interaction{backout.manual.cat}
igor@400 362 Para que el tercer cambio esté en el fichero, hacemos una fusión usual
igor@388 363 de las dos cabezas.
jerojasro@343 364 \interaction{backout.manual.merge}
jerojasro@516 365 Después de eso, el historial gráfica de nuestro repositorio luce como
igor@388 366 la figura~\ref{fig:undo:backout-manual-merge}.
jerojasro@343 367
jerojasro@343 368 \begin{figure}[htb]
jerojasro@343 369 \centering
jerojasro@343 370 \grafix{undo-manual-merge}
igor@388 371 \caption{Fusión manual de un retroceso}
jerojasro@343 372 \label{fig:undo:backout-manual-merge}
jerojasro@343 373 \end{figure}
jerojasro@343 374
igor@388 375 \subsection{Por qué \hgcmd{backout} hace lo que hace}
igor@388 376
igor@388 377 Esta es una descripción corta de cómo trabaja la orden \hgcmd{backout}.
jerojasro@343 378 \begin{enumerate}
igor@388 379 \item Se asegura de que el directorio de trabajo es ``limpio'', esto
igor@388 380 es, que la salida de \hgcmd{status} debería ser vacía.
igor@388 381 \item Recuerda el padre actual del directorio de trabajo. A este
igor@388 382 conjunto de cambio lo llamaremos \texttt{orig}
igor@388 383 \item Hace el equivalente de un \hgcmd{update} para sincronizar el
igor@388 384 directorio de trabajo con el conjunto de cambios que usted quiere
igor@388 385 retroceder. Lo llamaremos \texttt{backout}
igor@388 386 \item Encuentra el padre del conjunto de cambios. Lo llamaremos
igor@388 387 \texttt{parent}.
igor@400 388 \item Para cada fichero del conjunto de cambios que el
igor@388 389 \texttt{retroceso} afecte, hará el equivalente a
igor@388 390 \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a
igor@388 391 los contenidos que tenía antes de que el conjunto de cambios fuera
igor@388 392 consignado.
igor@388 393 \item Se consigna el resultado como un nuevo conjunto de cambios y
igor@388 394 tiene a \texttt{backout} como su padre.
igor@388 395 \item Si especifica \hgopt{backout}{--merge} en la línea de comandos,
igor@388 396 se fusiona con \texttt{orig}, y se consigna el resultado de la
igor@388 397 fusión.
jerojasro@343 398 \end{enumerate}
jerojasro@343 399
igor@388 400 Una vía alternativa de implementar la orden \hgcmd{backout} sería usar
igor@388 401 \hgcmd{export} sobre el conjunto de cambios a retroceder como un diff
igor@388 402 y después usar laa opción \cmdopt{patch}{--reverse} de la orden
igor@388 403 \command{patch} para reversar el efecto del cambio sin molestar el
igor@388 404 directorio de trabajo. Suena mucho más simple, pero no funcionaría
igor@388 405 bien ni de cerca.
igor@388 406
igor@388 407 La razón por la cual \hgcmd{backout} hace una actualización, una
igor@388 408 consignación, una fusión y otra consignación es para dar a la
igor@388 409 maquinaria de fusión la mayor oportunidad de hacer un buen trabajo
igor@388 410 cuando se trata con todos los cambios \emph{entre} el cambio que está
igor@388 411 retrocediendo y la punta actual.
igor@388 412
igor@388 413 Si está retrocediendo un conjunto de cambios que está a unas ~100
jerojasro@516 414 atrás en su historial del proyecto, las posibilidades de que una orden
igor@388 415 \command{patch} sea capaz de ser aplicada a un diff reverso,
igor@388 416 claramente no son altas, porque los cambios que intervienen podrían
igor@388 417 ``no coincidir con el contexto'' que \command{patch} usa para
igor@388 418 determinar si puede aplicar un parche (si esto suena como cháchara,
igor@388 419 vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}).
igor@388 420 Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros
igor@388 421 y directorios renombrados, cambios de permisos, y modificaciones a
igor@400 422 ficheros binarios, nada de lo cual la orden \command{patch} puede manejar.
jerojasro@343 423
igor@389 424 \section{Cambios que nunca debieron ocurrir}
jerojasro@343 425 \label{sec:undo:aaaiiieee}
jerojasro@343 426
igor@389 427 En la mayoría de los casos, la orden \hgcmd{backout} es exactamente lo
igor@389 428 que necesita para deshacer los efectos de un cambio. Deja un registro
igor@389 429 permanente y exacto de lo que usted hizo, cuando se consignó el
igor@389 430 conjunto de cambios original y cuando se hizo la limpieza.
igor@389 431
igor@389 432 En ocasiones particulares, puede haber consignado un cambio que no
igor@389 433 debería estar de ninguna forma en el repositorio. Por ejemplo, sería
igor@389 434 muy inusual, y considerado como una equivocación, consignar los
jerojasro@525 435 ficheros objeto junto con el código fuente. Los ficheros objeto no
igor@389 436 tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el
igor@389 437 tamaño del repositorio y la cantidad de tiempo que se emplea al clonar
igor@389 438 o jalar cambios.
igor@389 439
igor@389 440 Antes de discutir las opciones que tiene si consignó cambio del tipo
igor@389 441 ``bolsa de papel deschable'' (el tipo que es tan malo que le gustaría
igor@389 442 colocarse una bolsa de papel desechable en su cabeza), permítame
igor@389 443 discutir primero unas aproximaciones que probablemente no funcionen.
igor@389 444
jerojasro@516 445 Dado que Mercurial trata de forma acumulativa al historial---cada
jerojasro@516 446 cambio se coloca encima de todos los cambios que le
jerojasro@516 447 preceden---usualmente usted no puede hacer que unos cambios desastrosos
igor@389 448 desaparezcan. La única excepción es cuando usted ha acabado de
igor@389 449 consignar un cambio y este no ha sido publicado o jalado en otro
igor@389 450 repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con
jerojasro@516 451 seguridad, como detallé en la sección~\ref{sec:undo:rollback}.
igor@389 452
igor@389 453 Después de que usted haya publicado un cambio en otro repositorio, usted
igor@389 454 \emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia
igor@389 455 local desaparezca el cambio, pero no tendrá las consecuencias que
igor@389 456 desea. El cambio estará presente en un repositorio remoto, y
igor@389 457 reaparecerá en su repositorio local la próxima vez que jale
igor@389 458
igor@389 459 Si una situación como esta se presenta, y usted sabe en qué
igor@389 460 repositorios su mal cambio se ha propagado, puede \emph{intentar}
igor@389 461 deshacerse del conjunto de cambios de \emph{todos} los repositorios en
igor@389 462 los que se pueda encontrar. Esta por supuesto, no es una solución
igor@389 463 satisfactoria: si usted deja de hacerlo en un solo repositorio,
igor@389 464 mientras esté eliminándolo, el cambio todavía estará ``allí afuera'',
igor@389 465 y podría propagarse más tarde.
igor@389 466
igor@389 467 Si ha consignado uno o más cambios \emph{después} del cambio que desea
igor@389 468 desaparecer, sus opciones son aún más reducidas. Mercurial no provee
jerojasro@516 469 una forma de ``cabar un hueco'' en el historial, dejando los conjuntos
igor@389 470 de cambios intactos.
igor@389 471
igor@389 472 %Dejamos de traducir lo que viene a continuación, porque será
igor@389 473 %modificado por upstream...
jerojasro@343 474
jerojasro@343 475 XXX This needs filling out. The \texttt{hg-replay} script in the
jerojasro@343 476 \texttt{examples} directory works, but doesn't handle merge
jerojasro@343 477 changesets. Kind of an important omission.
jerojasro@343 478
igor@397 479 \subsection{Cómo protegerse de cambios que han ``escapado''}
igor@397 480
igor@397 481 Si ha consignado cambios a su repositorio local y estos han sido
igor@397 482 publicados o jalados en cualquier otro sitio, no es necesariamente un
igor@397 483 desastre. Puede protegerse de antemano de ciertas clases de conjuntos
igor@397 484 de cambios malos. Esto es particularmente sencillo si su equipo de
igor@397 485 trabajo jala cambios de un repositorio central.
igor@397 486
jerojasro@458 487 Al configurar algunos ganchos en el repositorio central para validar
jerojasro@520 488 conjuntos de cambios (ver capítulo~\ref{chap:hook}), puede prevenir la
igor@397 489 publicación automáticamente de cierta clase de cambios malos. Con tal
igor@397 490 configuración, cierta clase de conjuntos de cambios malos tenderán
igor@397 491 naturalmente a``morir'' debido a que no pueden propagarse al
igor@397 492 repositorio central. Esto sucederá sin necesidad de intervención
igor@397 493 explícita.
igor@397 494
igor@397 495 Por ejemplo, un gancho de cambios de entrada que verifique que un
igor@397 496 conjunto de cambios compila, puede prevenir que la gente ``rompa
igor@397 497 la compilación'' inadvertidamente.
igor@397 498
igor@397 499 \section{Al encuentro de la fuente de un fallo}
jerojasro@343 500 \label{sec:undo:bisect}
jerojasro@343 501
igor@397 502 Aunque es muy bueno poder retroceder el conjunto de cambios que
igor@397 503 originó un fallo, se requiere que usted sepa cual conjunto de cambios
igor@397 504 retroceder. Mercurial brinda una orden invaluable, llamada
igor@397 505 \hgcmd{bisect}, que ayuda a automatizar este proceso y a alcanzarlo
igor@397 506 muy eficientemente.
igor@397 507
igor@397 508 La idea tras la orden \hgcmd{bisect} es que el conjunto de cambios que
igor@397 509 ha introducido un cambio de comportamiento pueda identificarse con una
igor@397 510 prueba binaria sencilla. No tiene que saber qué pieza de código
igor@397 511 introdujo el cambio, pero si requiere que sepa cómo probar la
igor@397 512 existencia de un fallo. La orden \hgcmd{bisect} usa su prueba para
igor@397 513 dirigir su búsqueda del conjunto de cambios que introdujo el código
igor@397 514 causante del fallo.
igor@397 515
igor@397 516 A continuación un conjunto de escenarios que puede ayudarle a entender
igor@397 517 cómo puede aplicar esta orden.
jerojasro@343 518 \begin{itemize}
igor@397 519 \item La versión más reciente de su programa tiene un fallo que usted
igor@397 520 recuerda no estaba hace unas semanas, pero no sabe cuándo fue
igor@397 521 introducido. En este caso, su prueba binaria busca la presencia de
igor@397 522 tal fallo.
igor@397 523 \item Usted arregló un fallo en un apurto, y es hora de dar por
igor@397 524 cerrado el caso en la base de datos de fallos de su equipo de
igor@397 525 trabajo. La base de datos de fallos requiere el ID del conjunto de
igor@397 526 cambios que permita dar por cerrado el caso, pero usted no recuerda
igor@397 527 qué conjunto de cambios arregló tal fallo. De nuevo la prueba
igor@397 528 binaria revisa la presencia del fallo.
igor@397 529 \item Su programa funciona correctamente, pero core ~15\% más lento
igor@397 530 que la última vez que lo midió. Usted desea saber qué conjunto de
igor@397 531 cambios introdujo esta disminución de desempeño. En este caso su
igor@397 532 prueba binaria mide el desempeño de su programa, para ver dónde es
igor@397 533 ``rápido'' y dónde es ``lento''.
igor@397 534 \item Los tamaños de los componentes del proyecto que usted lleva se
igor@397 535 expandieron recientemente, y sospecha que algo cambio en la forma en
igor@397 536 que se construye su proyecto.
jerojasro@343 537 \end{itemize}
jerojasro@343 538
igor@397 539 Para estos ejemplos debería ser claro que la orden \hgcmd{bisect}
igor@397 540 es útil no solamente para encontrar la fuente de los fallos. Puede
igor@397 541 usarla para encontrar cualquier ``propiedad emergente'' de un
jerojasro@520 542 repositorio (Cualquier cosa que usted no pueda encontrar con una
igor@400 543 búsqueda de texto sencilla sobre los ficheros en el árbol) para la
igor@397 544 cual pueda escribir una prueba binaria.
igor@397 545
igor@397 546 A continuación introduciremos algo terminología, para aclarar qué
igor@397 547 partes del proceso de búsqueda son su responsabilidad y cuáles de
igor@397 548 Mercurial. Una \emph{prueba} es algo que \emph{usted} ejecuta cuando
igor@397 549 \hgcmd{bisect} elige un conjunto de cambios. Un \emph{sondeo} es lo que
igor@397 550 \hgcmd{bisect} ejecuta para decidir si una revisión es buena. Finalmente,
igor@397 551 usaremos la palabra ``biseccionar', en frases como ``buscar con la
igor@397 552 orden \hgcmd{bisect}''.
igor@397 553
igor@397 554 Una forma sencilla de automatizar el proceso de búsqueda sería probar
igor@397 555 cada conjunto de cambios. Lo cual escala muy poco. Si le tomó diez
igor@397 556 minutos hacer pruebas sobre un conjunto de cambios y tiene 10.000
igor@397 557 conjuntos de cambios en su repositorio, esta aproximación exhaustiva
igor@397 558 tomaría en promedio~35 \emph{días} para encontrar el conjunto de
igor@397 559 cambios que introdujo el fallo. Incluso si supiera que el fallo se
igor@397 560 introdujo en un de los últimos 500 conjuntos de cambios y limitara la
igor@397 561 búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
igor@397 562 conjunto de cambios culpable.
igor@397 563
jerojasro@516 564 La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' del
jerojasro@516 565 historial de revisiones de su proyecto para hacer una búsqueda
igor@397 566 proporcional al \emph{logaritmo} del número de conjunto de cambios a
jerojasro@516 567 revisar (el tipo de búsqueda que realiza se llama búsqueda
igor@397 568 binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
jerojasro@516 569 cambios tomará menos de 3 horas, incluso a diez minutos por prueba (La
igor@397 570 búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
igor@397 571 última centena de conjuntos de cambios, tomará a lo sumo una
jerojasro@516 572 hora (Apenas unas 7 pruebas).
igor@397 573
igor@397 574 La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
jerojasro@517 575 del historial de revisiones del proyecto con Mercurial, así que no
igor@397 576 hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
jerojasro@516 577 repositorio. Puede evitar ramas enteras de historial con un solo
igor@397 578 sondeo.
jerojasro@343 579
igor@398 580 \subsection{Uso de la orden \hgcmd{bisect}}
igor@398 581
igor@398 582 A continuación un ejemplo de \hgcmd{bisect} en acción.
jerojasro@343 583
jerojasro@343 584 \begin{note}
igor@398 585 En las versiones 0.9.5 y anteriores de Mercurial, \hgcmd{bisect} no
igor@398 586 era una orden incluída en la distribución principal: se ofrecía como
igor@398 587 una extensión de Mercurial. Esta sección describe la orden embebida
igor@398 588 y no la extensión anterior.
jerojasro@343 589 \end{note}
jerojasro@343 590
igor@398 591 Creamos un repostorio para probar el comando \hgcmd{bisect} de forma
igor@398 592 aislada
jerojasro@343 593 \interaction{bisect.init}
igor@398 594 Simularemos de forma sencilla un proyecto con un fallo: haremos
igor@398 595 cambios triviales en un ciclo, e indicaremos que un cambio específico
igor@398 596 sea el ``fallo''. Este ciclo crea 35 conjuntos de cambios, cada uno
igor@400 597 añade un único fichero al repositorio. Representaremos nuestro ``fallo''
igor@398 598 con un fichero que contiene el texto ``tengo un gub''.
jerojasro@343 599 \interaction{bisect.commits}
jerojasro@343 600
igor@398 601 A continuación observaremos cómo usar la orden \hgcmd{bisect}. Podemos
igor@398 602 usar el mecanismo de ayuda embebida que trae Mercurial.
jerojasro@343 603 \interaction{bisect.help}
jerojasro@343 604
igor@398 605 La orden \hgcmd{bisect} trabaja en etapas, de la siguiente forma:
jerojasro@343 606 \begin{enumerate}
igor@398 607 \item Usted ejecuta una prueba binaria.
jerojasro@343 608 \begin{itemize}
igor@398 609 \item Si la prueba es exitosa, usted se lo indicará a \hgcmd{bisect}
igor@398 610 ejecutando la orden \hgcmdargs{bisect}{good}.
igor@398 611 \item Si falla, ejecutará la orden \hgcmdargs{bisect}{--bad}.
jerojasro@343 612 \end{itemize}
igor@398 613 \item La orden usa su información para decidir qué conjuntos de
igor@398 614 cambios deben probarse a continuación.
igor@398 615 \item Actualiza el directorio de trabajo a tal conjunto de cambios y
igor@398 616 el proceso se lleva a cabo de nuevo.
jerojasro@343 617 \end{enumerate}
igor@398 618 El proceso termina cuando \hgcmd{bisect} identifica un único conjunto
igor@398 619 de cambios que marca el punto donde se encontró la transición de
igor@398 620 ``exitoso'' a ``fallido''.
igor@398 621
igor@398 622 Para comenzar la búsqueda, es indispensable ejecutar la orden
igor@398 623 \hgcmdargs{bisect}{--reset}.
jerojasro@343 624 \interaction{bisect.search.init}
jerojasro@343 625
igor@398 626 En nuestro caso, la prueba binaria es sencilla: revisamos si el
igor@400 627 fichero en el repositorio contiene la cadena ``tengo un gub''. Si la
igor@398 628 tiene, este conjunto de cambios contiene aquel que ``causó el fallo''.
igor@398 629 Por convención, un conjunto de cambios que tiene la propiedad que
igor@398 630 estamos buscando es ``malo'', mientras que el otro que no la tiene es
igor@398 631 ``bueno''.
igor@398 632
igor@398 633 En la mayoría de casos, la revisión del directorio actual (usualmente
igor@398 634 la punta) exhibe el problema introducido por el cambio con el fallo,
igor@398 635 por lo tanto la marcaremos como ``mala''.
jerojasro@343 636 \interaction{bisect.search.bad-init}
jerojasro@343 637
igor@398 638 Nuestra próxima tarea es nominar al conjunto de cambios que sabemos
igor@398 639 \emph{no} tiene el fallo; la orden \hgcmd{bisect} ``acotará'' su
igor@398 640 búsqueda entre el primer par de conjuntos de cambios buenos y malos.
igor@398 641 En nuestro caso, sabemos que la revisión~10 no tenía el fallo. (Más
igor@398 642 adelante diré un poco más acerca de la elección del conjunto de
igor@398 643 cambios ``bueno''.)
jerojasro@343 644 \interaction{bisect.search.good-init}
jerojasro@343 645
igor@398 646 Note que esta orden mostró algo.
jerojasro@343 647 \begin{itemize}
igor@398 648 \item Nos dijo cuántos conjuntos de cambios debe considerar antes de
igor@398 649 que pueda identifica aquel que introdujo el fallo, y cuántas pruebas
igor@398 650 se requerirán.
igor@398 651 \item Actualizó el directorio de trabajo al siguiente conjunto de
igor@398 652 cambios, y nos dijo qué conjunto de cambios está evaluando.
jerojasro@343 653 \end{itemize}
jerojasro@343 654
igor@398 655 Ahora ejecutamos nuestra prueba en el directorio de trabajo. Usamos la
igor@398 656 orden \command{grep} para ver si nuestro fichero ``malo'' está
igor@398 657 presente en el directorio de trabajo. Si lo está, esta revisión es
igor@398 658 mala; si no esta revisión es buena.
jerojasro@343 659 \interaction{bisect.search.step1}
jerojasro@343 660
igor@398 661 Esta prueba luce como candidata perfecta para automatizarse, por lo
igor@398 662 tanto la convertimos en una función de interfaz de comandos.
jerojasro@343 663 \interaction{bisect.search.mytest}
igor@398 664 Ahora podemos ejecutar un paso entero de pruebas con un solo comando,
jerojasro@343 665 \texttt{mytest}.
jerojasro@343 666 \interaction{bisect.search.step2}
igor@398 667 Unas invocaciones más de nuestra prueba, y hemos terminado.
jerojasro@343 668 \interaction{bisect.search.rest}
jerojasro@343 669
igor@398 670 Aunque teníamos unos~40 conjuntos de cambios en los cuales buscar, la
igor@398 671 orden \hgcmd{bisect} nos permitió encontrar el conjunto de cambios que
igor@398 672 introdujo el ``fallo'' con sólo cinco pruebas. Porque el número de
igor@398 673 pruebas que la orden \hgcmd{bisect} ejecuta crece logarítmicamente con
igor@398 674 la cantidad de conjuntos de cambios a buscar, la ventaja que esto
igor@398 675 tiene frente a la búsqueda por``fuerza bruta'' crece con cada
igor@398 676 conjunto de cambios que usted adicione.
igor@398 677
igor@398 678 \subsection{Limpieza después de la búsqueda}
igor@398 679
igor@398 680 Cuando haya terminado de usar la orden \hgcmd{bisect} en un
igor@398 681 repositorio, puede usar la orden \hgcmdargs{bisect}{reset} para
igor@398 682 deshacerse de la información que se estaba usando para lograr la
igor@398 683 búsqueda. Lar orden no usa mucho espacio, así que no hay problema si
igor@398 684 olvida ejecutar la orden. En todo caso, \hgcmd{bisect} no le
igor@398 685 permitirá comenzar una nueva búsqueda sobre el repositorio hasta que
igor@398 686 no aplique \hgcmdargs{bisect}{reset}.
jerojasro@343 687 \interaction{bisect.search.reset}
jerojasro@343 688
igor@401 689 \section{Consejos para encontrar fallos efectivamente}
igor@401 690
igor@401 691 \subsection{Dar una entrada consistente}
igor@401 692
igor@401 693 La orden \hgcmd{bisect} requiere que usted ofrezca un reporte correcto
igor@401 694 del resultado de cada prueba que aplique. Si usted le dice que una
igor@401 695 prueba falla cuando en realidad era acertada, \emph{podría} detectar
igor@401 696 la inconsistencia. Si puede identificar una inconsistencia en sus
igor@401 697 reportes, le dirá que un conjunto de cambios particular es a la vez
igor@401 698 bueno y malo. Aunque puede no hacerlo; estaría tratando de reportar
igor@401 699 un conjunto de cambios como el responsable de un fallo aunque no lo
igor@401 700 sea.
igor@401 701
igor@401 702 \subsection{Automatizar tanto como se pueda}
igor@401 703
igor@401 704 Cuando comencé a usar la orden \hgcmd{bisect}, intenté ejecutar
igor@401 705 algunas veces las pruebas a mano desde la línea de comandos. Es una
igor@401 706 aproximación a la cual no esta acostumbrado. Después de algunos
igor@401 707 intentos, me di cuenta que estaba cometiendo tantas equivocaciones que
igor@401 708 tenía que comenzar de nuevo con mis búsquedas varias veces antes de
igor@401 709 llegar a los resultados deseados.
igor@401 710
igor@401 711 Mi problema inicial al dirigir a la orden \hgcmd{bisect} manualmente
igor@401 712 ocurrieron incluso con búsquedas en repositorios pequeños; si el
igor@401 713 problema que está buscando es más sutil, o el número de pruebas que
igor@401 714 \hgcmd{bisect} debe aplicar, la posibilidad de errar es mucho más
igor@401 715 alta. Una vez que comencé a automatizar mis pruebas, obtuve mejores
igor@401 716 resultados.
igor@401 717
igor@401 718 La clave para las pruebas automatizadas se puede resumir en:
jerojasro@343 719 \begin{itemize}
igor@401 720 \item pruebe siempre buscando el mismo síntoma y
igor@401 721 \item ofrezca siempre datos consistentes a la orden \hgcmd{bisect}.
jerojasro@343 722 \end{itemize}
igor@401 723 En mi tutorial de ejemplo anterior, la orden \command{grep} busca el
igor@401 724 síntoma, y la construcción \texttt{if} toma el resultado de esta
igor@401 725 prueba y verifica que siempre alimentamos con los mismos datos a la
igor@401 726 orden \hgcmd{bisect}. La función \texttt{mytest} los une de una forma
igor@401 727 reproducible, logrando que cada prueba sea uniforme y consistente.
igor@401 728
igor@401 729 \subsection{Verificar los resultados}
igor@401 730
igor@401 731 Dado que la salida de la búsqueda de \hgcmd{bisect} es tan buena como
igor@401 732 los datos ofrecidos por usted, no confíe en esto como si fuera la
igor@401 733 verdad absoluta. Una forma sencilla de asegurarse es ejecutar
igor@401 734 manualmente su prueba a cada uno de los siguientes conjuntos de
igor@401 735 cambios:
jerojasro@343 736 \begin{itemize}
igor@401 737 \item El conjunto de cambios que se reportó como la primera versión
igor@401 738 erronea. Su prueba debería dar un reporte de fallo.
igor@401 739 \item El conjunto de cambios padre (cada padre, si es una fusión).
igor@401 740 Su prueba debería reportar este(os) conjunto(s) de cambios como
igor@401 741 bueno(s).
igor@401 742 \item Un hijo del conjunto de cambios. Su prueba debería reportar al
igor@401 743 conjunto de cambios hijo como malo.
jerojasro@343 744 \end{itemize}
jerojasro@343 745
igor@401 746 \subsection{Tener en cuenta la interferencia entre fallos}
igor@401 747
igor@401 748 Es posible que su búsqueda de un fallo pueda viciarse por la presencia
igor@401 749 de otro. Por ejemplo, digamos que su programa se revienta en la
igor@401 750 revisión 100, y que funcionó correctamente en la revisión 50. Sin su
igor@401 751 conocimiento, alguien introdujo un fallo con consecuencias grandes en
igor@401 752 la revisión 60, y lo arregló en la revisión 80. Sus resultados
igor@401 753 estarían distorcionados de una o muchas formas.
igor@401 754
igor@401 755 Es posible que este fallo ``enmascare'' completamente al suyo, y que
igor@401 756 podría haberse revelado antes de que su propio fallo haya tenido
jerojasro@520 757 oportunidad de manifestarse. Si no puede saltar el otro fallo (por
igor@401 758 ejemplo, este evita que su proyecto se arme o compile), y de esta
igor@401 759 forma no se pueda revisar si su fallo esté presente en un conjunto
igor@401 760 particular de cambios, la orden \hgcmd{bisect} no podrá ayudarle
igor@401 761 directamente. En cambio, puede marcar este conjunto de cambios como
igor@401 762 al ejecutar \hgcmdargs{bisect}{--skip}.
igor@401 763
igor@401 764 Un problema distinto podría surgir si su prueba de la presencia de un
igor@401 765 fallo no es suficientemente específica. Si usted busca ``mi programa
igor@401 766 se revienta'', entonces tanto su fallo como el otro fallo sin relación
igor@401 767 que terminan presentando síntomas distintos, podría terminar
igor@401 768 confundiendo a \hgcmd{bisect}.
igor@401 769
igor@401 770 Otra situación en la cual sería de mucha utilidad emplear a
igor@401 771 \hgcmdargs{bisect}{--skip} surge cuando usted no puede probar una
igor@401 772 revisión porque su proyecto estaba en una situación de rompimiento y
igor@401 773 por lo tanto en un estado en el cual era imposible hacer la prueba en
igor@401 774 esa revisión, tal vez porque alguien consignó un cambio que hacía
igor@401 775 imposible la construcción del proyecto.
igor@401 776
igor@401 777 \subsection{Acotar la búsqueda perezosamente}
igor@401 778
igor@401 779 Elegir los primeros ``buenos'' y ``malos'' conjuntos de cambios que
igor@401 780 marcarán los límites de su búsqueda en general es sencillo, pero vale
igor@401 781 la pena discutirlo. Desde la perspectiva de \hgcmd{bisect}, el
igor@401 782 conjunto de cambios ``más nuevo'' por convención es el ``malo'', y el
igor@401 783 otro conjunto de cambios es el ``bueno''.
igor@401 784
igor@401 785 Si no recuerda cuál podría ser el cambio ``bueno'', para informar a
igor@401 786 \hgcmd{bisect}, podría hacer pruebas aleatorias en el peor de los
igor@401 787 casos. Pero recuerde eliminar aquellos conjuntos de cambios que
jerojasro@520 788 podrían no exhibir el fallo (tal vez porque la característica donde se
igor@401 789 presenta el fallo todavía no está presente) y aquellos en los cuales
jerojasro@520 790 otro fallo puede enmascararlo (como se discutió anteriormente).
igor@401 791
igor@401 792 Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
jerojasro@516 793 meses de historial, solamente estaŕa adicionando unas pruebas contadas
igor@401 794 para \hgcmd{bisect}, gracias al comportamiento logarítmico.
jerojasro@343 795
jerojasro@343 796 %%% Local Variables:
jerojasro@343 797 %%% mode: latex
jerojasro@343 798 %%% TeX-master: "00book"
jerojasro@343 799 %%% End: