hgbook
changeset 345:6595729623f9
Instructions on contribute start daily.tex translation. Added words to Leame.1st
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Mon Oct 20 04:01:59 2008 -0500 (2008-10-20) |
parents | cbffdb4dde82 |
children | 6d899c80bfb5 d8596cd12b41 |
files | es/Leame.1st es/daily.tex |
line diff
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: