hgbook
view es/daily.tex @ 380:1a4b507935de
began translation of tour-merge
| author | Javier Rojas <jerojasro@devnull.li> |
|---|---|
| date | Wed Oct 29 00:37:55 2008 -0500 (2008-10-29) |
| parents | 84944c0ecde6 |
| children | 93bd78a98b78 |
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 explícitamente se lo indique. La orden \hgcmd{status} le mostrará
8 cuáles ficheros son desconocidos para Mercurial; 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 hacerles algo---de forma
22 predeterminada. Si tiene un repositorio que contiene miles de
23 ficheros, inusualmente 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 A 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 explicíto 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 tratará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 efectua un paso extra al 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 son inusualmente útiles, hay soluciones
68 alternativas no intrusivas que 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 ``escondido'' dentro de ese directorio. En sistemas tipo
76 Unix, cualquier fichero cuyo nombre comience con un punto
77 (``\texttt{.}'') se trata como escondido por la mayoría de
78 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 escondido}
83 \label{ex:daily:hidden}
84 \end{figure}
86 Otra forma de abordar la necesidad de un fichero vacío es crear
87 simplemente uno en sus guiones de construcción antes de ser necesarios.
89 \section{Cómo dejar de hacer seguimiento a un fichero}
91 Si decide que un fichero no pertenece a su repositorio, use la orden
92 \hgcmd{remove}; se borrará el fichero y le indicará a Mercurial que
93 deje de hacerle seguimiento. Los ficheros eliminados se representan
94 con ``\texttt{R}'' al usar \hgcmd{status}.
95 \interaction{daily.files.remove}
97 Después de hacer \hgcmd{remove} a un fichero, Mercurial dejará de
98 hacer seguimiento al mismo, incluso si recrea el fichero con el mismo
99 nombre en su directorio de trabajo. Si decide recrear un fichero con
100 el mismo nombre y desea que Mercurial le haga seguimiento, basta con
101 hacerle \hgcmd{add}. Mercurial sabrá que el fichero recientemente
102 adicionado no está relacionado con el fichero anterior que tenía el
103 mismo nombre.
105 \subsection{Al eliminar un fichero no se afecta su historia}
107 Es preciso tener en cuenta que al eliminar un fichero se tiene
108 dos efectos solamente.
109 \begin{itemize}
110 \item Se elimina la versión actual del fichero del directorio de
111 trabajo.
112 \item Mercurial deja de hacer seguimiento a los cambios del fichero
113 desde la próxima consignación.
114 \end{itemize}
115 Al eliminar un fichero \emph{no} se altera de ninguna manera la
116 \emph{historia} del mismo.
118 Si actualiza su directorio de trabajo a un conjunto de cambios en el
119 cual esl fichero que eliminó aún era tenido en cuenta, reaparecerá en
120 el directorio de trabajo, con los contenidos que este tenía cuando se
121 consignó tal conjunto de cambios. Si usted actualiza el directorio de
122 trabajo a un conjunto de cambios posterior en el cual el fichero había
123 sido eliminado, Mercurial lo eliminará de nuevo del directorio de
124 trabajo.
126 \subsection{Ficheros perdidos}
128 Mercurial considera como \emph{perdido} un fichero que usted borró,
129 pero para el que no se usó \hgcmd{remove}. Los ficheros perdidos se
130 representan con ``\texttt{!}'' al visualizar \hgcmd{status}.
131 Las órdenes de Mercurial generalmente no harán nada con los ficheros
132 perdidos.
133 \interaction{daily.files.missing}
135 Si su repositorio contiene un fichero que \hgcmd{status} reporta como
136 perdido, y desea que el mismo se vaya, se puede usar
137 \hgcmdargs{remove}{\hgopt{remove}{--after}} posteriormente para
138 indicarle a Mercurial que usted deseaba borrar tal fichero.
139 \interaction{daily.files.remove-after}
141 Por otro lado, si borró un fichero perdido por accidente, puede usar
142 \hgcmdargs{revert}{\emph{nombre de fichero}} para recuperar el
143 fichero. Reaparecerá sin modificaciones.
144 \interaction{daily.files.recover-missing}
146 \subsection{Nota al margen: ¿Por qué decirle explícitamente a Mercurial
147 que elimine un fichero?}
149 Es posible que se haya preguntado por qué Mercurial exige que usted le
150 indique explícitamente que está borrando un fichero. Al principio del
151 desarrollo de Mercurial, este permitía que usted borrara el fichero
152 sin más; Mercurial se daría cuanta de la ausencia del fichero
153 automáticamente después de la ejecución de \hgcmd{commit}, y dejaba de
154 hacer seguimiento al fichero. En la práctica, resultaba muy sencillo
155 borrar un fichero accidentalmente sin darse cuenta.
157 \subsection{Atajo útil---agregar y eliminar ficheros en un solo paso}
159 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
160 los ficheros que no tienen seguimiento y marca los ficheros faltantes
161 como eliminados.
162 \interaction{daily.files.addremove}
163 La orden \hgcmd{commit} su puede usar con la opción \hgopt{commit}{-A}
164 que aplica el agregar-eliminar, seguido inmediatamente de una
165 consignación.
166 \interaction{daily.files.commit-addremove}
168 \section{Copiar ficheros}
170 Mercurial ofrece la orden \hgcmd{copy} para hacer una nueva copia de
171 un fichero. Cuando se copia un fichero con esta orden, Mercurial
172 lleva un registro indicando que el nuevo fichero es una copia del
173 fichero original. Trata de forma especial los ficheros copiados cuando
174 usted hace una fusión con el trabajo de alguien más.
176 \subsection{Resultados de copiar un fichero durante una fusión}
178 Durante una fusión lols cambios ``siguen'' una copia. Para ilustrar
179 lo que esto significa, haremos un ejemplo. Comenzaremos con el mini
180 repositorio usual que contiene un solo fichero
181 \interaction{daily.copy.init}
182 Debemos trabajar algo en paralelo, de forma que tengamos algo para
183 fusionar. Aquí clonamos el repositorio.
184 \interaction{daily.copy.clone}
185 De vuelta en el repositorio, usemos la orden \hgcmd{copy} para hacer
186 una copia del primer fichero que creamos.
187 \interaction{daily.copy.copy}
189 Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce
190 como un fichero que se ha añadido normalmente.
191 \interaction{daily.copy.status}
192 Si usamos la opción \hgopt{status}{-C} de la orden \hgcmd{status},
193 imprimirá otra línea: Ela fichero of output: this is the file that our newly-added
194 file was copied \emph{from}.
195 \interaction{daily.copy.status-copy}
197 Ahora, en el repositorio que clonamos, hagamos un cambio en
198 paralelo. Adicionaremos una línea de contenido al fichero original que
199 creamos.
200 \interaction{daily.copy.other}
201 Hemos modificado el fichero \filename{file} en este
202 repositorio. Cuando jalemos los cambios del primer repositorio y
203 fusionemos las dos cabezas, Mercurial propagará los cambios que hemos
204 hecho localmente en \filename{file} a su copia, \filename{new-file}.
205 \interaction{daily.copy.merge}
207 \subsection{¿Por qué los cambios se reflejan en las copias?}
208 \label{sec:daily:why-copy}
210 Este comportamiento de cambios en ficheros que se propagan a las
211 copias de los ficheros parecería esotérico, pero en la mayoría de
212 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 oficinal 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, use
251 la orden usual de sus sistema para copiar ficheros (En sistemas tipo
252 Unix, es \command{cp}), posteriormente use \hgcmd{add} sobre la nueva
253 copia hecha a mano. Antes de hacerlo, de todas maneras, relea la
254 sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que
255 este comportamiento no es el apropiado para su caso específico.
257 \subsection{Comportamiento de la orden \hgcmd{copy}}
259 Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
260 fichero fuente del directorio actual. Esto significa que si usted hace
261 modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber
262 consignado primero los cambios, la nueva copia contendrá también las
263 modificaciones que haya hecho hasta ese punto. (Este comportamiento me
264 parece poco intuitivo, y por tal motivo lo menciono.)
266 La orden \hgcmd{copy} actua de forma parecida a la orden \command{cp}
267 de Unix(puede usar el alias \hgcmd{cp} si le es más cómodo). El
268 último argumento es el \emph{destino}, y todos los argumentos previos
269 son las \emph{fuentes}. Si solamente indica un fichero como la
270 fuente, y el destino no existe, se crea un fichero nuevo con ese nombre.
271 \interaction{daily.copy.simple}
272 Si el destino es un directorio, Mercurial copia las fuentes en este.
273 \interaction{daily.copy.dir-dest}
274 La copia de un directorio es recursiva, y preserva la estructura del
275 directorio fuente.
276 \interaction{daily.copy.dir-src}
277 Si tanto la fuente como el destino son directorios, la estructura de
278 la fuente se recrea en el directorio destino.
279 \interaction{daily.copy.dir-src-dest}
281 De la misma forma como la orden \hgcmd{rename}, si copia un fichero
282 manualmente y desea que Mercurial sepa que ha copiado un fichero,
283 basta con aplicar la opción \hgopt{copy}{--after} a la orden
284 \hgcmd{copy}.
285 \interaction{daily.copy.after}
287 \section{Renombrar ficheros}
289 La necesidad de renombrar un fichero es más común que hacer una copia
290 del fichero. La razón por la cual discutí la orden \hgcmd{copy} antes
291 de hablar acerca de cambiar el nombre de los ficheros, es que
292 Mercurial trata el renombrar un fichero de la misma forma que una
293 copia. Por lo tanto, saber lo que hace Mercurial cuando usted copia
294 un fichero, le indica qué esperar cuando renombra un fichero.
296 Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada
297 fichero fuente, lo borra y lo marca como fichero eliminado.
298 \interaction{daily.rename.rename}
299 La orden \hgcmd{status} muestra la nueva copia del fichero como
300 añadido y el fichero inicial de la copia, como eliminado.
301 \interaction{daily.rename.status}
302 De la misma forma como se usa la orden \hgcmd{copy}, debemos usar la
303 opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar
304 que el fichero añadido realmente comienza a ser seguido por Mercurial
305 como una copia del fichero original, ahora eliminado.
306 \interaction{daily.rename.status-copy}
308 Igual que con \hgcmd{remove} y \hgcmd{copy}, puede indicársele a
309 Mercurial acerca de un renombramiento inmediato con la opción
310 \hgopt{rename}{--after}. El comportamiento de la orden
311 \hgcmd{rename} y las opciones que acepta, son similares a la orden
312 \hgcmd{copy} en casi todo.
314 \subsection{Renombrar ficheros y fusionar cambios}
316 Dado que el renombrar de Mercurial se implementa como un
317 copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted
318 fusiona después de renombrar como después de hacer una copia.
320 Si Yo modifico un fichero y usted lo renombra a un nuevo fichero, y
321 posteriormente fusionamos nuestros cambios respectivos, mi
322 modificación al fichero bajo su nombre original se propagará en el
323 fichero con el nuevo nombre. (Es lo que se esperaría como ``lo hace,''
324 pero, no todos los sistemas de control de revisiones lo logran.)
326 El hecho de que los cambios sigan la copia es una característica que
327 puede subestimar diciendo ``si, puede ser útil,'' debería ser claro
328 que el seguimiento de cambios de un renombramiento es importante
329 definitivamente. Sin esto, sería muy sencillo que los cambios se
330 volvieran huérfanos cuando los ficheros se renombran.
332 \subsection{Cambios de nombre divergentes y fusión}
334 El caso de renombramiento con nombres divergentes ocurre cuando dos
335 desarrolladores comienzan con un fichero---llamémoslo
336 \filename{foo}---en sus repositorios respectivos.
338 \interaction{rename.divergent.clone}
339 Ana renombra el fichero a \filename{bar}.
340 \interaction{rename.divergent.rename.anne}
341 Mientras que Roberto lo renombra como \filename{quux}.
342 \interaction{rename.divergent.rename.bob}
344 Veo esto como un conflicto porque cada desarrollador ha expresado
345 intenciones diferentes acerca de cómo considera debería haberse
346 renombrado el fichero.
348 ¿ué cree que debería pasar cuando fusionen su trabajo?
349 El comportamiento de Mercurial es que siempre preserva \emph{ambos}
350 nombres cuando fusiona los conjuntos de cambios que contienen nombres
351 divergentes.
352 \interaction{rename.divergent.merge}
354 Tenga en cuenta que Mercurial le advierte acerca de nombres
355 divergentes, pero deja que usted decida qué hacer con la divergencia
356 después de la fusión.
358 \subsection{Cambios de nombre convergentes y fusión}
360 Otra clase de conflicto al cambiar el nombre ocurre cuando dos
361 personas eligen renombrar diferentes ficheros \emph{fuente} al mismo
362 \emph{destino}. En este caso Mercurial aplica su maquinaria de fusión
363 usual, y le permite a usted guiarlo a una solución adecuada.
365 \subsection{Otros casos límites relacionados con renombramientos}
367 Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
368 fusionar cuando por un lado hay un fichero con un nombre dado,
369 mientras que en otro hay un directorio con el mismo nombre. Esto está
370 documentado como~\bug{29}.
371 \interaction{issue29.go}
373 \section{Recuperarse de equivocaciones}
375 Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse
376 de equivocaciones comunes.
378 La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
379 su directorio de trabajo. Por ejemplo, Si aplicó \hgcmd{add} a un
380 fichero por accidente, ejecute \hgcmd{revert} con el nombre del
381 fichero que añadió, y en tando que el fichero no haya sido tocado de
382 forma alguna, no será adicionado, ni seguido por Mercurial. También
383 puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
384 fichero.
386 Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no
387 han sido consignados. Cuando haya consignado un cambio, si decide que
388 era un error, puede hacer algo todavía, pero sus opciones pueden ser
389 más limitadas.
391 Para obtener información acerca de la orden \hgcmd{revert} y detalles
392 de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}.
394 %%% Local Variables:
395 %%% mode: latex
396 %%% TeX-master: "00book"
397 %%% End: