| rev |
line source |
|
jerojasro@515
|
1 %% vim: tw=70 encoding=utf8
|
|
jerojasro@515
|
2 \chapter{Administración de versiones y desarrollo ramificado}
|
|
igor@324
|
3 \label{chap:branch}
|
|
igor@324
|
4
|
|
jerojasro@531
|
5 Mercurial ofrece varios mecanismos que le permiten administrar un
|
|
igor@324
|
6 proyecto que avanza en múltiples frentes simultáneamente. Para
|
|
igor@324
|
7 entender estos mecanismos, demos un vistazo a la estructura usual de
|
|
igor@324
|
8 un proyecto de software.
|
|
igor@324
|
9
|
|
jerojasro@515
|
10 Muchos proyectos de software liberan una versión ``mayor'' que contiene
|
|
igor@324
|
11 nuevas características substanciales. En paralelo, pueden liberar
|
|
jerojasro@515
|
12 versiones ``menores''. Usualmente éstas son idénticas a las
|
|
jerojasro@515
|
13 versiones mayores en las cuales están basadas, pero con arreglos para
|
|
igor@324
|
14 algunos fallos.
|
|
igor@324
|
15
|
|
igor@324
|
16 En este capítulo, comenzaremos hablando de cómo mantener registro de
|
|
jerojasro@532
|
17 etapas del proyecto como las liberaciones de una
|
|
igor@324
|
18 versión. Continuaremos hablando del flujo de trabajo entre las
|
|
jerojasro@532
|
19 diferentes fases de un proyecto, y cómo puede ayudar Mercurial a
|
|
jerojasro@532
|
20 aislar y administrar tal trabajo.
|
|
igor@324
|
21
|
|
igor@324
|
22 \section{Dar un nombre persistente a una revisión}
|
|
igor@324
|
23
|
|
jerojasro@532
|
24 Cuando usted decide otorgar a una revisión el nombre particular de una
|
|
jerojasro@515
|
25 ``versión'', es buena idea grabar la identidad de tal revisión.
|
|
jerojasro@515
|
26 Esto le permitirá reproducir dicha versión en una fecha posterior,
|
|
jerojasro@515
|
27 para cualquiera que sea el
|
|
jerojasro@515
|
28 propósito que se tenga en ese momento (reproducir un fallo, portar
|
|
igor@324
|
29 a una nueva plataforma, etc).
|
|
igor@324
|
30 \interaction{tag.init}
|
|
igor@324
|
31
|
|
igor@324
|
32 Mercurial le permite dar un nombre permanente a cualquier revisión
|
|
igor@324
|
33 usando la orden \hgcmd{tag}. Sin causa de sorpresa, esos nombres se llaman
|
|
jerojasro@515
|
34 ``tags'' (etiquetas).
|
|
igor@324
|
35 \interaction{tag.tag}
|
|
igor@324
|
36
|
|
jerojasro@515
|
37 Una etiqueta no es más que un ``nombre simbólico'' para una revisión. Las
|
|
jerojasro@515
|
38 etiquetas existen únicamente para su conveniencia, brindándole una forma
|
|
jerojasro@515
|
39 permanente y sencilla de referirse a una revisión; Mercurial no
|
|
jerojasro@515
|
40 interpreta de ninguna manera los nombres de las etiquetas que usted use.
|
|
jerojasro@515
|
41 Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más
|
|
jerojasro@515
|
42 allá de lo necesario para asegurar que una etiqueta pueda procesarse sin
|
|
jerojasro@515
|
43 ambigüedades. El nombre de una etiqueta no puede tener ninguno de los
|
|
jerojasro@515
|
44 siguientes caracteres:
|
|
igor@324
|
45 \begin{itemize}
|
|
igor@324
|
46 \item Dos puntos (ASCII 58, ``\texttt{:}'')
|
|
jerojasro@515
|
47 \item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'')
|
|
igor@324
|
48 \item Nueva línea (ASCII 10, ``\Verb+\n+'')
|
|
igor@324
|
49 \end{itemize}
|
|
igor@324
|
50
|
|
jerojasro@532
|
51 Puede usar la orden \hgcmd{tags} para ver las etiquetas presentes en
|
|
igor@324
|
52 su repositorio. Al desplegarse, cada revisión marcada se identifica
|
|
jerojasro@532
|
53 primero con su nombre, después con el número de revisión y finalmente con
|
|
igor@324
|
54 un hash único de la revisión.
|
|
igor@324
|
55 \interaction{tag.tags}
|
|
jerojasro@532
|
56 Note que \texttt{tip} aparece en en listado generado por \hgcmd{tags}. La etiqueta
|
|
jerojasro@519
|
57 \texttt{tip} es una etiqueta ``flotante'' especial, que identifica siempre
|
|
jerojasro@532
|
58 la revisión más reciente en el repositorio.
|
|
igor@324
|
59
|
|
jerojasro@515
|
60 Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
|
|
jerojasro@532
|
61 inverso, por número de revisión. Lo que significa usualmente que las
|
|
jerojasro@532
|
62 etiquetas más recientes se listan antes que las más antiguas. También
|
|
jerojasro@519
|
63 significa que la etiqueta \texttt{tip} siempre aparecerá como primera
|
|
jerojasro@519
|
64 etiqueta listada al desplegar la orden \hgcmd{tags}.
|
|
jerojasro@519
|
65
|
|
jerojasro@532
|
66 Cuando usted ejecuta \hgcmd{log}, si se muestra una revisión que tenga
|
|
jerojasro@532
|
67 etiquetas asociadas a ella, se imprimirán tales etiquetas.
|
|
igor@324
|
68 \interaction{tag.log}
|
|
igor@324
|
69
|
|
jerojasro@531
|
70 Siempre que requiera indicar un~ID de revisión a una orden de
|
|
jerojasro@519
|
71 Mercurial, aceptará un nombre de etiqueta en su lugar. Internamente,
|
|
jerojasro@531
|
72 Mercurial traducirá su nombre de etiqueta en el~ID de revisión
|
|
igor@324
|
73 correspondiente, y lo usará.
|
|
igor@324
|
74 \interaction{tag.log.v1.0}
|
|
igor@324
|
75
|
|
jerojasro@531
|
76 No hay límites en la cantidad de etiquetas por repositorio, o la cantidad
|
|
jerojasro@519
|
77 de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es
|
|
jerojasro@532
|
78 muy buena idea tener ``demasiadas'' (la cantidad variará de un
|
|
igor@330
|
79 proyecto a otro), debido a que la intención es ayudarle a encontrar
|
|
jerojasro@532
|
80 revisiones. Si tiene demasiadas etiquetas, la facilidad de usarlas
|
|
jerojasro@532
|
81 para identificar revisiones disminuirá rápidamente.
|
|
jerojasro@532
|
82
|
|
jerojasro@532
|
83 Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes, de pocos
|
|
jerojasro@519
|
84 días, es perfectamente razonable asignarle una etiqueta a cada una de
|
|
igor@330
|
85 ellas. Pero si tiene un sistema de construcción automática de binarios
|
|
igor@330
|
86 que asegura que cada revisión puede generarse limpiamente, estaría
|
|
jerojasro@519
|
87 introduciendo mucho ruido si se usara una etiqueta para cada generación
|
|
jerojasro@533
|
88 exitosa. Más bien, podría usar tags para generaciones fallidas
|
|
jerojasro@533
|
89 (\textexclamdown en
|
|
jerojasro@515
|
90 caso de que estas sean raras!), o simplemente evitar las etiquetas para
|
|
igor@330
|
91 llevar cuenta de la posibilidad de generación de binarios.
|
|
igor@330
|
92
|
|
igor@324
|
93
|
|
jerojasro@532
|
94 Si quiere eliminar una etiqueta que no desea, use
|
|
igor@324
|
95 \hgcmdargs{tag}{--remove}.
|
|
igor@324
|
96 \interaction{tag.remove}
|
|
jerojasro@532
|
97 También puede modificar una etiqueta en cualquier momento, para que
|
|
jerojasro@532
|
98 identifique una revisión distinta, simplemente usando una nueva orden
|
|
igor@331
|
99 \hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
|
|
jerojasro@532
|
100 Mercurial que \emph{realmente} desea actualizar la etiqueta.
|
|
igor@324
|
101 \interaction{tag.replace}
|
|
igor@331
|
102 De todas maneras habrá un registro permanente de la antigua identidad
|
|
jerojasro@532
|
103 de la etiqueta, pero Mercurial no la usará. Por lo tanto no hay
|
|
jerojasro@532
|
104 problema al marcar con una etiqueta una revisión incorrecta; lo único
|
|
jerojasro@532
|
105 que debe hacer es mover la etiqueta hacia la revisión correcta tan
|
|
jerojasro@532
|
106 pronto como localice el error.
|
|
igor@331
|
107
|
|
jerojasro@516
|
108 Mercurial almacena las etiquetas en un fichero controlado por revisiones en
|
|
jerojasro@516
|
109 su repositorio. Si ha creado etiquetas, las encontrará en un fichero
|
|
igor@331
|
110 llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag},
|
|
jerojasro@533
|
111 Mercurial modifica este fichero, y hace la consignación del cambio al
|
|
jerojasro@533
|
112 mismo automáticamente. Esto significa que cada vez que ejecuta
|
|
jerojasro@533
|
113 \hgcmd{tag}, verá un conjunto de cambios correspondiente en la salida
|
|
jerojasro@533
|
114 de \hgcmd{log}.
|
|
igor@324
|
115 \interaction{tag.tip}
|
|
igor@324
|
116
|
|
jerojasro@515
|
117 \subsection{Manejo de conflictos entre etiquetas durante una fusión}
|
|
igor@331
|
118
|
|
jerojasro@532
|
119 Usualmente no tendrá que preocuparse por el fichero \sfilename{.hgtags},
|
|
jerojasro@532
|
120 pero a veces hace su aparición durante una fusión. El formato del
|
|
jerojasro@516
|
121 fichero es sencillo: Consiste de una serie de líneas. Cada línea
|
|
jerojasro@532
|
122 comienza con un hash de conjunto de cambios, seguido por un espacio,
|
|
jerojasro@519
|
123 seguido por el nombre de una etiqueta.
|
|
igor@331
|
124
|
|
jerojasro@516
|
125 Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
|
|
igor@331
|
126 durante una fusión, hay un detalle para tener en cuenta al modificar
|
|
jerojasro@516
|
127 el fichero \sfilename{.hgtags}:
|
|
jerojasro@533
|
128 cuando Mercurial procesa las etiquetas en el repositorio, \emph{nunca}
|
|
jerojasro@516
|
129 lee la copia de trabajo del fichero \sfilename{.hgtags}. En cambio,
|
|
jerojasro@516
|
130 lee la versión \emph{consignada más reciente} del fichero.
|
|
igor@331
|
131
|
|
igor@331
|
132 Una consecuencia desafortunada de este diseño es que usted no puede
|
|
jerojasro@532
|
133 verificar que su fichero \sfilename{.hgtags} fusionado sea correcto hasta
|
|
jerojasro@531
|
134 \emph{después} de haber consignado un cambio. Así que si se
|
|
igor@331
|
135 encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
|
|
igor@331
|
136 fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
|
|
jerojasro@516
|
137 consignar. Si encuentra un error en el fichero \sfilename{.hgtags},
|
|
jerojasro@532
|
138 la orden reportará el lugar del error, que podrá arreglar y después
|
|
igor@331
|
139 consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
|
|
jerojasro@532
|
140 asegurarse de que su arreglo fue aplicado correctamente .
|
|
jerojasro@532
|
141
|
|
jerojasro@532
|
142 \subsection{Etiquetas y clonado}
|
|
igor@331
|
143
|
|
igor@331
|
144 Puede haber notado que la orden \hgcmd{clone} tiene la opción
|
|
igor@331
|
145 \hgopt{clone}{-r} que le permite clonar una copia exacta del
|
|
igor@331
|
146 repositorio hasta un conjunto de cambios específico. El nuevo clon no
|
|
jerojasro@516
|
147 tendrá historial posterior a la revisión que usted haya
|
|
jerojasro@532
|
148 especificado. Esto tiene una interacción con etiquetas que puede
|
|
jerojasro@532
|
149 sorprender a los desprevenidos.
|
|
igor@331
|
150
|
|
jerojasro@519
|
151 Recuerde que una etiqueta se almacena como una revisión al fichero
|
|
jerojasro@532
|
152 \sfilename{.hgtags}, así que cuando usted crea una etiqueta, el
|
|
jerojasro@532
|
153 conjunto de cambios en el cual ésta se almacena necesariamente se
|
|
igor@331
|
154 refiere a un conjunto de cambios anterior. Cuando ejecuta
|
|
jerojasro@519
|
155 \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta la etiqueta
|
|
jerojasro@516
|
156 \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
|
|
jerojasro@519
|
157 la etiqueta} que usó para clonar el repositorio. El resultado es que tendrá
|
|
jerojasro@517
|
158 exactamente el subconjunto correcto del historial del proyecto en el
|
|
jerojasro@519
|
159 nuevo repositorio, pero, \emph{no} la etiqueta que podría haber esperado.
|
|
igor@331
|
160
|
|
jerojasro@515
|
161 \subsection{Cuando las etiquetas permanentes son demasiado}
|
|
jerojasro@515
|
162
|
|
jerojasro@515
|
163 Dado que las etiquetas de Mercurial están controladas por revisiones y se
|
|
jerojasro@516
|
164 llevan en el historial del proyecto, todas las personas involucradas
|
|
jerojasro@515
|
165 verán las etiquetas que usted haya creado. El hecho de dar nombres a las
|
|
igor@331
|
166 revisiones tiene usos más allá que simplemente hacer notar que la
|
|
igor@331
|
167 revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está
|
|
jerojasro@531
|
168 tratando de encontrar un fallo sutil, posiblemente desearía colocar una
|
|
jerojasro@533
|
169 etiqueta recordándole algo como ``Ana vio los síntomas en esta revisión''.
|
|
igor@331
|
170
|
|
jerojasro@534
|
171 Para estos casos, lo que usted posiblemente desearía serían etiquetas
|
|
jerojasro@534
|
172 \emph{locales}. Puede crear una etiqueta local con la opción~\hgopt{tag}{-l}
|
|
jerojasro@519
|
173 de la orden \hgcmd{tag}. Esto guardará la etiqueta en un fichero llamado
|
|
igor@331
|
174 \sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags},
|
|
igor@331
|
175 \sfilename{.hg/localtags} no está controlado por revisiones.
|
|
jerojasro@532
|
176 Cualquier etiqueta que usted cree usando \hgopt{tag}{-l} se mantendrá
|
|
jerojasro@534
|
177 local al repositorio en el que esté trabajando en ese momento.
|
|
igor@331
|
178
|
|
igor@331
|
179 \section{El flujo de cambios---El gran cuadro vs. el pequeño}
|
|
igor@331
|
180
|
|
igor@331
|
181 Retomando lo mencionado en el comienzo de un capítulo, pensemos en el
|
|
igor@331
|
182 hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
|
|
igor@331
|
183 en desarrollo al mismo tiempo.
|
|
igor@331
|
184
|
|
jerojasro@532
|
185 Puede haber prisa por una nueva versión ``principal''; una nueva
|
|
jerojasro@531
|
186 versión con un arreglo de fallo a la última versión; y una versión de
|
|
igor@331
|
187 ``mantenimiento correctivo'' a una versión antigua que ha entrado en
|
|
igor@331
|
188 modo de mantenimiento.
|
|
igor@331
|
189
|
|
igor@331
|
190 Usualmente la gente se refiere a esas direcciones
|
|
jerojasro@532
|
191 concurrentes de desarrollo como ``ramas''. Sin embargo, ya hemos visto que
|
|
jerojasro@532
|
192 en varias ocasiones Mercurial trata a \emph{todo el historial} como
|
|
igor@331
|
193 una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos
|
|
igor@331
|
194 ideas que se relacionan periféricamente, pero que en esencia comparten
|
|
igor@331
|
195 un nombre.
|
|
igor@324
|
196 \begin{itemize}
|
|
igor@331
|
197 \item ``El gran cuadro'' Las ramas representan un barrido de la
|
|
igor@331
|
198 evolución del proyecto; la gente les da nombres y hablan acerca de
|
|
igor@331
|
199 ellas en sus conversaciones.
|
|
igor@331
|
200 \item ``El cuadro pequeño'' Las ramas son artefactos de las
|
|
jerojasro@532
|
201 actividades diarias de desarrollar y fusionar cambios. Exponen la
|
|
igor@331
|
202 narrativa de cómo se desarrolló el código.
|
|
igor@324
|
203 \end{itemize}
|
|
igor@324
|
204
|
|
igor@337
|
205 \section{Administrar ramas en repositorios estilo gran cuadro}
|
|
igor@337
|
206
|
|
igor@337
|
207 En Mercurial la forma más sencilla de aislar una rama del ``gran
|
|
igor@337
|
208 cuadro'' es a través de un repositorio dedicado. Si cuenta con un
|
|
igor@337
|
209 repositorio compartido existente ---llamémoslo
|
|
igor@337
|
210 \texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a
|
|
igor@337
|
211 prepararse para versiones de mantenimiento futuras a partir de la
|
|
jerojasro@532
|
212 versión~1.0 marcando con una etiqueta la revisión con la cual preparó la versión~1.0.
|
|
igor@324
|
213 \interaction{branch-repo.tag}
|
|
igor@337
|
214 Ahora puede clonar un repositorio compartido nuevo
|
|
jerojasro@532
|
215 \texttt{myproject-1.0.1} con tal etiqueta.
|
|
igor@324
|
216 \interaction{branch-repo.clone}
|
|
igor@324
|
217
|
|
igor@337
|
218 Posteriormente, si alguien necesita trabajar en la reparación de un
|
|
igor@337
|
219 fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
|
|
igor@337
|
220 camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
|
|
jerojasro@532
|
221 harían sus cambios y los empujarían de vuelta.
|
|
igor@324
|
222 \interaction{branch-repo.bugfix}
|
|
igor@337
|
223 Mientras tanto, el desarrollo para la siguiente versión mayor puede
|
|
jerojasro@532
|
224 continuar aislado e incólume, en el repositorio \texttt{myproject}.
|
|
igor@324
|
225 \interaction{branch-repo.new}
|
|
igor@324
|
226
|
|
igor@342
|
227 \section{No repita trabajo: fusión entre ramas}
|
|
igor@342
|
228
|
|
igor@342
|
229 En muchos casos, cuando tiene un fallo para arreglar en una rama de
|
|
jerojasro@534
|
230 mantenimiento, es muy probable que el fallo también esté en la rama
|
|
jerojasro@521
|
231 principal (y posiblemente en otras ramas de mantenimiento
|
|
igor@342
|
232 también). Solamente un desarrollador extraño desearía corregir el
|
|
igor@342
|
233 mismo fallo muchas veces, por tanto, veremos varias alternativas con
|
|
igor@342
|
234 las que Mercurial puede ayudarle a administrar tales arreglos de fallo
|
|
igor@342
|
235 sin duplicar su trabajo.
|
|
igor@342
|
236
|
|
igor@342
|
237 En el caso más sencillo, basta con jalar los cambios de la rama de
|
|
jerojasro@531
|
238 mantenimiento a la rama objetivo en su clon local.
|
|
igor@324
|
239 \interaction{branch-repo.pull}
|
|
jerojasro@532
|
240 A continuación deberá mezclar las cabezas de las dos ramas, y empujar
|
|
igor@342
|
241 de nuevo a la rama principal.
|
|
igor@324
|
242 \interaction{branch-repo.merge}
|
|
igor@324
|
243
|
|
igor@342
|
244 \section{Nombrar ramas dentro de un repositorio}
|
|
igor@342
|
245
|
|
igor@342
|
246 La aproximación correcta en casi todas las oportunidades es aislar las
|
|
igor@342
|
247 ramas en los repositorios. Es fácil de entender gracias a su
|
|
jerojasro@532
|
248 simplicidad; y es difícil cometer errores. Hay una relación uno a uno
|
|
igor@342
|
249 entre las ramas y los directorios con los que está trabajando en su
|
|
jerojasro@532
|
250 sistema. Esto le permite usar emplear herramientas usuales (que no son
|
|
jerojasro@532
|
251 conscientes de Mercurial) para trabajar con los ficheros dentro de una
|
|
igor@342
|
252 rama/repositorio.
|
|
igor@342
|
253
|
|
igor@342
|
254 Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
|
|
igor@342
|
255 colaboradores también), puede considerar otra alternativa para
|
|
jerojasro@531
|
256 administrar las ramas. He mencionado con anterioridad la distinción a
|
|
igor@342
|
257 nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
|
|
igor@342
|
258 cuadro''. Mientras que Mercurial trabaja con muchas ramas del estilo
|
|
jerojasro@520
|
259 ``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando
|
|
igor@342
|
260 usted jala cambios, pero antes de fusionarlos), \emph{también} puede
|
|
igor@342
|
261 trabajar con varias ramas del ``cuadro grande''.
|
|
igor@342
|
262
|
|
igor@342
|
263 El truco para trabajar de esta forma en Mercurial se logra gracias a
|
|
igor@342
|
264 que puede asignar un \emph{nombre} persistente a una rama. Siempre
|
|
igor@342
|
265 existe una rama llamada \texttt{default}. Incluso antes de que
|
|
igor@342
|
266 empiece a nombrar ramas por su cuenta, puede encontrar indicios de la
|
|
igor@342
|
267 rama \texttt{default} si los busca.
|
|
igor@342
|
268
|
|
igor@342
|
269 Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su
|
|
igor@342
|
270 editor para introducir el mensaje de la consignación, busque la línea
|
|
igor@342
|
271 que contiene el texto ``\texttt{HG: branch default}'' al final. Le
|
|
igor@342
|
272 está indicando que su consignación ocurrirá en la rama llamada
|
|
igor@324
|
273 \texttt{default}.
|
|
igor@324
|
274
|
|
jerojasro@532
|
275 Use la orden \hgcmd{branches} para empezar a trabajar con ramas
|
|
igor@342
|
276 nombradas. Esta orden mostrará las ramas presentes en su repositorio,
|
|
jerojasro@532
|
277 indicándole qué conjunto de cambios es la punta de cada una.
|
|
igor@324
|
278 \interaction{branch-named.branches}
|
|
jerojasro@532
|
279 Dado que todavía no ha creado ramas nombradas, la única que verá será
|
|
igor@342
|
280 \texttt{default}.
|
|
igor@342
|
281
|
|
igor@342
|
282 Para hallar cuál es la rama ``actual'', invoque la orden
|
|
igor@342
|
283 \hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
|
|
jerojasro@532
|
284 encuentra el padre del conjunto de cambios actual.
|
|
igor@324
|
285 \interaction{branch-named.branch}
|
|
igor@324
|
286
|
|
igor@342
|
287 Para crear una nueva rama, invoque la orden \hgcmd{branch} de
|
|
igor@342
|
288 nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama
|
|
igor@342
|
289 que desea crear.
|
|
igor@324
|
290 \interaction{branch-named.create}
|
|
igor@324
|
291
|
|
igor@342
|
292 Después de crear la rama, usted podría desear ver el efecto que tuvo
|
|
igor@342
|
293 la orden \hgcmd{branch}. ¿Qué reportan las ordenes \hgcmd{status} y
|
|
jerojasro@532
|
294 \hgcmd{tip}?
|
|
igor@324
|
295 \interaction{branch-named.status}
|
|
jerojasro@516
|
296 Nada cambia en el directorio actual, y no se ha añadido nada al
|
|
jerojasro@516
|
297 historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
|
|
igor@342
|
298 un efecto permanente; solamente le indica a que nombre de rama usará
|
|
igor@342
|
299 la \emph{próxima} vez que consigne un conjunto de cambios.
|
|
igor@342
|
300
|
|
jerojasro@531
|
301 Cuando consigna un cambio, Mercurial almacena el nombre de la rama en
|
|
igor@342
|
302 la cual consignó. Una vez que haya cambiado de la rama \texttt{default}
|
|
igor@342
|
303 y haya consignado, verá que el nombre de la nueva rama se mostrará
|
|
igor@342
|
304 cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
|
|
igor@342
|
305 desplieguen la misma clase de información.
|
|
igor@324
|
306 \interaction{branch-named.commit}
|
|
igor@342
|
307 Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
|
|
jerojasro@532
|
308 cualquier conjunto de cambios que no esté en la rama
|
|
igor@342
|
309 \texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
|
|
igor@342
|
310 verá esta información.
|
|
igor@342
|
311
|
|
igor@342
|
312 Una vez que haya nombrado una rama y consignado un cambio con ese
|
|
igor@342
|
313 nombre, todas las consignaciones subsecuentes que desciendan de ese
|
|
igor@342
|
314 cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de
|
|
igor@342
|
315 una rama en cualquier momento con la orden \hgcmd{branch}.
|
|
igor@324
|
316 \interaction{branch-named.rebranch}
|
|
igor@342
|
317 Esto es algo que no hará muy seguido en la práctica, debido que los
|
|
igor@342
|
318 nombres de las ramas tienden a tener vidas largas. (Esto no es una
|
|
igor@342
|
319 regla, solamente una observación.)
|
|
igor@342
|
320
|
|
igor@342
|
321 \section{Tratamiento de varias ramas nombradas en un repositorio}
|
|
igor@342
|
322
|
|
igor@342
|
323 Si tiene más de una rama nombrada en un repositorio, Mercurial
|
|
igor@342
|
324 recordará la rama en la cual está su directorio de trabajo cuando
|
|
igor@342
|
325 invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}. Se
|
|
jerojasro@532
|
326 actualizará su directorio de trabajo actual a la punta de esta rama, sin
|
|
jerojasro@532
|
327 importar cuál sea la punta ``a lo largo del repositorio''. Para
|
|
jerojasro@531
|
328 actualizar a una revisión que está en una rama con distinto nombre,
|
|
igor@342
|
329 puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
|
|
igor@342
|
330
|
|
jerojasro@532
|
331 Este comportamiento puede ser sutil, así que veámoslo en acción. Primero,
|
|
igor@342
|
332 recordemos en qué rama estamos trabajando, y qué ramas están en
|
|
igor@342
|
333 nuestro repositorio.
|
|
igor@324
|
334 \interaction{branch-named.parents}
|
|
igor@342
|
335 Estamos en la rama \texttt{bar}, pero existe otra rama más antigua
|
|
igor@342
|
336 llamada \hgcmd{foo}.
|
|
igor@342
|
337
|
|
igor@342
|
338 Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
|
|
igor@342
|
339 y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
|
|
igor@342
|
340 puesto que esto solamente implica ir linealmente hacia adelante y
|
|
jerojasro@516
|
341 atrás en nuestro historial de cambios.
|
|
igor@324
|
342 \interaction{branch-named.update-switchy}
|
|
igor@324
|
343
|
|
igor@342
|
344 Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
|
|
jerojasro@532
|
345 nos mantendrá en \texttt{foo}, sin movernos a la punta de \texttt{bar}.
|
|
igor@342
|
346 \interaction{branch-named.update-nothing}
|
|
igor@342
|
347
|
|
igor@342
|
348 Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva
|
|
igor@342
|
349 cabeza.
|
|
igor@342
|
350 \interaction{branch-named.foo-commit}
|
|
igor@342
|
351
|
|
igor@342
|
352 \section{Nombres de ramas y fusiones}
|
|
igor@342
|
353
|
|
igor@342
|
354 Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
|
|
jerojasro@531
|
355 Supongamos que su repositorio tiene dos cabezas, 17 y 23. Si yo invoco
|
|
igor@342
|
356 \hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
|
|
igor@342
|
357 como el primer padre de la fusión, y 23 como el segundo. Mientras que
|
|
igor@342
|
358 si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
|
|
igor@342
|
359 grabará a 23 como el primer padre, y 17 como el segundo.
|
|
igor@342
|
360
|
|
jerojasro@533
|
361 Esto afecta el cómo elige Mercurial el nombre de la rama cuando usted
|
|
jerojasro@533
|
362 hace la fusión. Después de una fusión, Mercurial mantendrá el nombre de la
|
|
jerojasro@533
|
363 rama del primer padre cuando consigne el resultado de la fusión. Si
|
|
igor@342
|
364 el primer nombre de su padre es \texttt{foo}, y fusiona con
|
|
igor@342
|
365 \texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
|
|
igor@342
|
366 después de fusionar.
|
|
igor@342
|
367
|
|
igor@342
|
368 No es inusual que un repositorio contenga varias cabezas, cada una con
|
|
igor@342
|
369 el mismo nombre de rama. Digamos que estoy trabajando en la rama
|
|
jerojasro@533
|
370 \texttt{foo}, y usted también. Consignamos cambios distintos; yo jalo
|
|
igor@342
|
371 sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
|
|
igor@342
|
372 rama \texttt{foo}. El resultado de una fusión será una única cabeza
|
|
igor@342
|
373 en la rama \texttt{foo} como usted esperaría.
|
|
igor@342
|
374
|
|
igor@342
|
375 Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
|
|
jerojasro@533
|
376 de la rama \texttt{foo}, el resultado permanecerá en la rama
|
|
igor@324
|
377 \texttt{bar}.
|
|
igor@324
|
378 \interaction{branch-named.merge}
|
|
igor@324
|
379
|
|
jerojasro@531
|
380 En un ejemplo más concreto, si yo estoy trabajando en la rama
|
|
igor@342
|
381 \texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
|
|
igor@342
|
382 rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
|
|
igor@342
|
383 (\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.
|
|
igor@342
|
384
|
|
igor@342
|
385 \section{Normalmente es útil nombrar ramas}
|
|
igor@342
|
386
|
|
igor@342
|
387 No debería considerar que las ramas nombradas son aplicables
|
|
jerojasro@533
|
388 únicamente en situaciones con muchas ramas de larga vida cohabitando
|
|
igor@342
|
389 en un mismo repositorio. Son muy útiles incluso en los casos de
|
|
jerojasro@533
|
390 una rama por repositorio.
|
|
igor@342
|
391
|
|
igor@342
|
392 En el caso más sencillo, dar un nombre a cada rama ofrece un registro
|
|
igor@342
|
393 permanente acerca de en qué conjunto de cambios se generó la rama.
|
|
jerojasro@516
|
394 Esto le ofrece más contexto cuando esté tratando de seguir el
|
|
jerojasro@516
|
395 historial de un proyecto ramificado de larga vida.
|
|
igor@342
|
396
|
|
igor@342
|
397 Si está trabajando con repositorios compartidos, puede configurar el gancho
|
|
igor@342
|
398 \hook{pretxnchangegroup} para que cada uno bloquee los cambios con
|
|
igor@342
|
399 nombres de rama ``incorrectos'' que están por adicionarse. Este
|
|
jerojasro@533
|
400 provee una defensa sencilla, pero efectiva, para evitar que la gente
|
|
jerojasro@533
|
401 publique accidentalmente cambios de una rama ``super nueva'' a la rama
|
|
igor@342
|
402 ``estable''. Tal gancho podría verse de la siguiente forma dentro de
|
|
igor@342
|
403 un repositorio compartido de \hgrc.
|
|
igor@324
|
404 \begin{codesample2}
|
|
igor@324
|
405 [hooks]
|
|
igor@324
|
406 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
|
|
igor@324
|
407 \end{codesample2}
|
|
igor@324
|
408
|
|
igor@324
|
409 %%% Local Variables:
|
|
igor@324
|
410 %%% mode: latex
|
|
igor@324
|
411 %%% TeX-master: "00book"
|
|
igor@324
|
412 %%% End:
|
