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
|
igor@345
|
7 explícitamente se lo indique. La orden \hgcmd{status} le mostrará
|
igor@359
|
8 cuáles ficheros son desconocidos para Mercurial; 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
|
igor@359
|
20 ficheros ``interesantes''---los que usted haya modificado o a aquellos
|
igor@345
|
21 sobre los que usted haya indicado a Mercurial hacerles algo---de forma
|
igor@345
|
22 predeterminada. Si tiene un repositorio que contiene miles de
|
igor@359
|
23 ficheros, inusualmente 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.
|
igor@359
|
29 A 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
|
igor@359
|
33 \subsection{Nombramiento explicíto e implícito de ficheros}
|
igor@345
|
34
|
igor@345
|
35 Mercurial tiene un comportamiento útil en el cual si a una orden,
|
igor@345
|
36 le pasa el nombre de un directorio, todas las órdenes lo tratará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
|
igor@345
|
50 nombre de un directorio, Mercurial efectua un paso extra al 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
|
igor@359
|
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
|
igor@359
|
61 para completar la ruta del fichero. 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
|
igor@345
|
67 Los directorios vacíos son inusualmente útiles, hay soluciones
|
igor@345
|
68 alternativas no intrusivas que 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
|
igor@359
|
75 un fichero ``escondido'' dentro de ese directorio. En sistemas tipo
|
igor@359
|
76 Unix, cualquier fichero cuyo nombre comience con un punto
|
igor@345
|
77 (``\texttt{.}'') se trata como escondido por la mayoría de
|
igor@345
|
78 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}
|
igor@359
|
82 \caption{Simular un directorio vacío con un fichero escondido}
|
igor@345
|
83 \label{ex:daily:hidden}
|
igor@345
|
84 \end{figure}
|
igor@345
|
85
|
igor@359
|
86 Otra forma de abordar la necesidad de un fichero vacío es crear
|
igor@345
|
87 simplemente uno en sus guiones de construcción antes de ser necesarios.
|
igor@345
|
88
|
igor@359
|
89 \section{Cómo dejar de hacer seguimiento a un fichero}
|
igor@359
|
90
|
igor@359
|
91 Si decide que un fichero no pertenece a su repositorio, use la orden
|
igor@359
|
92 \hgcmd{remove}; se borrará el fichero y le indicará a Mercurial que
|
igor@359
|
93 deje de hacerle seguimiento. Los ficheros eliminados se representan
|
igor@353
|
94 con ``\texttt{R}'' al usar \hgcmd{status}.
|
igor@345
|
95 \interaction{daily.files.remove}
|
igor@345
|
96
|
igor@359
|
97 Después de hacer \hgcmd{remove} a un fichero, Mercurial dejará de
|
igor@359
|
98 hacer seguimiento al mismo, incluso si recrea el fichero con el mismo
|
igor@359
|
99 nombre en su directorio de trabajo. Si decide recrear un fichero con
|
igor@353
|
100 el mismo nombre y desea que Mercurial le haga seguimiento, basta con
|
igor@359
|
101 hacerle \hgcmd{add}. Mercurial sabrá que el fichero recientemente
|
igor@359
|
102 adicionado no está relacionado con el fichero anterior que tenía el
|
igor@353
|
103 mismo nombre.
|
igor@353
|
104
|
igor@359
|
105 \subsection{Al eliminar un fichero no se afecta su historia}
|
igor@359
|
106
|
igor@359
|
107 Es preciso tener en cuenta que al eliminar un fichero se tiene
|
igor@353
|
108 dos efectos solamente.
|
igor@345
|
109 \begin{itemize}
|
igor@353
|
110 \item Se elimina la versión actual del fichero del directorio de
|
igor@353
|
111 trabajo.
|
igor@353
|
112 \item Mercurial deja de hacer seguimiento a los cambios del fichero
|
igor@353
|
113 desde la próxima consignación.
|
igor@345
|
114 \end{itemize}
|
igor@353
|
115 Al eliminar un fichero \emph{no} se altera de ninguna manera la
|
igor@353
|
116 \emph{historia} del mismo.
|
igor@353
|
117
|
igor@353
|
118 Si actualiza su directorio de trabajo a un conjunto de cambios en el
|
igor@359
|
119 cual esl fichero que eliminó aún era tenido en cuenta, reaparecerá en
|
igor@353
|
120 el directorio de trabajo, con los contenidos que este tenía cuando se
|
igor@353
|
121 consignó tal conjunto de cambios. Si usted actualiza el directorio de
|
igor@359
|
122 trabajo a un conjunto de cambios posterior en el cual el fichero había
|
igor@353
|
123 sido eliminado, Mercurial lo eliminará de nuevo del directorio de
|
igor@353
|
124 trabajo.
|
igor@345
|
125
|
igor@359
|
126 \subsection{Ficheros perdidos}
|
igor@359
|
127
|
igor@359
|
128 Mercurial considera como \emph{perdido} un fichero que usted borró,
|
igor@359
|
129 pero para el que no se usó \hgcmd{remove}. Los ficheros perdidos se
|
igor@353
|
130 representan con ``\texttt{!}'' al visualizar \hgcmd{status}.
|
igor@359
|
131 Las órdenes de Mercurial generalmente no harán nada con los ficheros
|
igor@353
|
132 perdidos.
|
igor@345
|
133 \interaction{daily.files.missing}
|
igor@345
|
134
|
igor@359
|
135 Si su repositorio contiene un fichero que \hgcmd{status} reporta como
|
igor@353
|
136 perdido, y desea que el mismo se vaya, se puede usar
|
igor@353
|
137 \hgcmdargs{remove}{\hgopt{remove}{--after}} posteriormente para
|
igor@359
|
138 indicarle a Mercurial que usted deseaba borrar tal fichero.
|
igor@345
|
139 \interaction{daily.files.remove-after}
|
igor@345
|
140
|
igor@353
|
141 Por otro lado, si borró un fichero perdido por accidente, puede usar
|
igor@353
|
142 \hgcmdargs{revert}{\emph{nombre de fichero}} para recuperar el
|
igor@353
|
143 fichero. Reaparecerá sin modificaciones.
|
igor@345
|
144 \interaction{daily.files.recover-missing}
|
igor@345
|
145
|
igor@353
|
146 \subsection{Nota al margen: ¿Por qué decirle explícitamente a Mercurial
|
igor@359
|
147 que elimine un fichero?}
|
igor@353
|
148
|
igor@353
|
149 Es posible que se haya preguntado por qué Mercurial exige que usted le
|
igor@359
|
150 indique explícitamente que está borrando un fichero. Al principio del
|
igor@359
|
151 desarrollo de Mercurial, este permitía que usted borrara el fichero
|
igor@359
|
152 sin más; Mercurial se daría cuanta de la ausencia del fichero
|
igor@353
|
153 automáticamente después de la ejecución de \hgcmd{commit}, y dejaba de
|
igor@359
|
154 hacer seguimiento al fichero. En la práctica, resultaba muy sencillo
|
igor@359
|
155 borrar un fichero accidentalmente sin darse cuenta.
|
igor@359
|
156
|
igor@359
|
157 \subsection{Atajo útil---agregar y eliminar ficheros en un solo paso}
|
igor@353
|
158
|
igor@353
|
159 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
|
igor@359
|
160 los ficheros que no tienen seguimiento y marca los ficheros faltantes
|
igor@353
|
161 como eliminados.
|
igor@345
|
162 \interaction{daily.files.addremove}
|
igor@353
|
163 La orden \hgcmd{commit} su puede usar con la opción \hgopt{commit}{-A}
|
igor@353
|
164 que aplica el agregar-eliminar, seguido inmediatamente de una
|
igor@353
|
165 consignación.
|
igor@345
|
166 \interaction{daily.files.commit-addremove}
|
igor@345
|
167
|
igor@359
|
168 \section{Copiar ficheros}
|
igor@359
|
169
|
igor@359
|
170 Mercurial ofrece la orden \hgcmd{copy} para hacer una nueva copia de
|
igor@359
|
171 un archivo. Cuando se copia un archivo con esta orden, Mercurial
|
igor@359
|
172 lleva un registro indicando que el nuevo archivo es una copia del
|
igor@359
|
173 fichero original. Trata de forma especial los archivos copiados cuando
|
igor@359
|
174 usted hace una fusión con el trabajo de alguien más.
|
igor@359
|
175
|
igor@359
|
176 \subsection{Resultados de copiar un archivo durante una fusión}
|
igor@359
|
177
|
igor@359
|
178 Durante una fusión lols cambios ``siguen'' una copia. Para ilustrar
|
igor@359
|
179 lo que esto significa, haremos un ejemplo. Comenzaremos con el mini
|
igor@359
|
180 repositorio usual que contiene un solo archivo
|
igor@345
|
181 \interaction{daily.copy.init}
|
igor@359
|
182 Debemos trabajar algo en paralelo, de forma que tengamos algo para
|
igor@359
|
183 fusionar. Aquí clonamos el repositorio.
|
igor@345
|
184 \interaction{daily.copy.clone}
|
igor@359
|
185 De vuelta en el repositorio, usemos la orden \hgcmd{copy} para hacer
|
igor@359
|
186 una copia del primer archivo que creamos.
|
igor@345
|
187 \interaction{daily.copy.copy}
|
igor@345
|
188
|
igor@359
|
189 Si vemos la salida de la orden \hgcmd{status}, el archivo copiado luce
|
igor@359
|
190 como un archivo que se ha añadido normalmente.
|
igor@345
|
191 \interaction{daily.copy.status}
|
igor@359
|
192 Si usamos la opción \hgopt{status}{-C} de la orden \hgcmd{status},
|
igor@359
|
193 imprimirá otra línea: Ela archivo of output: this is the file that our newly-added
|
igor@345
|
194 file was copied \emph{from}.
|
igor@345
|
195 \interaction{daily.copy.status-copy}
|
igor@345
|
196
|
igor@359
|
197 Ahora, en el repositorio que clonamos, hagamos un cambio en
|
igor@359
|
198 paralelo. Adicionaremos una línea de contenido al archivo original que
|
igor@359
|
199 creamos.
|
igor@345
|
200 \interaction{daily.copy.other}
|
igor@359
|
201 Hemos modificado el fichero \filename{file} en este
|
igor@359
|
202 repositorio. Cuando jalemos los cambios del primer repositorio y
|
igor@359
|
203 fusionemos las dos cabezas, Mercurial propagará los cambios que hemos
|
igor@359
|
204 hecho localmente en \filename{file} a su copia, \filename{new-file}.
|
igor@345
|
205 \interaction{daily.copy.merge}
|
igor@345
|
206
|
igor@359
|
207 \subsection{¿Por qué los cambios se reflejan en las copias?}
|
igor@345
|
208 \label{sec:daily:why-copy}
|
igor@345
|
209
|
igor@359
|
210 Este comportamiento de cambios en ficheros que se propagan a las
|
igor@359
|
211 copias de los ficheros parecería esotérico, pero en la mayoría de
|
igor@359
|
212 casos es absolutamente deseable.
|
igor@359
|
213
|
igor@359
|
214 Es indispensable recordar que esta propagación \emph{solamente} sucede
|
igor@359
|
215 cuando fusionamos. Por lo tanto si sobre un archivo 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@359
|
225 archivo 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@359
|
228 del archivo.
|
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@359
|
233 mismo \emph{permanecería} en su copia del archivo.
|
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
|
igor@359
|
242 fichero oficinal 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
|
igor@359
|
250 propagación automática de cambios en las copias no es para usted, use
|
igor@359
|
251 la orden usual de sus sistema para copiar ficheros (En sistemas tipo
|
igor@359
|
252 Unix, es \command{cp}), posteriormente use \hgcmd{add} sobre la nueva
|
igor@359
|
253 copia hecha a mano. Antes de hacerlo, de todas maneras, relea la
|
igor@359
|
254 sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que
|
igor@359
|
255 este comportamiento no es el apropiado para su caso específico.
|
igor@359
|
256
|
igor@359
|
257 \subsection{Comportamiento de la orden \hgcmd{copy}}
|
igor@359
|
258
|
igor@359
|
259 Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
|
igor@359
|
260 archivo fuente del directorio actual. Esto significa que si usted hace
|
igor@359
|
261 modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber
|
igor@359
|
262 consignado primero los cambios, la nueva copia contendrá también las
|
igor@359
|
263 modificaciones que haya hecho hasta ese punto. (Este comportamiento me
|
igor@359
|
264 parece poco intuitivo, y por tal motivo lo menciono.)
|
igor@359
|
265
|
igor@359
|
266 La orden \hgcmd{copy} actua de forma parecida a la orden \command{cp}
|
igor@359
|
267 de Unix(puede usar el alias \hgcmd{cp} si le es más cómodo). El
|
igor@359
|
268 último argumento es el \emph{destino}, y todos los argumentos previos
|
igor@359
|
269 son las \emph{fuentes}. Si solamente indica un fichero como la
|
igor@359
|
270 fuente, y el destino no existe, se crea un fichero nuevo con ese nombre.
|
igor@345
|
271 \interaction{daily.copy.simple}
|
igor@359
|
272 Si el destino es un directorio, Mercurial copia las fuentes en este.
|
igor@345
|
273 \interaction{daily.copy.dir-dest}
|
igor@359
|
274 La copia de un directorio es recursiva, y preserva la estructura del
|
igor@359
|
275 directorio fuente.
|
igor@345
|
276 \interaction{daily.copy.dir-src}
|
igor@359
|
277 Si tanto la fuente como el destino son directorios, la estructura de
|
igor@359
|
278 la fuente se recrea en el directorio destino.
|
igor@345
|
279 \interaction{daily.copy.dir-src-dest}
|
igor@345
|
280
|
igor@359
|
281 De la misma forma como la orden \hgcmd{rename}, si copia un fichero
|
igor@359
|
282 manualmente y desea que Mercurial sepa que ha copiado un fichero,
|
igor@359
|
283 basta con aplicar la opción \hgopt{copy}{--after} a la orden
|
igor@359
|
284 \hgcmd{copy}.
|
igor@345
|
285 \interaction{daily.copy.after}
|
igor@345
|
286
|
igor@345
|
287 \section{Renaming files}
|
igor@345
|
288
|
igor@345
|
289 It's rather more common to need to rename a file than to make a copy
|
igor@345
|
290 of it. The reason I discussed the \hgcmd{copy} command before talking
|
igor@345
|
291 about renaming files is that Mercurial treats a rename in essentially
|
igor@345
|
292 the same way as a copy. Therefore, knowing what Mercurial does when
|
igor@345
|
293 you copy a file tells you what to expect when you rename a file.
|
igor@345
|
294
|
igor@345
|
295 When you use the \hgcmd{rename} command, Mercurial makes a copy of
|
igor@345
|
296 each source file, then deletes it and marks the file as removed.
|
igor@345
|
297 \interaction{daily.rename.rename}
|
igor@345
|
298 The \hgcmd{status} command shows the newly copied file as added, and
|
igor@345
|
299 the copied-from file as removed.
|
igor@345
|
300 \interaction{daily.rename.status}
|
igor@345
|
301 As with the results of a \hgcmd{copy}, we must use the
|
igor@345
|
302 \hgopt{status}{-C} option to \hgcmd{status} to see that the added file
|
igor@345
|
303 is really being tracked by Mercurial as a copy of the original, now
|
igor@345
|
304 removed, file.
|
igor@345
|
305 \interaction{daily.rename.status-copy}
|
igor@345
|
306
|
igor@345
|
307 As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
|
igor@345
|
308 a rename after the fact using the \hgopt{rename}{--after} option. In
|
igor@345
|
309 most other respects, the behaviour of the \hgcmd{rename} command, and
|
igor@345
|
310 the options it accepts, are similar to the \hgcmd{copy} command.
|
igor@345
|
311
|
igor@345
|
312 \subsection{Renaming files and merging changes}
|
igor@345
|
313
|
igor@345
|
314 Since Mercurial's rename is implemented as copy-and-remove, the same
|
igor@345
|
315 propagation of changes happens when you merge after a rename as after
|
igor@345
|
316 a copy.
|
igor@345
|
317
|
igor@345
|
318 If I modify a file, and you rename it to a new name, and then we merge
|
igor@345
|
319 our respective changes, my modifications to the file under its
|
igor@345
|
320 original name will be propagated into the file under its new name.
|
igor@345
|
321 (This is something you might expect to ``simply work,'' but not all
|
igor@345
|
322 revision control systems actually do this.)
|
igor@345
|
323
|
igor@345
|
324 Whereas having changes follow a copy is a feature where you can
|
igor@345
|
325 perhaps nod and say ``yes, that might be useful,'' it should be clear
|
igor@345
|
326 that having them follow a rename is definitely important. Without
|
igor@345
|
327 this facility, it would simply be too easy for changes to become
|
igor@345
|
328 orphaned when files are renamed.
|
igor@345
|
329
|
igor@345
|
330 \subsection{Divergent renames and merging}
|
igor@345
|
331
|
igor@345
|
332 The case of diverging names occurs when two developers start with a
|
igor@345
|
333 file---let's call it \filename{foo}---in their respective
|
igor@345
|
334 repositories.
|
igor@345
|
335
|
igor@345
|
336 \interaction{rename.divergent.clone}
|
igor@345
|
337 Anne renames the file to \filename{bar}.
|
igor@345
|
338 \interaction{rename.divergent.rename.anne}
|
igor@345
|
339 Meanwhile, Bob renames it to \filename{quux}.
|
igor@345
|
340 \interaction{rename.divergent.rename.bob}
|
igor@345
|
341
|
igor@345
|
342 I like to think of this as a conflict because each developer has
|
igor@345
|
343 expressed different intentions about what the file ought to be named.
|
igor@345
|
344
|
igor@345
|
345 What do you think should happen when they merge their work?
|
igor@345
|
346 Mercurial's actual behaviour is that it always preserves \emph{both}
|
igor@345
|
347 names when it merges changesets that contain divergent renames.
|
igor@345
|
348 \interaction{rename.divergent.merge}
|
igor@345
|
349
|
igor@345
|
350 Notice that Mercurial does warn about the divergent renames, but it
|
igor@345
|
351 leaves it up to you to do something about the divergence after the merge.
|
igor@345
|
352
|
igor@345
|
353 \subsection{Convergent renames and merging}
|
igor@345
|
354
|
igor@345
|
355 Another kind of rename conflict occurs when two people choose to
|
igor@345
|
356 rename different \emph{source} files to the same \emph{destination}.
|
igor@345
|
357 In this case, Mercurial runs its normal merge machinery, and lets you
|
igor@345
|
358 guide it to a suitable resolution.
|
igor@345
|
359
|
igor@345
|
360 \subsection{Other name-related corner cases}
|
igor@345
|
361
|
igor@345
|
362 Mercurial has a longstanding bug in which it fails to handle a merge
|
igor@345
|
363 where one side has a file with a given name, while another has a
|
igor@345
|
364 directory with the same name. This is documented as~\bug{29}.
|
igor@345
|
365 \interaction{issue29.go}
|
igor@345
|
366
|
igor@345
|
367 \section{Recovering from mistakes}
|
igor@345
|
368
|
igor@345
|
369 Mercurial has some useful commands that will help you to recover from
|
igor@345
|
370 some common mistakes.
|
igor@345
|
371
|
igor@345
|
372 The \hgcmd{revert} command lets you undo changes that you have made to
|
igor@345
|
373 your working directory. For example, if you \hgcmd{add} a file by
|
igor@345
|
374 accident, just run \hgcmd{revert} with the name of the file you added,
|
igor@345
|
375 and while the file won't be touched in any way, it won't be tracked
|
igor@345
|
376 for adding by Mercurial any longer, either. You can also use
|
igor@345
|
377 \hgcmd{revert} to get rid of erroneous changes to a file.
|
igor@345
|
378
|
igor@345
|
379 It's useful to remember that the \hgcmd{revert} command is useful for
|
igor@345
|
380 changes that you have not yet committed. Once you've committed a
|
igor@345
|
381 change, if you decide it was a mistake, you can still do something
|
igor@345
|
382 about it, though your options may be more limited.
|
igor@345
|
383
|
igor@345
|
384 For more information about the \hgcmd{revert} command, and details
|
igor@345
|
385 about how to deal with changes you have already committed, see
|
igor@345
|
386 chapter~\ref{chap:undo}.
|
igor@345
|
387
|
igor@345
|
388 %%% Local Variables:
|
igor@345
|
389 %%% mode: latex
|
igor@345
|
390 %%% TeX-master: "00book"
|
igor@345
|
391 %%% End:
|