hgbook
view es/daily.tex @ 1083:ef79008cda9e
2.4.1 first para
| author | Zhaoping Sun <zhaopingsun@gmail.com> |
|---|---|
| date | Fri Nov 20 23:00:06 2009 -0500 (2009-11-20) |
| parents | 193d107798cc |
| children |
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 efectúa 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 mismo. 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, éste 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?}
150 Es posible que se haya preguntado por qué Mercurial exige que usted le
151 indique explícitamente que está borrando un fichero. Al principio del
152 desarrollo de Mercurial, este permitía que usted borrara el fichero
153 sin más; Mercurial se daría cuenta de la ausencia del fichero
154 automáticamente después de la ejecución de \hgcmd{commit}, y dejaría de
155 hacer seguimiento al fichero. En la práctica, resultaba muy sencillo
156 borrar un fichero accidentalmente sin darse cuenta.
158 \subsection{Atajo útil---agregar y eliminar ficheros en un solo paso}
160 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
161 los ficheros que no tienen seguimiento y marca los ficheros faltantes
162 como eliminados.
163 \interaction{daily.files.addremove}
164 La orden \hgcmd{commit} se puede usar con la opción \hgopt{commit}{-A}
165 que aplica el mismo agregar-eliminar, seguido inmediatamente de una
166 consignación.
167 \interaction{daily.files.commit-addremove}
169 \section{Copiar ficheros}
171 Mercurial ofrece la orden \hgcmd{copy} para hacer una copia nueva de
172 un fichero. Cuando se copia un fichero con esta orden, Mercurial
173 lleva un registro indicando que el nuevo fichero es una copia del
174 fichero original. Los ficheros copiados se tratan de forma especial cuando
175 usted hace una fusión con el trabajo de alguien más.
177 \subsection{Resultados de copiar un fichero durante una fusión}
179 Durante una fusión los cambios ``siguen'' una copia. Para ilustrar
180 lo que esto significa, haremos un ejemplo. Comenzaremos con el mini
181 repositorio usual que contiene un solo fichero
182 \interaction{daily.copy.init}
183 Debemos hacer algo de trabajo en paralelo, de forma que tengamos algo para
184 fusionar. Aquí clonamos el repositorio.
185 \interaction{daily.copy.clone}
186 De vuelta en el repositorio inicial, usemos la orden \hgcmd{copy} para hacer
187 una copia del primer fichero que creamos.
188 \interaction{daily.copy.copy}
190 Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce
191 tal como un fichero que se ha añadido normalmente.
192 \interaction{daily.copy.status}
193 Pero si usamos la opción \hgopt{status}{-C} de la orden
194 \hgcmd{status}, se imprimirá otra línea: el fichero \emph{desde} el
195 cual fue copiado nuestro fichero recién añadido.
196 \interaction{daily.copy.status-copy}
198 Ahora, en el repositorio que clonamos, hagamos un cambio en
199 paralelo. Adicionaremos una línea de contenido al fichero original que
200 creamos.
201 \interaction{daily.copy.other}
202 Hemos modificado el fichero \filename{file} en este
203 repositorio. Cuando jalemos los cambios del primer repositorio y
204 fusionemos las dos cabezas, Mercurial propagará los cambios que hemos
205 hecho localmente en \filename{file} a su copia, \filename{new-file}.
206 \interaction{daily.copy.merge}
208 \subsection{¿Por qué los cambios se reflejan en las copias?}
209 \label{sec:daily:why-copy}
211 Este comportamiento de cambios en ficheros que se propagan a las
212 copias de los ficheros parecería esotérico, pero en la mayoría de
213 casos es absolutamente deseable.
214 Es indispensable recordar que esta propagación \emph{solamente} sucede
215 cuando fusionamos. Por lo tanto si sobre un fichero se usa
216 \hgcmd{copy}, y se modifica el fichero original durante el curso
217 normal de su trabajo, nada pasará.
219 Lo segundo a tener en cuenta es que las modificaciones solamente se
220 propagarán en las copias únicamente si los repositorios de los cuales
221 está jalando los cambios \emph{no saben} de la copia.
223 Explicaremos a continuación la razón de este comportamiento de
224 Mercurial. Digamos que yo he aplicado un arreglo de un fallo importante a un
225 fichero fuente y consigné los cambios. Por otro lado, usted decidió hacer
226 \hgcmd{copy} sobre el fichero en su repositorio, sin saber acerca del
227 fallo o sin ver el arreglo, y ha comenzado a trabajar sobre su copia
228 del fichero.
230 Si jala y fusiona mis cambios y Mercurial \emph{no hubiera} propagado
231 los cambios en las copias, su fichero fuente tendría el fallo, a menos
232 que usted haya recordado propagar el arreglo del fallo a mano, el
233 mismo \emph{permanecería} en su copia del fichero.
235 Mercurial previene esta clase de problemas, gracias a la propagación
236 automática del cambio que arregló el fallo del fichero original. Hasta
237 donde sé, Mercurial es el \emph{único} sistema de control de
238 revisiones que propaga los cambios en las copias de esta forma.
240 Cuando su historial de cambios tiene un registro de la copia y la
241 subsecuente fusión, usualmente no es necesario propagar los cambios el
242 fichero original a las copias del mismo, y por esta razón Mercurial
243 propaga únicamente los cambios en las copias hasta este punto y no más
244 allá.
247 \subsection{Cómo hacer que los cambios \emph{no} sigan a la copia?}
249 Si por algún motivo usted decide que esta característica de
250 propagación automática de cambios en las copias no es para usted,
251 simplemente use
252 la orden usual de su sistema para copiar ficheros (en sistemas tipo
253 Unix, es \command{cp}), y posteriormente use \hgcmd{add} sobre la nueva
254 copia hecha a mano. Antes de hacerlo, de todas maneras, relea la
255 sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que
256 este comportamiento no es el apropiado para su caso específico.
258 \subsection{Comportamiento de la orden \hgcmd{copy}}
260 Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
261 fichero fuente tal como se encuentra en el directorio actual. Esto
262 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 éste.
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 que 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 mismo. 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ñadida y el fichero inicial de la copia, como eliminado.
303 \interaction{daily.rename.status}
304 De la misma forma en que 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 renombrado 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 respectivos cambios, 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 que ``simplemente
326 funcione,''
327 pero, no todos los sistemas de control de revisiones hacen esto.)
329 Aunque el hecho de que los cambios sigan la copia es una característica
330 respecto a la cual usted puede estar de acuerdo y decir ``si, puede
331 ser útil,'' debería ser claro
332 que el seguimiento de cambios de un renombramiento es definitivamente
333 importante. Sin esto, sería muy sencillo que los cambios se
334 quedaran atrás cuando los ficheros se renombran.
336 \subsection{Cambios de nombre divergentes y fusión}
338 El caso de renombramiento con nombres divergentes ocurre cuando dos
339 desarrolladores comienzan con un fichero---llamémoslo
340 \filename{foo}---en sus repositorios respectivos.
342 \interaction{rename.divergent.clone}
343 %TODO we must either change the example's names, and these names, or
344 %use the original names. as of now, we keep the old names
345 Anne renombra el fichero a \filename{bar}.
346 \interaction{rename.divergent.rename.anne}
347 Mientras que Bob lo renombra como \filename{quux}.
348 \interaction{rename.divergent.rename.bob}
350 Veo esto como un conflicto porque cada desarrollador ha expresado
351 intenciones diferentes acerca de cómo considera debería haberse
352 nombrado el fichero.
354 ¿Qué cree que debería pasar cuando fusionen su trabajo?
355 El comportamiento de Mercurial es que siempre preserva \emph{ambos}
356 nombres cuando fusiona los conjuntos de cambios que contienen nombres
357 divergentes.
358 %TODO traducir texto interaccion
359 \interaction{rename.divergent.merge}
361 Tenga en cuenta que Mercurial le advierte acerca de nombres
362 divergentes, pero deja que usted decida qué hacer con la divergencia
363 después de la fusión.
365 \subsection{Cambios de nombre convergentes y fusión}
367 Otra clase de conflicto al cambiar el nombre de ficheros ocurre cuando dos
368 personas eligen renombrar diferentes ficheros \emph{fuente} al mismo
369 \emph{destino}. En este caso Mercurial aplica su maquinaria de fusión
370 usual, y le permite a usted guiar la situación a una resolución adecuada.
372 \subsection{Otros casos límite relacionados con renombramientos}
374 Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
375 fusionar cuando por un lado hay un fichero con un nombre dado,
376 mientras que en otro hay un directorio con el mismo nombre. Esto está
377 documentado como~\bug{29}.
378 \interaction{issue29.go}
380 \section{Recuperarse de equivocaciones}
382 Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse
383 de equivocaciones comunes.
385 La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
386 su directorio de trabajo. Por ejemplo, si aplicó \hgcmd{add} a un
387 fichero por accidente, ejecute \hgcmd{revert} con el nombre del
388 fichero que añadió, y en tanto que el fichero no haya sido tocado de
389 forma alguna, no será adicionado, ni seguido por Mercurial. También
390 puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
391 fichero.
393 Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no
394 han sido consignados. Cuando haya consignado un cambio, si decide que
395 era un error, puede hacer algo todavía, pero sus opciones pueden estar
396 más limitadas.
398 Para obtener información acerca de la orden \hgcmd{revert} y detalles
399 de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}.
401 %%% Local Variables:
402 %%% mode: latex
403 %%% TeX-master: "00book"
404 %%% End: