1.1 --- a/es/Leame.1st	Sun Oct 19 20:18:42 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Oct 20 04:01:59 2008 -0500
     1.3 @@ -8,13 +8,78 @@
     1.4   * Encoding UTF-8 para las tildes, eñes y demás
     1.5   * Ancho de línea de 70 caracteres
     1.6  
     1.7 += ¿Cómo contribuir? =
     1.8 +Obtenga la copia :
     1.9 +hg clone http://mercurial.intuxication.org/hg/mercurial_book_es/
    1.10 +
    1.11 +Esto le ofrecerá un clon del repositorio en el directorio recién 
    1.12 +creado '''mercurial_book_es''':
    1.13 +
    1.14 +mercurial_book_es
    1.15 +|
    1.16 +|-- en
    1.17 +|-- es
    1.18 +|-- examples
    1.19 +|-- html
    1.20 +`-- sillybench
    1.21 +
    1.22 +El directorio de trabajo es '''es'''.
    1.23 +
    1.24 +
    1.25 +Una vez que haya traducido o aplicado correcciones a los archivos de
    1.26 +su copia local, haga un commit
    1.27 +
    1.28 + hg commit -m "comentario descriptivo de lo que hizo"
    1.29 +
    1.30 +Siempre mantenga actualizado su repositorio local
    1.31 + hg pull
    1.32 + hg update
    1.33 +
    1.34 +Hay dos formas de hacer la contribución, primero envíe un correo a
    1.35 +igor@tamarapatino.org indicando lo que desea hacer, se le puede
    1.36 +otorgar permiso de escritura en el repositorio, o si lo prefiere,
    1.37 +puede enviar un parche(patch).  Describimos a continuación los dos
    1.38 +procedimientos : Repositorio Público y Parches.   Es preferible el
    1.39 +repositorio público frente a los parches, puesto que estos segundos
    1.40 +pueden tardar en propagarse más.
    1.41 +
    1.42 +== Repositorio Público ==
    1.43 +Este sería el método preferido para que los cambios que usted haga
    1.44 +automáticamente queden en el repositorio y todos los traductores
    1.45 +podamos contar con la información rápidamente.
    1.46 +
    1.47 +Una vez que usted haya recibido la información necesaria, habiendo
    1.48 +elegido su usuario y su clave podrá "publicar"(push).
    1.49 +
    1.50 +Como este es un sistema distribuido, después de hacer la
    1.51 +consignación(commit), deberá publicarlo.
    1.52 +
    1.53 + hg push
    1.54 +
    1.55 +Se le solicitará su usuario y clave.
    1.56 +
    1.57 +== Parches ==
    1.58 +Este método exige que alguien reciba el parche y haga manualmente la
    1.59 +aplicación del mismo, ese alguien es igor@tamarapatino.org por ahora,
    1.60 +después de haber hecho commit en su repositorio local, revise su log.
    1.61 +
    1.62 + hg log | head
    1.63 +
    1.64 +Esta última orden le permitirá establecer la última revisión que se
    1.65 +consignó en su repositorio local, su identificador de revisión tendrá
    1.66 +el formato número:hash .   Generaría el archivo 
    1.67 +/tmp/patchparahgbook.patch con la orden
    1.68 +
    1.69 + hg -o /tmp/patchparahgbook.patch REV
    1.70 +
    1.71 +donde REV es el identificador de revisión que debió haber encontrado.
    1.72 +
    1.73  = Traducción/Revisión =
    1.74  
    1.75  En esta sección indicamos quienes están traduciendo
    1.76  y quienes revisando lo traducido. Coloque su nombre 
    1.77  para que los demás colaboradores sepan en dónde 
    1.78 -enfocar sus esfuerzos.  En este momento estamos dejando 
    1.79 -que *make* nos guíe.
    1.80 +enfocar sus esfuerzos.
    1.81  
    1.82  Indique qué archivos está traduciendo y/o revisando en 
    1.83  la lista siguiente. Cada archivo debe ser traducido y
    1.84 @@ -33,6 +98,7 @@
    1.85  || branch.tex      || Igor Támara   ||    100%    || 16/10/2008 ||  19/10/2008 ||
    1.86  || preface.tex     || Javier Rojas  ||    100%    || 18/10/2008 ||  19/10/2008 ||
    1.87  || tour-basic.tex  || Javier Rojas  ||    34%     || 19/10/2008 ||             ||
    1.88 +||      daily.tex  || Igor Támara   ||    19%     || 19/10/2008 ||             ||
    1.89  
    1.90  == Archivos en proceso de revisión ==
    1.91  ||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    1.92 @@ -40,7 +106,6 @@
    1.93  || branch.tex   ||               ||            ||            ||             ||
    1.94  || preface.tex  ||               ||            ||            ||             ||
    1.95  
    1.96 -
    1.97  == Archivos terminados ==
    1.98  
    1.99  = Unificación de Términos de Traducción =
   1.100 @@ -62,17 +127,20 @@
   1.101  
   1.102   Branch: Rama
   1.103   Bug: Fallo
   1.104 + Build Script: Guión de construcción
   1.105   Builtin: integrada/o
   1.106   Changelog: Bitácora de Cambios
   1.107   Changeset: Conjunto de Cambios
   1.108   Command: Orden
   1.109   Commit: Consignar
   1.110 + Directory: Directorio
   1.111   File: Archivo
   1.112   Head: Principal
   1.113   Hook: Gancho
   1.114   Merge: Fusión
   1.115   Milestone: Etapa
   1.116   Patch: Parche
   1.117 + Path: Ruta de archivo
   1.118   Pull: Jalar
   1.119   Push: Publicar
   1.120   Release: Versión o liberación de versión

     2.1 --- a/es/daily.tex	Sun Oct 19 20:18:42 2008 -0500
     2.2 +++ b/es/daily.tex	Mon Oct 20 04:01:59 2008 -0500
     2.3 @@ -0,0 +1,385 @@
     2.4 +\chapter{Mercurial día a día}
     2.5 +\label{chap:daily}
     2.6 +
     2.7 +\section{Cómo indicarle a Mercurial qué archivos seguir}
     2.8 +
     2.9 +Mercurial no trabaja con archivos en su repositorio a menos que usted
    2.10 +explícitamente se lo indique.  La orden \hgcmd{status} le mostrará
    2.11 +cuáles archivos son desconocidos para Mercurial; emplea un
    2.12 +``\texttt{?}'' para mostrar tales archivos.
    2.13 +
    2.14 +Para indicarle a Mercurial que tenga en cuenta un archivo, emplee la
    2.15 +orden \hgcmd{add}. Una vez que haya adicionado el archivo, la línea
    2.16 +referente al archivo al aplicar la orden \hgcmd{status} para tal
    2.17 +archivo cambia de ``\texttt{?}'' a ``\texttt{A}''.
    2.18 +\interaction{daily.files.add}
    2.19 +
    2.20 +Después de invocar \hgcmd{commit}, los archivos que haya adicionado
    2.21 +antes de consignar no se listarán en la salida de \hgcmd{status}.  La
    2.22 +razón para esto es que \hgcmd{status} solamente le muestra aquellos
    2.23 +archivos ``interesantes''---los que usted haya modificado o a aquellos
    2.24 +sobre los que usted haya indicado a Mercurial hacerles algo---de forma
    2.25 +predeterminada. Si tiene un repositorio que contiene miles de
    2.26 +archivos, inusualmente deseará saber cuáles de ellos están siendo
    2.27 +seguidos por Mercurial, pero que no han cambiado.  (De todas maneras,
    2.28 +puede obtener tal información; más adelante hablaremos de ello.)
    2.29 +
    2.30 +
    2.31 +Cuando usted añade un archivo, Mercurial no hace nada con el inmediatamente.
    2.32 +A cambio, tomará una instantánea del estado del archivo la próxima vez
    2.33 +que usted consigne. Continuará haciendo seguimiento a los cambios que
    2.34 +haga sobre el archivo cada vez que consigne, hasta que usted lo elimine.
    2.35 +
    2.36 +\subsection{Nombramiento explicíto e implícito de archivos}
    2.37 +
    2.38 +Mercurial tiene un comportamiento útil en el cual si a una orden,
    2.39 +le pasa el nombre de un directorio, todas las órdenes lo tratarán como
    2.40 +``Deseo operar en cada archivo de este directorio y sus 
    2.41 +subdirectorios''.
    2.42 +\interaction{daily.files.add-dir}
    2.43 +Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de
    2.44 +los archivos que se adicionaron, mientras que no lo hizo en el ejemplo
    2.45 +anterior cuando adicionamos el archivo con nombre \filename{a}.
    2.46 +
    2.47 +En el último caso hicimos explícito el nombre del archivo que
    2.48 +deseábamos adicionar en la línea de órdenes, y Mercurial asume en
    2.49 +tales casos que usted sabe lo que está haciendo y no imprime
    2.50 +información alguna.
    2.51 +
    2.52 +Cuando hacemos \emph{implícitos} los nombres de los archivos dando el
    2.53 +nombre de un directorio, Mercurial efectua un paso extra al imprimir
    2.54 +el nombre de cada archivo con el que va a hacer algo.  Esto para
    2.55 +aclarar lo que está sucediendo, y reducir en lo posible una sorpresa
    2.56 +silenciosa pero fatal.  Este comportamiento es común a la mayoría de
    2.57 +órdenes en Mercurial.
    2.58 +
    2.59 +\subsection{Nota al margen:Mercurial trata archivos, no directorios}
    2.60 +
    2.61 +Mercurial no da seguimiento a la información de los directorios.  En
    2.62 +lugar de eso tiene en cuenta las rutas de los archivos.  Antes  de
    2.63 +crear un archivo, primero crea todos los directorios que hagan falta
    2.64 +para completar la ruta del archivo. Después de borrar un archivo,
    2.65 +borra todos los directorios vacíos que estuvieran en la ruta del
    2.66 +archivo borrado. Suena como una diferencia trivial, pero tiene una
    2.67 +consecuencia práctica menor: no es posible representar un directorio
    2.68 +completamente vacío en Mercurial.
    2.69 +
    2.70 +Los directorios vacíos son inusualmente útiles, hay soluciones
    2.71 +alternativas no intrusivas que puede emplear para obtener el efecto
    2.72 +apropiado. Los desarrolladores de Mercurial pensaron que la
    2.73 +complejidad necesaria para administrar directorios vacíos no valía la
    2.74 +pena frente al beneficio limitado que esta característica podría traer.
    2.75 +
    2.76 +Si necesita un directorio vacío en su repositorio, hay algunas formas
    2.77 +de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a
    2.78 +un archivo ``escondido'' dentro de ese directorio. En sistemas tipo
    2.79 +Unix, cualquier archivo cuyo nombre comience con un punto
    2.80 +(``\texttt{.}'') se trata como escondido por la mayoría de
    2.81 +herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}.
    2.82 +
    2.83 +\begin{figure}[ht]
    2.84 +  \interaction{daily.files.hidden}
    2.85 +  \caption{Simular un directorio vacío con un archivo escondido}
    2.86 +  \label{ex:daily:hidden}
    2.87 +\end{figure}
    2.88 +
    2.89 +Otra forma de abordar la necesidad de un archivo vacío es crear
    2.90 +simplemente uno en sus guiones de construcción antes de ser necesarios.
    2.91 +
    2.92 +\section{How to stop tracking a file}
    2.93 +
    2.94 +Once you decide that a file no longer belongs in your repository, use
    2.95 +the \hgcmd{remove} command; this deletes the file, and tells Mercurial
    2.96 +to stop tracking it.  A removed file is represented in the output of
    2.97 +\hgcmd{status} with a ``\texttt{R}''.
    2.98 +\interaction{daily.files.remove}
    2.99 +
   2.100 +After you \hgcmd{remove} a file, Mercurial will no longer track
   2.101 +changes to that file, even if you recreate a file with the same name
   2.102 +in your working directory.  If you do recreate a file with the same
   2.103 +name and want Mercurial to track the new file, simply \hgcmd{add} it.
   2.104 +Mercurial will know that the newly added file is not related to the
   2.105 +old file of the same name.
   2.106 +
   2.107 +\subsection{Removing a file does not affect its history}
   2.108 +
   2.109 +It is important to understand that removing a file has only two
   2.110 +effects.
   2.111 +\begin{itemize}
   2.112 +\item It removes the current version of the file from the working
   2.113 +  directory.
   2.114 +\item It stops Mercurial from tracking changes to the file, from the
   2.115 +  time of the next commit.
   2.116 +\end{itemize}
   2.117 +Removing a file \emph{does not} in any way alter the \emph{history} of
   2.118 +the file.
   2.119 +
   2.120 +If you update the working directory to a changeset in which a file
   2.121 +that you have removed was still tracked, it will reappear in the
   2.122 +working directory, with the contents it had when you committed that
   2.123 +changeset.  If you then update the working directory to a later
   2.124 +changeset, in which the file had been removed, Mercurial will once
   2.125 +again remove the file from the working directory.
   2.126 +
   2.127 +\subsection{Missing files}
   2.128 +
   2.129 +Mercurial considers a file that you have deleted, but not used
   2.130 +\hgcmd{remove} to delete, to be \emph{missing}.  A missing file is
   2.131 +represented with ``\texttt{!}'' in the output of \hgcmd{status}.
   2.132 +Mercurial commands will not generally do anything with missing files.
   2.133 +\interaction{daily.files.missing}
   2.134 +
   2.135 +If your repository contains a file that \hgcmd{status} reports as
   2.136 +missing, and you want the file to stay gone, you can run
   2.137 +\hgcmdargs{remove}{\hgopt{remove}{--after}} at any time later on, to
   2.138 +tell Mercurial that you really did mean to remove the file.
   2.139 +\interaction{daily.files.remove-after}
   2.140 +
   2.141 +On the other hand, if you deleted the missing file by accident, use
   2.142 +\hgcmdargs{revert}{\emph{filename}} to recover the file.  It will
   2.143 +reappear, in unmodified form.
   2.144 +\interaction{daily.files.recover-missing}
   2.145 +
   2.146 +\subsection{Aside: why tell Mercurial explicitly to 
   2.147 +  remove a file?}
   2.148 +
   2.149 +You might wonder why Mercurial requires you to explicitly tell it that
   2.150 +you are deleting a file.  Early during the development of Mercurial,
   2.151 +it let you delete a file however you pleased; Mercurial would notice
   2.152 +the absence of the file automatically when you next ran a
   2.153 +\hgcmd{commit}, and stop tracking the file.  In practice, this made it
   2.154 +too easy to accidentally remove a file without noticing.
   2.155 +
   2.156 +\subsection{Useful shorthand---adding and removing files
   2.157 +  in one step}
   2.158 +
   2.159 +Mercurial offers a combination command, \hgcmd{addremove}, that adds
   2.160 +untracked files and marks missing files as removed.  
   2.161 +\interaction{daily.files.addremove}
   2.162 +The \hgcmd{commit} command also provides a \hgopt{commit}{-A} option
   2.163 +that performs this same add-and-remove, immediately followed by a
   2.164 +commit.
   2.165 +\interaction{daily.files.commit-addremove}
   2.166 +
   2.167 +\section{Copying files}
   2.168 +
   2.169 +Mercurial provides a \hgcmd{copy} command that lets you make a new
   2.170 +copy of a file.  When you copy a file using this command, Mercurial
   2.171 +makes a record of the fact that the new file is a copy of the original
   2.172 +file.  It treats these copied files specially when you merge your work
   2.173 +with someone else's.
   2.174 +
   2.175 +\subsection{The results of copying during a merge}
   2.176 +
   2.177 +What happens during a merge is that changes ``follow'' a copy.  To
   2.178 +best illustrate what this means, let's create an example.  We'll start
   2.179 +with the usual tiny repository that contains a single file.
   2.180 +\interaction{daily.copy.init}
   2.181 +We need to do some work in parallel, so that we'll have something to
   2.182 +merge.  So let's clone our repository.
   2.183 +\interaction{daily.copy.clone}
   2.184 +Back in our initial repository, let's use the \hgcmd{copy} command to
   2.185 +make a copy of the first file we created.
   2.186 +\interaction{daily.copy.copy}
   2.187 +
   2.188 +If we look at the output of the \hgcmd{status} command afterwards, the
   2.189 +copied file looks just like a normal added file.
   2.190 +\interaction{daily.copy.status}
   2.191 +But if we pass the \hgopt{status}{-C} option to \hgcmd{status}, it
   2.192 +prints another line of output: this is the file that our newly-added
   2.193 +file was copied \emph{from}.
   2.194 +\interaction{daily.copy.status-copy}
   2.195 +
   2.196 +Now, back in the repository we cloned, let's make a change in
   2.197 +parallel.  We'll add a line of content to the original file that we
   2.198 +created.
   2.199 +\interaction{daily.copy.other}
   2.200 +Now we have a modified \filename{file} in this repository.  When we
   2.201 +pull the changes from the first repository, and merge the two heads,
   2.202 +Mercurial will propagate the changes that we made locally to
   2.203 +\filename{file} into its copy, \filename{new-file}.
   2.204 +\interaction{daily.copy.merge}
   2.205 +
   2.206 +\subsection{Why should changes follow copies?}
   2.207 +\label{sec:daily:why-copy}
   2.208 +
   2.209 +This behaviour, of changes to a file propagating out to copies of the
   2.210 +file, might seem esoteric, but in most cases it's highly desirable.
   2.211 +
   2.212 +First of all, remember that this propagation \emph{only} happens when
   2.213 +you merge.  So if you \hgcmd{copy} a file, and subsequently modify the
   2.214 +original file during the normal course of your work, nothing will
   2.215 +happen.
   2.216 +
   2.217 +The second thing to know is that modifications will only propagate
   2.218 +across a copy as long as the repository that you're pulling changes
   2.219 +from \emph{doesn't know} about the copy.
   2.220 +
   2.221 +The reason that Mercurial does this is as follows.  Let's say I make
   2.222 +an important bug fix in a source file, and commit my changes.
   2.223 +Meanwhile, you've decided to \hgcmd{copy} the file in your repository,
   2.224 +without knowing about the bug or having seen the fix, and you have
   2.225 +started hacking on your copy of the file.
   2.226 +
   2.227 +If you pulled and merged my changes, and Mercurial \emph{didn't}
   2.228 +propagate changes across copies, your source file would now contain
   2.229 +the bug, and unless you remembered to propagate the bug fix by hand,
   2.230 +the bug would \emph{remain} in your copy of the file.
   2.231 +
   2.232 +By automatically propagating the change that fixed the bug from the
   2.233 +original file to the copy, Mercurial prevents this class of problem.
   2.234 +To my knowledge, Mercurial is the \emph{only} revision control system
   2.235 +that propagates changes across copies like this.
   2.236 +
   2.237 +Once your change history has a record that the copy and subsequent
   2.238 +merge occurred, there's usually no further need to propagate changes
   2.239 +from the original file to the copied file, and that's why Mercurial
   2.240 +only propagates changes across copies until this point, and no
   2.241 +further.
   2.242 +
   2.243 +\subsection{How to make changes \emph{not} follow a copy}
   2.244 +
   2.245 +If, for some reason, you decide that this business of automatically
   2.246 +propagating changes across copies is not for you, simply use your
   2.247 +system's normal file copy command (on Unix-like systems, that's
   2.248 +\command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
   2.249 +by hand.  Before you do so, though, please do reread
   2.250 +section~\ref{sec:daily:why-copy}, and make an informed decision that
   2.251 +this behaviour is not appropriate to your specific case.
   2.252 +
   2.253 +\subsection{Behaviour of the \hgcmd{copy} command}
   2.254 +
   2.255 +When you use the \hgcmd{copy} command, Mercurial makes a copy of each
   2.256 +source file as it currently stands in the working directory.  This
   2.257 +means that if you make some modifications to a file, then \hgcmd{copy}
   2.258 +it without first having committed those changes, the new copy will
   2.259 +also contain the modifications you have made up until that point.  (I
   2.260 +find this behaviour a little counterintuitive, which is why I mention
   2.261 +it here.)
   2.262 +
   2.263 +The \hgcmd{copy} command acts similarly to the Unix \command{cp}
   2.264 +command (you can use the \hgcmd{cp} alias if you prefer).  The last
   2.265 +argument is the \emph{destination}, and all prior arguments are
   2.266 +\emph{sources}.  If you pass it a single file as the source, and the
   2.267 +destination does not exist, it creates a new file with that name.
   2.268 +\interaction{daily.copy.simple}
   2.269 +If the destination is a directory, Mercurial copies its sources into
   2.270 +that directory.
   2.271 +\interaction{daily.copy.dir-dest}
   2.272 +Copying a directory is recursive, and preserves the directory
   2.273 +structure of the source.
   2.274 +\interaction{daily.copy.dir-src}
   2.275 +If the source and destination are both directories, the source tree is
   2.276 +recreated in the destination directory.
   2.277 +\interaction{daily.copy.dir-src-dest}
   2.278 +
   2.279 +As with the \hgcmd{rename} command, if you copy a file manually and
   2.280 +then want Mercurial to know that you've copied the file, simply use
   2.281 +the \hgopt{copy}{--after} option to \hgcmd{copy}.
   2.282 +\interaction{daily.copy.after}
   2.283 +
   2.284 +\section{Renaming files}
   2.285 +
   2.286 +It's rather more common to need to rename a file than to make a copy
   2.287 +of it.  The reason I discussed the \hgcmd{copy} command before talking
   2.288 +about renaming files is that Mercurial treats a rename in essentially
   2.289 +the same way as a copy.  Therefore, knowing what Mercurial does when
   2.290 +you copy a file tells you what to expect when you rename a file.
   2.291 +
   2.292 +When you use the \hgcmd{rename} command, Mercurial makes a copy of
   2.293 +each source file, then deletes it and marks the file as removed.
   2.294 +\interaction{daily.rename.rename}
   2.295 +The \hgcmd{status} command shows the newly copied file as added, and
   2.296 +the copied-from file as removed.
   2.297 +\interaction{daily.rename.status}
   2.298 +As with the results of a \hgcmd{copy}, we must use the
   2.299 +\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
   2.300 +is really being tracked by Mercurial as a copy of the original, now
   2.301 +removed, file.
   2.302 +\interaction{daily.rename.status-copy}
   2.303 +
   2.304 +As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
   2.305 +a rename after the fact using the \hgopt{rename}{--after} option.  In
   2.306 +most other respects, the behaviour of the \hgcmd{rename} command, and
   2.307 +the options it accepts, are similar to the \hgcmd{copy} command.
   2.308 +
   2.309 +\subsection{Renaming files and merging changes}
   2.310 +
   2.311 +Since Mercurial's rename is implemented as copy-and-remove, the same
   2.312 +propagation of changes happens when you merge after a rename as after
   2.313 +a copy.
   2.314 +
   2.315 +If I modify a file, and you rename it to a new name, and then we merge
   2.316 +our respective changes, my modifications to the file under its
   2.317 +original name will be propagated into the file under its new name.
   2.318 +(This is something you might expect to ``simply work,'' but not all
   2.319 +revision control systems actually do this.)
   2.320 +
   2.321 +Whereas having changes follow a copy is a feature where you can
   2.322 +perhaps nod and say ``yes, that might be useful,'' it should be clear
   2.323 +that having them follow a rename is definitely important.  Without
   2.324 +this facility, it would simply be too easy for changes to become
   2.325 +orphaned when files are renamed.
   2.326 +
   2.327 +\subsection{Divergent renames and merging}
   2.328 +
   2.329 +The case of diverging names occurs when two developers start with a
   2.330 +file---let's call it \filename{foo}---in their respective
   2.331 +repositories.
   2.332 +
   2.333 +\interaction{rename.divergent.clone}
   2.334 +Anne renames the file to \filename{bar}.
   2.335 +\interaction{rename.divergent.rename.anne}
   2.336 +Meanwhile, Bob renames it to \filename{quux}.
   2.337 +\interaction{rename.divergent.rename.bob}
   2.338 +
   2.339 +I like to think of this as a conflict because each developer has
   2.340 +expressed different intentions about what the file ought to be named.
   2.341 +
   2.342 +What do you think should happen when they merge their work?
   2.343 +Mercurial's actual behaviour is that it always preserves \emph{both}
   2.344 +names when it merges changesets that contain divergent renames.
   2.345 +\interaction{rename.divergent.merge}
   2.346 +
   2.347 +Notice that Mercurial does warn about the divergent renames, but it
   2.348 +leaves it up to you to do something about the divergence after the merge.
   2.349 +
   2.350 +\subsection{Convergent renames and merging}
   2.351 +
   2.352 +Another kind of rename conflict occurs when two people choose to
   2.353 +rename different \emph{source} files to the same \emph{destination}.
   2.354 +In this case, Mercurial runs its normal merge machinery, and lets you
   2.355 +guide it to a suitable resolution.
   2.356 +
   2.357 +\subsection{Other name-related corner cases}
   2.358 +
   2.359 +Mercurial has a longstanding bug in which it fails to handle a merge
   2.360 +where one side has a file with a given name, while another has a
   2.361 +directory with the same name.  This is documented as~\bug{29}.
   2.362 +\interaction{issue29.go}
   2.363 +
   2.364 +\section{Recovering from mistakes}
   2.365 +
   2.366 +Mercurial has some useful commands that will help you to recover from
   2.367 +some common mistakes.
   2.368 +
   2.369 +The \hgcmd{revert} command lets you undo changes that you have made to
   2.370 +your working directory.  For example, if you \hgcmd{add} a file by
   2.371 +accident, just run \hgcmd{revert} with the name of the file you added,
   2.372 +and while the file won't be touched in any way, it won't be tracked
   2.373 +for adding by Mercurial any longer, either.  You can also use
   2.374 +\hgcmd{revert} to get rid of erroneous changes to a file.
   2.375 +
   2.376 +It's useful to remember that the \hgcmd{revert} command is useful for
   2.377 +changes that you have not yet committed.  Once you've committed a
   2.378 +change, if you decide it was a mistake, you can still do something
   2.379 +about it, though your options may be more limited.
   2.380 +
   2.381 +For more information about the \hgcmd{revert} command, and details
   2.382 +about how to deal with changes you have already committed, see
   2.383 +chapter~\ref{chap:undo}.
   2.384 +
   2.385 +%%% Local Variables: 
   2.386 +%%% mode: latex
   2.387 +%%% TeX-master: "00book"
   2.388 +%%% End: