| 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
|
|
igor@374
|
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
|
|
igor@377
|
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@516
|
223 \hgcmd{backout} deshace cambios \emph{adicionando} a el 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
|
|
igor@387
|
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
|
|
igor@400
|
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
|
|
igor@397
|
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
|
|
igor@397
|
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
|
|
igor@401
|
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
|
|
igor@401
|
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
|
|
igor@401
|
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:
|
