hgbook
view es/daily.tex @ 536:2c2850e1e9a1
more revision; reordered files on Leame.1st
| author | Javier Rojas <jerojasro@devnull.li> |
|---|---|
| date | Sun Jan 25 21:21:59 2009 -0500 (2009-01-25) |
| parents | dce8441ee954 |
| children | ddbb28cd940a |
line source
1 \chapter{Mercurial día a día}
2 \label{chap:daily}
4 \section{Cómo indicarle a Mercurial qué ficheros seguir}
6 Mercurial no trabaja con ficheros en su repositorio a menos que usted
7 se lo indique explícitamente. La orden \hgcmd{status} le mostrará
8 cuáles ficheros son desconocidos para Mercurial; se emplea un
9 ``\texttt{?}'' para mostrar tales ficheros.
11 Para indicarle a Mercurial que tenga en cuenta un fichero, emplee la
12 orden \hgcmd{add}. Una vez que haya adicionado el fichero, la línea
13 referente al fichero al aplicar la orden \hgcmd{status} para tal
14 fichero cambia de ``\texttt{?}'' a ``\texttt{A}''.
15 \interaction{daily.files.add}
17 Después de invocar \hgcmd{commit}, los ficheros que haya adicionado
18 antes de consignar no se listarán en la salida de \hgcmd{status}. La
19 razón para esto es que \hgcmd{status} solamente le muestra aquellos
20 ficheros ``interesantes''---los que usted haya modificado o a aquellos
21 sobre los que usted haya indicado a Mercurial hacer algo---de forma
22 predeterminada. Si tiene un repositorio que contiene miles de
23 ficheros, rara vez deseará saber cuáles de ellos están siendo
24 seguidos por Mercurial, pero que no han cambiado. (De todas maneras,
25 puede obtener tal información; más adelante hablaremos de ello.)
28 Cuando usted añade un fichero, Mercurial no hace nada con él inmediatamente.
29 En cambio, tomará una instantánea del estado del fichero la próxima vez
30 que usted consigne. Continuará haciendo seguimiento a los cambios que
31 haga sobre el fichero cada vez que consigne, hasta que usted lo elimine.
33 \subsection{Nombramiento explícito e implícito de ficheros}
35 Mercurial tiene un comportamiento útil en el cual si a una orden,
36 le pasa el nombre de un directorio, todas las órdenes lo interpretarán como
37 ``Deseo operar en cada fichero de este directorio y sus
38 subdirectorios''.
39 \interaction{daily.files.add-dir}
40 Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de
41 los ficheros que se adicionaron, mientras que no lo hizo en el ejemplo
42 anterior cuando adicionamos el fichero con nombre \filename{a}.
44 En el último caso hicimos explícito el nombre del fichero que
45 deseábamos adicionar en la línea de órdenes, y Mercurial asume en
46 tales casos que usted sabe lo que está haciendo y no imprime
47 información alguna.
49 Cuando hacemos \emph{implícitos} los nombres de los ficheros dando el
50 nombre de un directorio, Mercurial da el paso extra de imprimir
51 el nombre de cada fichero con el que va a hacer algo. Esto para
52 aclarar lo que está sucediendo, y reducir en lo posible una sorpresa
53 silenciosa pero fatal. Este comportamiento es común a la mayoría de
54 órdenes en Mercurial.
56 \subsection{Nota al margen: Mercurial trata ficheros, no directorios}
58 Mercurial no da seguimiento a la información de los directorios. En
59 lugar de eso tiene en cuenta las rutas de los ficheros. Antes de
60 crear un fichero, primero crea todos los directorios que hagan falta
61 para completar la ruta del fichero. Después de borrar un fichero,
62 borra todos los directorios vacíos que estuvieran en la ruta del
63 fichero borrado. Suena como una diferencia trivial, pero tiene una
64 consecuencia práctica menor: no es posible representar un directorio
65 completamente vacío en Mercurial.
67 Los directorios vacíos rara vez son útiles, y hay soluciones
68 alternativas no intrusivas que usted puede emplear para obtener el efecto
69 apropiado. Los desarrolladores de Mercurial pensaron que la
70 complejidad necesaria para administrar directorios vacíos no valía la
71 pena frente al beneficio limitado que esta característica podría traer.
73 Si necesita un directorio vacío en su repositorio, hay algunas formas
74 de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a
75 un fichero ``oculto'' dentro de ese directorio. En sistemas tipo
76 Unix, cualquier fichero cuyo nombre comience con un punto
77 (``\texttt{.}'') es tratado como oculto por la mayoría de
78 comandos y herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}.
80 \begin{figure}[ht]
81 \interaction{daily.files.hidden}
82 \caption{Simular un directorio vacío con un fichero oculto}
83 \label{ex:daily:hidden}
84 \end{figure}
86 Otra forma de abordar la necesidad de un directorio vacío es
87 simplemente crear uno en sus guiones de construcción antes de que lo
88 necesiten.
90 \section{Cómo dejar de hacer seguimiento a un fichero}
92 Si decide que un fichero no pertenece a su repositorio, use la orden
93 \hgcmd{remove}; se borrará el fichero y le indicará a Mercurial que
94 deje de hacerle seguimiento. Los ficheros eliminados se representan
95 con ``\texttt{R}'' al usar \hgcmd{status}.
96 \interaction{daily.files.remove}
98 Después de hacer \hgcmd{remove} a un fichero, Mercurial dejará de
99 hacer seguimiento al mismo, incluso si recrea el fichero con el mismo
100 nombre en su directorio de trabajo. Si decide recrear un fichero con
101 el mismo nombre y desea que Mercurial le haga seguimiento, basta con
102 hacerle \hgcmd{add}. Mercurial sabrá que el fichero recientemente
103 adicionado no está relacionado con el fichero anterior que tenía el
104 mismo nombre.
106 \subsection{Al eliminar un fichero no se afecta su historial}
108 Es preciso tener en cuenta que eliminar un fichero tiene sólo dos
109 efectos.
110 \begin{itemize}
111 \item Se elimina la versión actual del fichero del directorio de
112 trabajo.
113 \item Mercurial deja de hacer seguimiento a los cambios del fichero
114 desde la próxima consignación.
115 \end{itemize}
116 Al eliminar un fichero \emph{no} se altera de ninguna manera el
117 \emph{historial} del mismo.
119 Si actualiza su directorio de trabajo a un conjunto de cambios en el
120 cual el fichero que eliminó aún era tenido en cuenta, reaparecerá en
121 el directorio de trabajo, con los contenidos que este tenía cuando se
122 consignó tal conjunto de cambios. Si usted actualiza el directorio de
123 trabajo a un conjunto de cambios posterior en el cual el fichero había
124 sido eliminado, Mercurial lo eliminará de nuevo del directorio de
125 trabajo.
127 \subsection{Ficheros perdidos}
129 Mercurial considera como \emph{perdido} un fichero que usted borró,
130 pero para el que no se usó \hgcmd{remove}. Los ficheros perdidos se
131 representan con ``\texttt{!}'' al visualizar \hgcmd{status}.
132 Las órdenes de Mercurial generalmente no harán nada con los ficheros
133 perdidos.
134 \interaction{daily.files.missing}
136 Si su repositorio contiene un fichero que \hgcmd{status} reporta como
137 perdido, y desea que el mismo se vaya, se puede usar
138 \hgcmdargs{remove}{\hgopt{remove}{--after}} posteriormente para
139 indicarle a Mercurial que usted deseaba borrar tal fichero.
140 \interaction{daily.files.remove-after}
142 Por otro lado, si borró un fichero perdido por accidente, puede usar
143 \hgcmdargs{revert}{\emph{nombre de fichero}} para recuperar el
144 fichero. Reaparecerá, sin modificaciones.
145 \interaction{daily.files.recover-missing}
147 \subsection{Nota al margen: ¿Por qué decirle explícitamente a Mercurial
148 que elimine un fichero?}
149 %TODO Im here!!
151 Es posible que se haya preguntado por qué Mercurial exige que usted le
152 indique explícitamente que está borrando un fichero. Al principio del
153 desarrollo de Mercurial, este permitía que usted borrara el fichero
154 sin más; Mercurial se daría cuanta de la ausencia del fichero
155 automáticamente después de la ejecución de \hgcmd{commit}, y dejaba de
156 hacer seguimiento al fichero. En la práctica, resultaba muy sencillo
157 borrar un fichero accidentalmente sin darse cuenta.
159 \subsection{Atajo útil---agregar y eliminar ficheros en un solo paso}
161 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
162 los ficheros que no tienen seguimiento y marca los ficheros faltantes
163 como eliminados.
164 \interaction{daily.files.addremove}
165 La orden \hgcmd{commit} su puede usar con la opción \hgopt{commit}{-A}
166 que aplica el agregar-eliminar, seguido inmediatamente de una
167 consignación.
168 \interaction{daily.files.commit-addremove}
170 \section{Copiar ficheros}
172 Mercurial ofrece la orden \hgcmd{copy} para hacer una nueva copia de
173 un fichero. Cuando se copia un fichero con esta orden, Mercurial
174 lleva un registro indicando que el nuevo fichero es una copia del
175 fichero original. Trata de forma especial los ficheros copiados cuando
176 usted hace una fusión con el trabajo de alguien más.
178 \subsection{Resultados de copiar un fichero durante una fusión}
180 Durante una fusión los cambios ``siguen'' una copia. Para ilustrar
181 lo que esto significa, haremos un ejemplo. Comenzaremos con el mini
182 repositorio usual que contiene un solo fichero
183 \interaction{daily.copy.init}
184 Debemos trabajar algo en paralelo, de forma que tengamos algo para
185 fusionar. Aquí clonamos el repositorio.
186 \interaction{daily.copy.clone}
187 De vuelta en el repositorio, usemos la orden \hgcmd{copy} para hacer
188 una copia del primer fichero que creamos.
189 \interaction{daily.copy.copy}
191 Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce
192 como un fichero que se ha añadido normalmente.
193 \interaction{daily.copy.status}
194 Pero si usamos la opción \hgopt{status}{-C} de la orden \hgcmd{status},
195 imprimirá otra línea: el fichero \emph{desde} el cual fue copiado nuestro
196 fichero recién añadido.
197 \interaction{daily.copy.status-copy}
199 Ahora, en el repositorio que clonamos, hagamos un cambio en
200 paralelo. Adicionaremos una línea de contenido al fichero original que
201 creamos.
202 \interaction{daily.copy.other}
203 Hemos modificado el fichero \filename{file} en este
204 repositorio. Cuando jalemos los cambios del primer repositorio y
205 fusionemos las dos cabezas, Mercurial propagará los cambios que hemos
206 hecho localmente en \filename{file} a su copia, \filename{new-file}.
207 \interaction{daily.copy.merge}
209 \subsection{¿Por qué los cambios se reflejan en las copias?}
210 \label{sec:daily:why-copy}
212 Este comportamiento de cambios en ficheros que se propagan a las
213 copias de los ficheros parecería esotérico, pero en la mayoría de
214 casos es absolutamente deseable.
216 Es indispensable recordar que esta propagación \emph{solamente} sucede
217 cuando fusionamos. Por lo tanto si sobre un fichero se usa
218 \hgcmd{copy}, y se modifica el fichero original durante el curso
219 normal de su trabajo, nada pasará.
221 Lo segundo a tener en cuenta es que las modificaciones solamente se
222 propagarán en las copias únicamente si los repositorios de los cuales
223 está jalando los cambios \emph{no saben} de la copia.
225 Explicaremos a continuación la razón de este comportamiento de
226 Mercurial. Digamos que yo he aplicado un arreglo de un fallo importante a un
227 fichero fuente y consigné los cambios. Por otro lado, usted decidió hacer
228 \hgcmd{copy} sobre el fichero en su repositorio, sin saber acerca del
229 fallo o sin ver el arreglo, y ha comenzado a trabajar sobre su copia
230 del fichero.
232 Si jala y fusiona mis cambios y Mercurial \emph{no hubiera} propagado
233 los cambios en las copias, su fichero fuente tendría el fallo, a menos
234 que usted haya recordado propagar el arreglo del fallo a mano, el
235 mismo \emph{permanecería} en su copia del fichero.
237 Mercurial previene esta clase de problemas, gracias a la propagación
238 automática del cambio que arregló el fallo del fichero original. Hasta
239 donde sé, Mercurial es el \emph{único} sistema de control de
240 revisiones que propaga los cambios en las copias de esta forma.
242 Cuando su historial de cambios tiene un registro de la copia y la
243 subsecuente fusión, usualmente no es necesario propagar los cambios el
244 fichero original a las copias del mismo, y por esta razón Mercurial
245 propaga únicamente los cambios en las copias hasta este punto y no más
246 allá.
249 \subsection{Cómo hacer que los cambios \emph{no} sigan a la copia?}
251 Si por algún motivo usted decide que esta característica de
252 propagación automática de cambios en las copias no es para usted, use
253 la orden usual de sus sistema para copiar ficheros (En sistemas tipo
254 Unix, es \command{cp}), posteriormente use \hgcmd{add} sobre la nueva
255 copia hecha a mano. Antes de hacerlo, de todas maneras, relea la
256 sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que
257 este comportamiento no es el apropiado para su caso específico.
259 \subsection{Comportamiento de la orden \hgcmd{copy}}
261 Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
262 fichero fuente del directorio actual. Esto significa que si usted hace
263 modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber
264 consignado primero los cambios, la nueva copia contendrá también las
265 modificaciones que haya hecho hasta ese punto. (Este comportamiento me
266 parece poco intuitivo, y por tal motivo lo menciono.)
268 La orden \hgcmd{copy} actúa de forma parecida a la orden \command{cp}
269 de Unix (puede usar el alias \hgcmd{cp} si le es más cómodo). El
270 último argumento es el \emph{destino}, y todos los argumentos previos
271 son las \emph{fuentes}. Si solamente indica un fichero como la
272 fuente, y el destino no existe, se crea un fichero nuevo con ese nombre.
273 \interaction{daily.copy.simple}
274 Si el destino es un directorio, Mercurial copia las fuentes en este.
275 \interaction{daily.copy.dir-dest}
276 La copia de un directorio es recursiva, y preserva la estructura del
277 directorio fuente.
278 \interaction{daily.copy.dir-src}
279 Si tanto la fuente como el destino son directorios, la estructura de
280 la fuente se recrea en el directorio destino.
281 \interaction{daily.copy.dir-src-dest}
283 De la misma forma como la orden \hgcmd{rename}, si copia un fichero
284 manualmente y desea que Mercurial sepa que ha copiado un fichero,
285 basta con aplicar la opción \hgopt{copy}{--after} a la orden
286 \hgcmd{copy}.
287 \interaction{daily.copy.after}
289 \section{Renombrar ficheros}
291 La necesidad de renombrar un fichero es más común que hacer una copia
292 del fichero. La razón por la cual discutí la orden \hgcmd{copy} antes
293 de hablar acerca de cambiar el nombre de los ficheros, es que
294 Mercurial trata el renombrar un fichero de la misma forma que una
295 copia. Por lo tanto, saber lo que hace Mercurial cuando usted copia
296 un fichero, le indica qué esperar cuando renombra un fichero.
298 Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada
299 fichero fuente, lo borra y lo marca como fichero eliminado.
300 \interaction{daily.rename.rename}
301 La orden \hgcmd{status} muestra la nueva copia del fichero como
302 añadido y el fichero inicial de la copia, como eliminado.
303 \interaction{daily.rename.status}
304 De la misma forma como se usa la orden \hgcmd{copy}, debemos usar la
305 opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar
306 que el fichero añadido realmente comienza a ser seguido por Mercurial
307 como una copia del fichero original, ahora eliminado.
308 \interaction{daily.rename.status-copy}
310 Igual que con \hgcmd{remove} y \hgcmd{copy}, puede indicársele a
311 Mercurial acerca de un renombramiento inmediato con la opción
312 \hgopt{rename}{--after}. El comportamiento de la orden
313 \hgcmd{rename} y las opciones que acepta, son similares a la orden
314 \hgcmd{copy} en casi todo.
316 \subsection{Renombrar ficheros y fusionar cambios}
318 Dado que el renombrar de Mercurial se implementa como un
319 copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted
320 fusiona después de renombrar como después de hacer una copia.
322 Si Yo modifico un fichero y usted lo renombra a un nuevo fichero, y
323 posteriormente fusionamos nuestros cambios respectivos, mi
324 modificación al fichero bajo su nombre original se propagará en el
325 fichero con el nuevo nombre. (Es lo que se esperaría como ``lo hace,''
326 pero, no todos los sistemas de control de revisiones lo logran.)
328 El hecho de que los cambios sigan la copia es una característica que
329 puede subestimar diciendo ``si, puede ser útil,'' debería ser claro
330 que el seguimiento de cambios de un renombramiento es importante
331 definitivamente. Sin esto, sería muy sencillo que los cambios se
332 volvieran huérfanos cuando los ficheros se renombran.
334 \subsection{Cambios de nombre divergentes y fusión}
336 El caso de renombramiento con nombres divergentes ocurre cuando dos
337 desarrolladores comienzan con un fichero---llamémoslo
338 \filename{foo}---en sus repositorios respectivos.
340 \interaction{rename.divergent.clone}
341 Ana renombra el fichero a \filename{bar}.
342 \interaction{rename.divergent.rename.anne}
343 Mientras que Roberto lo renombra como \filename{quux}.
344 \interaction{rename.divergent.rename.bob}
346 Veo esto como un conflicto porque cada desarrollador ha expresado
347 intenciones diferentes acerca de cómo considera debería haberse
348 renombrado el fichero.
350 ¿Qué cree que debería pasar cuando fusionen su trabajo?
351 El comportamiento de Mercurial es que siempre preserva \emph{ambos}
352 nombres cuando fusiona los conjuntos de cambios que contienen nombres
353 divergentes.
354 \interaction{rename.divergent.merge}
356 Tenga en cuenta que Mercurial le advierte acerca de nombres
357 divergentes, pero deja que usted decida qué hacer con la divergencia
358 después de la fusión.
360 \subsection{Cambios de nombre convergentes y fusión}
362 Otra clase de conflicto al cambiar el nombre ocurre cuando dos
363 personas eligen renombrar diferentes ficheros \emph{fuente} al mismo
364 \emph{destino}. En este caso Mercurial aplica su maquinaria de fusión
365 usual, y le permite a usted guiarlo a una solución adecuada.
367 \subsection{Otros casos límites relacionados con renombramientos}
369 Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
370 fusionar cuando por un lado hay un fichero con un nombre dado,
371 mientras que en otro hay un directorio con el mismo nombre. Esto está
372 documentado como~\bug{29}.
373 \interaction{issue29.go}
375 \section{Recuperarse de equivocaciones}
377 Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse
378 de equivocaciones comunes.
380 La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
381 su directorio de trabajo. Por ejemplo, Si aplicó \hgcmd{add} a un
382 fichero por accidente, ejecute \hgcmd{revert} con el nombre del
383 fichero que añadió, y en tanto que el fichero no haya sido tocado de
384 forma alguna, no será adicionado, ni seguido por Mercurial. También
385 puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
386 fichero.
388 Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no
389 han sido consignados. Cuando haya consignado un cambio, si decide que
390 era un error, puede hacer algo todavía, pero sus opciones pueden ser
391 más limitadas.
393 Para obtener información acerca de la orden \hgcmd{revert} y detalles
394 de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}.
396 %%% Local Variables:
397 %%% mode: latex
398 %%% TeX-master: "00book"
399 %%% End: