| rev |
line source |
|
igor@345
|
1 \chapter{Mercurial día a día}
|
|
igor@345
|
2 \label{chap:daily}
|
|
igor@345
|
3
|
|
igor@345
|
4 \section{Cómo indicarle a Mercurial qué archivos seguir}
|
|
igor@345
|
5
|
|
igor@345
|
6 Mercurial no trabaja con archivos en su repositorio a menos que usted
|
|
igor@345
|
7 explícitamente se lo indique. La orden \hgcmd{status} le mostrará
|
|
igor@345
|
8 cuáles archivos son desconocidos para Mercurial; emplea un
|
|
igor@345
|
9 ``\texttt{?}'' para mostrar tales archivos.
|
|
igor@345
|
10
|
|
igor@345
|
11 Para indicarle a Mercurial que tenga en cuenta un archivo, emplee la
|
|
igor@345
|
12 orden \hgcmd{add}. Una vez que haya adicionado el archivo, la línea
|
|
igor@345
|
13 referente al archivo al aplicar la orden \hgcmd{status} para tal
|
|
igor@345
|
14 archivo cambia de ``\texttt{?}'' a ``\texttt{A}''.
|
|
igor@345
|
15 \interaction{daily.files.add}
|
|
igor@345
|
16
|
|
igor@345
|
17 Después de invocar \hgcmd{commit}, los archivos 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@345
|
20 archivos ``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@345
|
23 archivos, 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
|
|
igor@345
|
28 Cuando usted añade un archivo, Mercurial no hace nada con el inmediatamente.
|
|
igor@345
|
29 A cambio, tomará una instantánea del estado del archivo la próxima vez
|
|
igor@345
|
30 que usted consigne. Continuará haciendo seguimiento a los cambios que
|
|
igor@345
|
31 haga sobre el archivo cada vez que consigne, hasta que usted lo elimine.
|
|
igor@345
|
32
|
|
igor@345
|
33 \subsection{Nombramiento explicíto e implícito de archivos}
|
|
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@345
|
37 ``Deseo operar en cada archivo 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@345
|
41 los archivos que se adicionaron, mientras que no lo hizo en el ejemplo
|
|
igor@345
|
42 anterior cuando adicionamos el archivo con nombre \filename{a}.
|
|
igor@345
|
43
|
|
igor@345
|
44 En el último caso hicimos explícito el nombre del archivo 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@345
|
49 Cuando hacemos \emph{implícitos} los nombres de los archivos dando el
|
|
igor@345
|
50 nombre de un directorio, Mercurial efectua un paso extra al imprimir
|
|
igor@345
|
51 el nombre de cada archivo 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@345
|
56 \subsection{Nota al margen:Mercurial trata archivos, no directorios}
|
|
igor@345
|
57
|
|
igor@345
|
58 Mercurial no da seguimiento a la información de los directorios. En
|
|
igor@345
|
59 lugar de eso tiene en cuenta las rutas de los archivos. Antes de
|
|
igor@345
|
60 crear un archivo, primero crea todos los directorios que hagan falta
|
|
igor@345
|
61 para completar la ruta del archivo. Después de borrar un archivo,
|
|
igor@345
|
62 borra todos los directorios vacíos que estuvieran en la ruta del
|
|
igor@345
|
63 archivo 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@345
|
75 un archivo ``escondido'' dentro de ese directorio. En sistemas tipo
|
|
igor@345
|
76 Unix, cualquier archivo 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@345
|
82 \caption{Simular un directorio vacío con un archivo escondido}
|
|
igor@345
|
83 \label{ex:daily:hidden}
|
|
igor@345
|
84 \end{figure}
|
|
igor@345
|
85
|
|
igor@345
|
86 Otra forma de abordar la necesidad de un archivo vacío es crear
|
|
igor@345
|
87 simplemente uno en sus guiones de construcción antes de ser necesarios.
|
|
igor@345
|
88
|
|
igor@353
|
89 \section{Cómo dejar de hacer seguimiento a un archivo}
|
|
igor@353
|
90
|
|
igor@353
|
91 Si decide que un archivo no pertenece a su repositorio, use la orden
|
|
igor@353
|
92 \hgcmd{remove}; se borrará el archivo y le indicará a Mercurial que
|
|
igor@353
|
93 deje de hacerle seguimiento. Los archivos eliminados se representan
|
|
igor@353
|
94 con ``\texttt{R}'' al usar \hgcmd{status}.
|
|
igor@345
|
95 \interaction{daily.files.remove}
|
|
igor@345
|
96
|
|
igor@353
|
97 Después de hacer \hgcmd{remove} a un archivo, Mercurial dejará de
|
|
igor@353
|
98 hacer seguimiento al mismo, incluso si recrea el archivo con el mismo
|
|
igor@353
|
99 nombre en su directorio de trabajo. Si decide recrear un archivo con
|
|
igor@353
|
100 el mismo nombre y desea que Mercurial le haga seguimiento, basta con
|
|
igor@353
|
101 hacerle \hgcmd{add}. Mercurial sabrá que el archivo recientemente
|
|
igor@353
|
102 adicionado no está relacionado con el archivo anterior que tenía el
|
|
igor@353
|
103 mismo nombre.
|
|
igor@353
|
104
|
|
igor@353
|
105 \subsection{Al eliminar un archivo no se afecta su historia}
|
|
igor@353
|
106
|
|
igor@353
|
107 Es preciso tener en cuenta que al eliminar un archivo 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@353
|
119 cual esl archivo 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@353
|
122 trabajo a un conjunto de cambios posterior en el cual el archivo había
|
|
igor@353
|
123 sido eliminado, Mercurial lo eliminará de nuevo del directorio de
|
|
igor@353
|
124 trabajo.
|
|
igor@345
|
125
|
|
igor@345
|
126 \subsection{Missing files}
|
|
igor@345
|
127
|
|
igor@353
|
128 Mercurial considera como \emph{perdido} un archivo que usted borró,
|
|
igor@353
|
129 pero para el que no se usó \hgcmd{remove}. Los archivos perdidos se
|
|
igor@353
|
130 representan con ``\texttt{!}'' al visualizar \hgcmd{status}.
|
|
igor@353
|
131 Las órdenes de Mercurial generalmente no harán nada con los archivos
|
|
igor@353
|
132 perdidos.
|
|
igor@345
|
133 \interaction{daily.files.missing}
|
|
igor@345
|
134
|
|
igor@353
|
135 Si su repositorio contiene un archivo 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@353
|
138 indicarle a Mercurial que usted deseaba borrar tal archivo.
|
|
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@353
|
147 que elimine un archivo?}
|
|
igor@353
|
148
|
|
igor@353
|
149 Es posible que se haya preguntado por qué Mercurial exige que usted le
|
|
igor@353
|
150 indique explícitamente que está borrando un archivo. Al principio del
|
|
igor@353
|
151 desarrollo de Mercurial, este permitía que usted borrara el archivo
|
|
igor@353
|
152 sin más; Mercurial se daría cuanta de la ausencia del archivo
|
|
igor@353
|
153 automáticamente después de la ejecución de \hgcmd{commit}, y dejaba de
|
|
igor@353
|
154 hacer seguimiento al archivo. En la práctica, resultaba muy sencillo
|
|
igor@353
|
155 borrar un archivo accidentalmente sin darse cuenta.
|
|
igor@353
|
156
|
|
igor@353
|
157 \subsection{Atajo útil---agregar y eliminar archivos en un solo paso}
|
|
igor@353
|
158
|
|
igor@353
|
159 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
|
|
igor@353
|
160 los archivos que no tienen seguimiento y marca los archivos 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@345
|
168 \section{Copying files}
|
|
igor@345
|
169
|
|
igor@345
|
170 Mercurial provides a \hgcmd{copy} command that lets you make a new
|
|
igor@345
|
171 copy of a file. When you copy a file using this command, Mercurial
|
|
igor@345
|
172 makes a record of the fact that the new file is a copy of the original
|
|
igor@345
|
173 file. It treats these copied files specially when you merge your work
|
|
igor@345
|
174 with someone else's.
|
|
igor@345
|
175
|
|
igor@345
|
176 \subsection{The results of copying during a merge}
|
|
igor@345
|
177
|
|
igor@345
|
178 What happens during a merge is that changes ``follow'' a copy. To
|
|
igor@345
|
179 best illustrate what this means, let's create an example. We'll start
|
|
igor@345
|
180 with the usual tiny repository that contains a single file.
|
|
igor@345
|
181 \interaction{daily.copy.init}
|
|
igor@345
|
182 We need to do some work in parallel, so that we'll have something to
|
|
igor@345
|
183 merge. So let's clone our repository.
|
|
igor@345
|
184 \interaction{daily.copy.clone}
|
|
igor@345
|
185 Back in our initial repository, let's use the \hgcmd{copy} command to
|
|
igor@345
|
186 make a copy of the first file we created.
|
|
igor@345
|
187 \interaction{daily.copy.copy}
|
|
igor@345
|
188
|
|
igor@345
|
189 If we look at the output of the \hgcmd{status} command afterwards, the
|
|
igor@345
|
190 copied file looks just like a normal added file.
|
|
igor@345
|
191 \interaction{daily.copy.status}
|
|
igor@345
|
192 But if we pass the \hgopt{status}{-C} option to \hgcmd{status}, it
|
|
igor@345
|
193 prints another line 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@345
|
197 Now, back in the repository we cloned, let's make a change in
|
|
igor@345
|
198 parallel. We'll add a line of content to the original file that we
|
|
igor@345
|
199 created.
|
|
igor@345
|
200 \interaction{daily.copy.other}
|
|
igor@345
|
201 Now we have a modified \filename{file} in this repository. When we
|
|
igor@345
|
202 pull the changes from the first repository, and merge the two heads,
|
|
igor@345
|
203 Mercurial will propagate the changes that we made locally to
|
|
igor@345
|
204 \filename{file} into its copy, \filename{new-file}.
|
|
igor@345
|
205 \interaction{daily.copy.merge}
|
|
igor@345
|
206
|
|
igor@345
|
207 \subsection{Why should changes follow copies?}
|
|
igor@345
|
208 \label{sec:daily:why-copy}
|
|
igor@345
|
209
|
|
igor@345
|
210 This behaviour, of changes to a file propagating out to copies of the
|
|
igor@345
|
211 file, might seem esoteric, but in most cases it's highly desirable.
|
|
igor@345
|
212
|
|
igor@345
|
213 First of all, remember that this propagation \emph{only} happens when
|
|
igor@345
|
214 you merge. So if you \hgcmd{copy} a file, and subsequently modify the
|
|
igor@345
|
215 original file during the normal course of your work, nothing will
|
|
igor@345
|
216 happen.
|
|
igor@345
|
217
|
|
igor@345
|
218 The second thing to know is that modifications will only propagate
|
|
igor@345
|
219 across a copy as long as the repository that you're pulling changes
|
|
igor@345
|
220 from \emph{doesn't know} about the copy.
|
|
igor@345
|
221
|
|
igor@345
|
222 The reason that Mercurial does this is as follows. Let's say I make
|
|
igor@345
|
223 an important bug fix in a source file, and commit my changes.
|
|
igor@345
|
224 Meanwhile, you've decided to \hgcmd{copy} the file in your repository,
|
|
igor@345
|
225 without knowing about the bug or having seen the fix, and you have
|
|
igor@345
|
226 started hacking on your copy of the file.
|
|
igor@345
|
227
|
|
igor@345
|
228 If you pulled and merged my changes, and Mercurial \emph{didn't}
|
|
igor@345
|
229 propagate changes across copies, your source file would now contain
|
|
igor@345
|
230 the bug, and unless you remembered to propagate the bug fix by hand,
|
|
igor@345
|
231 the bug would \emph{remain} in your copy of the file.
|
|
igor@345
|
232
|
|
igor@345
|
233 By automatically propagating the change that fixed the bug from the
|
|
igor@345
|
234 original file to the copy, Mercurial prevents this class of problem.
|
|
igor@345
|
235 To my knowledge, Mercurial is the \emph{only} revision control system
|
|
igor@345
|
236 that propagates changes across copies like this.
|
|
igor@345
|
237
|
|
igor@345
|
238 Once your change history has a record that the copy and subsequent
|
|
igor@345
|
239 merge occurred, there's usually no further need to propagate changes
|
|
igor@345
|
240 from the original file to the copied file, and that's why Mercurial
|
|
igor@345
|
241 only propagates changes across copies until this point, and no
|
|
igor@345
|
242 further.
|
|
igor@345
|
243
|
|
igor@345
|
244 \subsection{How to make changes \emph{not} follow a copy}
|
|
igor@345
|
245
|
|
igor@345
|
246 If, for some reason, you decide that this business of automatically
|
|
igor@345
|
247 propagating changes across copies is not for you, simply use your
|
|
igor@345
|
248 system's normal file copy command (on Unix-like systems, that's
|
|
igor@345
|
249 \command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
|
|
igor@345
|
250 by hand. Before you do so, though, please do reread
|
|
igor@345
|
251 section~\ref{sec:daily:why-copy}, and make an informed decision that
|
|
igor@345
|
252 this behaviour is not appropriate to your specific case.
|
|
igor@345
|
253
|
|
igor@345
|
254 \subsection{Behaviour of the \hgcmd{copy} command}
|
|
igor@345
|
255
|
|
igor@345
|
256 When you use the \hgcmd{copy} command, Mercurial makes a copy of each
|
|
igor@345
|
257 source file as it currently stands in the working directory. This
|
|
igor@345
|
258 means that if you make some modifications to a file, then \hgcmd{copy}
|
|
igor@345
|
259 it without first having committed those changes, the new copy will
|
|
igor@345
|
260 also contain the modifications you have made up until that point. (I
|
|
igor@345
|
261 find this behaviour a little counterintuitive, which is why I mention
|
|
igor@345
|
262 it here.)
|
|
igor@345
|
263
|
|
igor@345
|
264 The \hgcmd{copy} command acts similarly to the Unix \command{cp}
|
|
igor@345
|
265 command (you can use the \hgcmd{cp} alias if you prefer). The last
|
|
igor@345
|
266 argument is the \emph{destination}, and all prior arguments are
|
|
igor@345
|
267 \emph{sources}. If you pass it a single file as the source, and the
|
|
igor@345
|
268 destination does not exist, it creates a new file with that name.
|
|
igor@345
|
269 \interaction{daily.copy.simple}
|
|
igor@345
|
270 If the destination is a directory, Mercurial copies its sources into
|
|
igor@345
|
271 that directory.
|
|
igor@345
|
272 \interaction{daily.copy.dir-dest}
|
|
igor@345
|
273 Copying a directory is recursive, and preserves the directory
|
|
igor@345
|
274 structure of the source.
|
|
igor@345
|
275 \interaction{daily.copy.dir-src}
|
|
igor@345
|
276 If the source and destination are both directories, the source tree is
|
|
igor@345
|
277 recreated in the destination directory.
|
|
igor@345
|
278 \interaction{daily.copy.dir-src-dest}
|
|
igor@345
|
279
|
|
igor@345
|
280 As with the \hgcmd{rename} command, if you copy a file manually and
|
|
igor@345
|
281 then want Mercurial to know that you've copied the file, simply use
|
|
igor@345
|
282 the \hgopt{copy}{--after} option to \hgcmd{copy}.
|
|
igor@345
|
283 \interaction{daily.copy.after}
|
|
igor@345
|
284
|
|
igor@345
|
285 \section{Renaming files}
|
|
igor@345
|
286
|
|
igor@345
|
287 It's rather more common to need to rename a file than to make a copy
|
|
igor@345
|
288 of it. The reason I discussed the \hgcmd{copy} command before talking
|
|
igor@345
|
289 about renaming files is that Mercurial treats a rename in essentially
|
|
igor@345
|
290 the same way as a copy. Therefore, knowing what Mercurial does when
|
|
igor@345
|
291 you copy a file tells you what to expect when you rename a file.
|
|
igor@345
|
292
|
|
igor@345
|
293 When you use the \hgcmd{rename} command, Mercurial makes a copy of
|
|
igor@345
|
294 each source file, then deletes it and marks the file as removed.
|
|
igor@345
|
295 \interaction{daily.rename.rename}
|
|
igor@345
|
296 The \hgcmd{status} command shows the newly copied file as added, and
|
|
igor@345
|
297 the copied-from file as removed.
|
|
igor@345
|
298 \interaction{daily.rename.status}
|
|
igor@345
|
299 As with the results of a \hgcmd{copy}, we must use the
|
|
igor@345
|
300 \hgopt{status}{-C} option to \hgcmd{status} to see that the added file
|
|
igor@345
|
301 is really being tracked by Mercurial as a copy of the original, now
|
|
igor@345
|
302 removed, file.
|
|
igor@345
|
303 \interaction{daily.rename.status-copy}
|
|
igor@345
|
304
|
|
igor@345
|
305 As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
|
|
igor@345
|
306 a rename after the fact using the \hgopt{rename}{--after} option. In
|
|
igor@345
|
307 most other respects, the behaviour of the \hgcmd{rename} command, and
|
|
igor@345
|
308 the options it accepts, are similar to the \hgcmd{copy} command.
|
|
igor@345
|
309
|
|
igor@345
|
310 \subsection{Renaming files and merging changes}
|
|
igor@345
|
311
|
|
igor@345
|
312 Since Mercurial's rename is implemented as copy-and-remove, the same
|
|
igor@345
|
313 propagation of changes happens when you merge after a rename as after
|
|
igor@345
|
314 a copy.
|
|
igor@345
|
315
|
|
igor@345
|
316 If I modify a file, and you rename it to a new name, and then we merge
|
|
igor@345
|
317 our respective changes, my modifications to the file under its
|
|
igor@345
|
318 original name will be propagated into the file under its new name.
|
|
igor@345
|
319 (This is something you might expect to ``simply work,'' but not all
|
|
igor@345
|
320 revision control systems actually do this.)
|
|
igor@345
|
321
|
|
igor@345
|
322 Whereas having changes follow a copy is a feature where you can
|
|
igor@345
|
323 perhaps nod and say ``yes, that might be useful,'' it should be clear
|
|
igor@345
|
324 that having them follow a rename is definitely important. Without
|
|
igor@345
|
325 this facility, it would simply be too easy for changes to become
|
|
igor@345
|
326 orphaned when files are renamed.
|
|
igor@345
|
327
|
|
igor@345
|
328 \subsection{Divergent renames and merging}
|
|
igor@345
|
329
|
|
igor@345
|
330 The case of diverging names occurs when two developers start with a
|
|
igor@345
|
331 file---let's call it \filename{foo}---in their respective
|
|
igor@345
|
332 repositories.
|
|
igor@345
|
333
|
|
igor@345
|
334 \interaction{rename.divergent.clone}
|
|
igor@345
|
335 Anne renames the file to \filename{bar}.
|
|
igor@345
|
336 \interaction{rename.divergent.rename.anne}
|
|
igor@345
|
337 Meanwhile, Bob renames it to \filename{quux}.
|
|
igor@345
|
338 \interaction{rename.divergent.rename.bob}
|
|
igor@345
|
339
|
|
igor@345
|
340 I like to think of this as a conflict because each developer has
|
|
igor@345
|
341 expressed different intentions about what the file ought to be named.
|
|
igor@345
|
342
|
|
igor@345
|
343 What do you think should happen when they merge their work?
|
|
igor@345
|
344 Mercurial's actual behaviour is that it always preserves \emph{both}
|
|
igor@345
|
345 names when it merges changesets that contain divergent renames.
|
|
igor@345
|
346 \interaction{rename.divergent.merge}
|
|
igor@345
|
347
|
|
igor@345
|
348 Notice that Mercurial does warn about the divergent renames, but it
|
|
igor@345
|
349 leaves it up to you to do something about the divergence after the merge.
|
|
igor@345
|
350
|
|
igor@345
|
351 \subsection{Convergent renames and merging}
|
|
igor@345
|
352
|
|
igor@345
|
353 Another kind of rename conflict occurs when two people choose to
|
|
igor@345
|
354 rename different \emph{source} files to the same \emph{destination}.
|
|
igor@345
|
355 In this case, Mercurial runs its normal merge machinery, and lets you
|
|
igor@345
|
356 guide it to a suitable resolution.
|
|
igor@345
|
357
|
|
igor@345
|
358 \subsection{Other name-related corner cases}
|
|
igor@345
|
359
|
|
igor@345
|
360 Mercurial has a longstanding bug in which it fails to handle a merge
|
|
igor@345
|
361 where one side has a file with a given name, while another has a
|
|
igor@345
|
362 directory with the same name. This is documented as~\bug{29}.
|
|
igor@345
|
363 \interaction{issue29.go}
|
|
igor@345
|
364
|
|
igor@345
|
365 \section{Recovering from mistakes}
|
|
igor@345
|
366
|
|
igor@345
|
367 Mercurial has some useful commands that will help you to recover from
|
|
igor@345
|
368 some common mistakes.
|
|
igor@345
|
369
|
|
igor@345
|
370 The \hgcmd{revert} command lets you undo changes that you have made to
|
|
igor@345
|
371 your working directory. For example, if you \hgcmd{add} a file by
|
|
igor@345
|
372 accident, just run \hgcmd{revert} with the name of the file you added,
|
|
igor@345
|
373 and while the file won't be touched in any way, it won't be tracked
|
|
igor@345
|
374 for adding by Mercurial any longer, either. You can also use
|
|
igor@345
|
375 \hgcmd{revert} to get rid of erroneous changes to a file.
|
|
igor@345
|
376
|
|
igor@345
|
377 It's useful to remember that the \hgcmd{revert} command is useful for
|
|
igor@345
|
378 changes that you have not yet committed. Once you've committed a
|
|
igor@345
|
379 change, if you decide it was a mistake, you can still do something
|
|
igor@345
|
380 about it, though your options may be more limited.
|
|
igor@345
|
381
|
|
igor@345
|
382 For more information about the \hgcmd{revert} command, and details
|
|
igor@345
|
383 about how to deal with changes you have already committed, see
|
|
igor@345
|
384 chapter~\ref{chap:undo}.
|
|
igor@345
|
385
|
|
igor@345
|
386 %%% Local Variables:
|
|
igor@345
|
387 %%% mode: latex
|
|
igor@345
|
388 %%% TeX-master: "00book"
|
|
igor@345
|
389 %%% End:
|
