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