1.1 --- a/es/daily.tex	Sat Oct 18 07:48:21 2008 -0500
     1.2 +++ b/es/daily.tex	Mon Oct 20 04:01:59 2008 -0500
     1.3 @@ -0,0 +1,385 @@
     1.4 +\chapter{Mercurial día a día}
     1.5 +\label{chap:daily}
     1.6 +
     1.7 +\section{Cómo indicarle a Mercurial qué archivos seguir}
     1.8 +
     1.9 +Mercurial no trabaja con archivos en su repositorio a menos que usted
    1.10 +explícitamente se lo indique.  La orden \hgcmd{status} le mostrará
    1.11 +cuáles archivos son desconocidos para Mercurial; emplea un
    1.12 +``\texttt{?}'' para mostrar tales archivos.
    1.13 +
    1.14 +Para indicarle a Mercurial que tenga en cuenta un archivo, emplee la
    1.15 +orden \hgcmd{add}. Una vez que haya adicionado el archivo, la línea
    1.16 +referente al archivo al aplicar la orden \hgcmd{status} para tal
    1.17 +archivo cambia de ``\texttt{?}'' a ``\texttt{A}''.
    1.18 +\interaction{daily.files.add}
    1.19 +
    1.20 +Después de invocar \hgcmd{commit}, los archivos que haya adicionado
    1.21 +antes de consignar no se listarán en la salida de \hgcmd{status}.  La
    1.22 +razón para esto es que \hgcmd{status} solamente le muestra aquellos
    1.23 +archivos ``interesantes''---los que usted haya modificado o a aquellos
    1.24 +sobre los que usted haya indicado a Mercurial hacerles algo---de forma
    1.25 +predeterminada. Si tiene un repositorio que contiene miles de
    1.26 +archivos, inusualmente deseará saber cuáles de ellos están siendo
    1.27 +seguidos por Mercurial, pero que no han cambiado.  (De todas maneras,
    1.28 +puede obtener tal información; más adelante hablaremos de ello.)
    1.29 +
    1.30 +
    1.31 +Cuando usted añade un archivo, Mercurial no hace nada con el inmediatamente.
    1.32 +A cambio, tomará una instantánea del estado del archivo la próxima vez
    1.33 +que usted consigne. Continuará haciendo seguimiento a los cambios que
    1.34 +haga sobre el archivo cada vez que consigne, hasta que usted lo elimine.
    1.35 +
    1.36 +\subsection{Nombramiento explicíto e implícito de archivos}
    1.37 +
    1.38 +Mercurial tiene un comportamiento útil en el cual si a una orden,
    1.39 +le pasa el nombre de un directorio, todas las órdenes lo tratarán como
    1.40 +``Deseo operar en cada archivo de este directorio y sus 
    1.41 +subdirectorios''.
    1.42 +\interaction{daily.files.add-dir}
    1.43 +Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de
    1.44 +los archivos que se adicionaron, mientras que no lo hizo en el ejemplo
    1.45 +anterior cuando adicionamos el archivo con nombre \filename{a}.
    1.46 +
    1.47 +En el último caso hicimos explícito el nombre del archivo que
    1.48 +deseábamos adicionar en la línea de órdenes, y Mercurial asume en
    1.49 +tales casos que usted sabe lo que está haciendo y no imprime
    1.50 +información alguna.
    1.51 +
    1.52 +Cuando hacemos \emph{implícitos} los nombres de los archivos dando el
    1.53 +nombre de un directorio, Mercurial efectua un paso extra al imprimir
    1.54 +el nombre de cada archivo con el que va a hacer algo.  Esto para
    1.55 +aclarar lo que está sucediendo, y reducir en lo posible una sorpresa
    1.56 +silenciosa pero fatal.  Este comportamiento es común a la mayoría de
    1.57 +órdenes en Mercurial.
    1.58 +
    1.59 +\subsection{Nota al margen:Mercurial trata archivos, no directorios}
    1.60 +
    1.61 +Mercurial no da seguimiento a la información de los directorios.  En
    1.62 +lugar de eso tiene en cuenta las rutas de los archivos.  Antes  de
    1.63 +crear un archivo, primero crea todos los directorios que hagan falta
    1.64 +para completar la ruta del archivo. Después de borrar un archivo,
    1.65 +borra todos los directorios vacíos que estuvieran en la ruta del
    1.66 +archivo borrado. Suena como una diferencia trivial, pero tiene una
    1.67 +consecuencia práctica menor: no es posible representar un directorio
    1.68 +completamente vacío en Mercurial.
    1.69 +
    1.70 +Los directorios vacíos son inusualmente útiles, hay soluciones
    1.71 +alternativas no intrusivas que puede emplear para obtener el efecto
    1.72 +apropiado. Los desarrolladores de Mercurial pensaron que la
    1.73 +complejidad necesaria para administrar directorios vacíos no valía la
    1.74 +pena frente al beneficio limitado que esta característica podría traer.
    1.75 +
    1.76 +Si necesita un directorio vacío en su repositorio, hay algunas formas
    1.77 +de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a
    1.78 +un archivo ``escondido'' dentro de ese directorio. En sistemas tipo
    1.79 +Unix, cualquier archivo cuyo nombre comience con un punto
    1.80 +(``\texttt{.}'') se trata como escondido por la mayoría de
    1.81 +herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}.
    1.82 +
    1.83 +\begin{figure}[ht]
    1.84 +  \interaction{daily.files.hidden}
    1.85 +  \caption{Simular un directorio vacío con un archivo escondido}
    1.86 +  \label{ex:daily:hidden}
    1.87 +\end{figure}
    1.88 +
    1.89 +Otra forma de abordar la necesidad de un archivo vacío es crear
    1.90 +simplemente uno en sus guiones de construcción antes de ser necesarios.
    1.91 +
    1.92 +\section{How to stop tracking a file}
    1.93 +
    1.94 +Once you decide that a file no longer belongs in your repository, use
    1.95 +the \hgcmd{remove} command; this deletes the file, and tells Mercurial
    1.96 +to stop tracking it.  A removed file is represented in the output of
    1.97 +\hgcmd{status} with a ``\texttt{R}''.
    1.98 +\interaction{daily.files.remove}
    1.99 +
   1.100 +After you \hgcmd{remove} a file, Mercurial will no longer track
   1.101 +changes to that file, even if you recreate a file with the same name
   1.102 +in your working directory.  If you do recreate a file with the same
   1.103 +name and want Mercurial to track the new file, simply \hgcmd{add} it.
   1.104 +Mercurial will know that the newly added file is not related to the
   1.105 +old file of the same name.
   1.106 +
   1.107 +\subsection{Removing a file does not affect its history}
   1.108 +
   1.109 +It is important to understand that removing a file has only two
   1.110 +effects.
   1.111 +\begin{itemize}
   1.112 +\item It removes the current version of the file from the working
   1.113 +  directory.
   1.114 +\item It stops Mercurial from tracking changes to the file, from the
   1.115 +  time of the next commit.
   1.116 +\end{itemize}
   1.117 +Removing a file \emph{does not} in any way alter the \emph{history} of
   1.118 +the file.
   1.119 +
   1.120 +If you update the working directory to a changeset in which a file
   1.121 +that you have removed was still tracked, it will reappear in the
   1.122 +working directory, with the contents it had when you committed that
   1.123 +changeset.  If you then update the working directory to a later
   1.124 +changeset, in which the file had been removed, Mercurial will once
   1.125 +again remove the file from the working directory.
   1.126 +
   1.127 +\subsection{Missing files}
   1.128 +
   1.129 +Mercurial considers a file that you have deleted, but not used
   1.130 +\hgcmd{remove} to delete, to be \emph{missing}.  A missing file is
   1.131 +represented with ``\texttt{!}'' in the output of \hgcmd{status}.
   1.132 +Mercurial commands will not generally do anything with missing files.
   1.133 +\interaction{daily.files.missing}
   1.134 +
   1.135 +If your repository contains a file that \hgcmd{status} reports as
   1.136 +missing, and you want the file to stay gone, you can run
   1.137 +\hgcmdargs{remove}{\hgopt{remove}{--after}} at any time later on, to
   1.138 +tell Mercurial that you really did mean to remove the file.
   1.139 +\interaction{daily.files.remove-after}
   1.140 +
   1.141 +On the other hand, if you deleted the missing file by accident, use
   1.142 +\hgcmdargs{revert}{\emph{filename}} to recover the file.  It will
   1.143 +reappear, in unmodified form.
   1.144 +\interaction{daily.files.recover-missing}
   1.145 +
   1.146 +\subsection{Aside: why tell Mercurial explicitly to 
   1.147 +  remove a file?}
   1.148 +
   1.149 +You might wonder why Mercurial requires you to explicitly tell it that
   1.150 +you are deleting a file.  Early during the development of Mercurial,
   1.151 +it let you delete a file however you pleased; Mercurial would notice
   1.152 +the absence of the file automatically when you next ran a
   1.153 +\hgcmd{commit}, and stop tracking the file.  In practice, this made it
   1.154 +too easy to accidentally remove a file without noticing.
   1.155 +
   1.156 +\subsection{Useful shorthand---adding and removing files
   1.157 +  in one step}
   1.158 +
   1.159 +Mercurial offers a combination command, \hgcmd{addremove}, that adds
   1.160 +untracked files and marks missing files as removed.  
   1.161 +\interaction{daily.files.addremove}
   1.162 +The \hgcmd{commit} command also provides a \hgopt{commit}{-A} option
   1.163 +that performs this same add-and-remove, immediately followed by a
   1.164 +commit.
   1.165 +\interaction{daily.files.commit-addremove}
   1.166 +
   1.167 +\section{Copying files}
   1.168 +
   1.169 +Mercurial provides a \hgcmd{copy} command that lets you make a new
   1.170 +copy of a file.  When you copy a file using this command, Mercurial
   1.171 +makes a record of the fact that the new file is a copy of the original
   1.172 +file.  It treats these copied files specially when you merge your work
   1.173 +with someone else's.
   1.174 +
   1.175 +\subsection{The results of copying during a merge}
   1.176 +
   1.177 +What happens during a merge is that changes ``follow'' a copy.  To
   1.178 +best illustrate what this means, let's create an example.  We'll start
   1.179 +with the usual tiny repository that contains a single file.
   1.180 +\interaction{daily.copy.init}
   1.181 +We need to do some work in parallel, so that we'll have something to
   1.182 +merge.  So let's clone our repository.
   1.183 +\interaction{daily.copy.clone}
   1.184 +Back in our initial repository, let's use the \hgcmd{copy} command to
   1.185 +make a copy of the first file we created.
   1.186 +\interaction{daily.copy.copy}
   1.187 +
   1.188 +If we look at the output of the \hgcmd{status} command afterwards, the
   1.189 +copied file looks just like a normal added file.
   1.190 +\interaction{daily.copy.status}
   1.191 +But if we pass the \hgopt{status}{-C} option to \hgcmd{status}, it
   1.192 +prints another line of output: this is the file that our newly-added
   1.193 +file was copied \emph{from}.
   1.194 +\interaction{daily.copy.status-copy}
   1.195 +
   1.196 +Now, back in the repository we cloned, let's make a change in
   1.197 +parallel.  We'll add a line of content to the original file that we
   1.198 +created.
   1.199 +\interaction{daily.copy.other}
   1.200 +Now we have a modified \filename{file} in this repository.  When we
   1.201 +pull the changes from the first repository, and merge the two heads,
   1.202 +Mercurial will propagate the changes that we made locally to
   1.203 +\filename{file} into its copy, \filename{new-file}.
   1.204 +\interaction{daily.copy.merge}
   1.205 +
   1.206 +\subsection{Why should changes follow copies?}
   1.207 +\label{sec:daily:why-copy}
   1.208 +
   1.209 +This behaviour, of changes to a file propagating out to copies of the
   1.210 +file, might seem esoteric, but in most cases it's highly desirable.
   1.211 +
   1.212 +First of all, remember that this propagation \emph{only} happens when
   1.213 +you merge.  So if you \hgcmd{copy} a file, and subsequently modify the
   1.214 +original file during the normal course of your work, nothing will
   1.215 +happen.
   1.216 +
   1.217 +The second thing to know is that modifications will only propagate
   1.218 +across a copy as long as the repository that you're pulling changes
   1.219 +from \emph{doesn't know} about the copy.
   1.220 +
   1.221 +The reason that Mercurial does this is as follows.  Let's say I make
   1.222 +an important bug fix in a source file, and commit my changes.
   1.223 +Meanwhile, you've decided to \hgcmd{copy} the file in your repository,
   1.224 +without knowing about the bug or having seen the fix, and you have
   1.225 +started hacking on your copy of the file.
   1.226 +
   1.227 +If you pulled and merged my changes, and Mercurial \emph{didn't}
   1.228 +propagate changes across copies, your source file would now contain
   1.229 +the bug, and unless you remembered to propagate the bug fix by hand,
   1.230 +the bug would \emph{remain} in your copy of the file.
   1.231 +
   1.232 +By automatically propagating the change that fixed the bug from the
   1.233 +original file to the copy, Mercurial prevents this class of problem.
   1.234 +To my knowledge, Mercurial is the \emph{only} revision control system
   1.235 +that propagates changes across copies like this.
   1.236 +
   1.237 +Once your change history has a record that the copy and subsequent
   1.238 +merge occurred, there's usually no further need to propagate changes
   1.239 +from the original file to the copied file, and that's why Mercurial
   1.240 +only propagates changes across copies until this point, and no
   1.241 +further.
   1.242 +
   1.243 +\subsection{How to make changes \emph{not} follow a copy}
   1.244 +
   1.245 +If, for some reason, you decide that this business of automatically
   1.246 +propagating changes across copies is not for you, simply use your
   1.247 +system's normal file copy command (on Unix-like systems, that's
   1.248 +\command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
   1.249 +by hand.  Before you do so, though, please do reread
   1.250 +section~\ref{sec:daily:why-copy}, and make an informed decision that
   1.251 +this behaviour is not appropriate to your specific case.
   1.252 +
   1.253 +\subsection{Behaviour of the \hgcmd{copy} command}
   1.254 +
   1.255 +When you use the \hgcmd{copy} command, Mercurial makes a copy of each
   1.256 +source file as it currently stands in the working directory.  This
   1.257 +means that if you make some modifications to a file, then \hgcmd{copy}
   1.258 +it without first having committed those changes, the new copy will
   1.259 +also contain the modifications you have made up until that point.  (I
   1.260 +find this behaviour a little counterintuitive, which is why I mention
   1.261 +it here.)
   1.262 +
   1.263 +The \hgcmd{copy} command acts similarly to the Unix \command{cp}
   1.264 +command (you can use the \hgcmd{cp} alias if you prefer).  The last
   1.265 +argument is the \emph{destination}, and all prior arguments are
   1.266 +\emph{sources}.  If you pass it a single file as the source, and the
   1.267 +destination does not exist, it creates a new file with that name.
   1.268 +\interaction{daily.copy.simple}
   1.269 +If the destination is a directory, Mercurial copies its sources into
   1.270 +that directory.
   1.271 +\interaction{daily.copy.dir-dest}
   1.272 +Copying a directory is recursive, and preserves the directory
   1.273 +structure of the source.
   1.274 +\interaction{daily.copy.dir-src}
   1.275 +If the source and destination are both directories, the source tree is
   1.276 +recreated in the destination directory.
   1.277 +\interaction{daily.copy.dir-src-dest}
   1.278 +
   1.279 +As with the \hgcmd{rename} command, if you copy a file manually and
   1.280 +then want Mercurial to know that you've copied the file, simply use
   1.281 +the \hgopt{copy}{--after} option to \hgcmd{copy}.
   1.282 +\interaction{daily.copy.after}
   1.283 +
   1.284 +\section{Renaming files}
   1.285 +
   1.286 +It's rather more common to need to rename a file than to make a copy
   1.287 +of it.  The reason I discussed the \hgcmd{copy} command before talking
   1.288 +about renaming files is that Mercurial treats a rename in essentially
   1.289 +the same way as a copy.  Therefore, knowing what Mercurial does when
   1.290 +you copy a file tells you what to expect when you rename a file.
   1.291 +
   1.292 +When you use the \hgcmd{rename} command, Mercurial makes a copy of
   1.293 +each source file, then deletes it and marks the file as removed.
   1.294 +\interaction{daily.rename.rename}
   1.295 +The \hgcmd{status} command shows the newly copied file as added, and
   1.296 +the copied-from file as removed.
   1.297 +\interaction{daily.rename.status}
   1.298 +As with the results of a \hgcmd{copy}, we must use the
   1.299 +\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
   1.300 +is really being tracked by Mercurial as a copy of the original, now
   1.301 +removed, file.
   1.302 +\interaction{daily.rename.status-copy}
   1.303 +
   1.304 +As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
   1.305 +a rename after the fact using the \hgopt{rename}{--after} option.  In
   1.306 +most other respects, the behaviour of the \hgcmd{rename} command, and
   1.307 +the options it accepts, are similar to the \hgcmd{copy} command.
   1.308 +
   1.309 +\subsection{Renaming files and merging changes}
   1.310 +
   1.311 +Since Mercurial's rename is implemented as copy-and-remove, the same
   1.312 +propagation of changes happens when you merge after a rename as after
   1.313 +a copy.
   1.314 +
   1.315 +If I modify a file, and you rename it to a new name, and then we merge
   1.316 +our respective changes, my modifications to the file under its
   1.317 +original name will be propagated into the file under its new name.
   1.318 +(This is something you might expect to ``simply work,'' but not all
   1.319 +revision control systems actually do this.)
   1.320 +
   1.321 +Whereas having changes follow a copy is a feature where you can
   1.322 +perhaps nod and say ``yes, that might be useful,'' it should be clear
   1.323 +that having them follow a rename is definitely important.  Without
   1.324 +this facility, it would simply be too easy for changes to become
   1.325 +orphaned when files are renamed.
   1.326 +
   1.327 +\subsection{Divergent renames and merging}
   1.328 +
   1.329 +The case of diverging names occurs when two developers start with a
   1.330 +file---let's call it \filename{foo}---in their respective
   1.331 +repositories.
   1.332 +
   1.333 +\interaction{rename.divergent.clone}
   1.334 +Anne renames the file to \filename{bar}.
   1.335 +\interaction{rename.divergent.rename.anne}
   1.336 +Meanwhile, Bob renames it to \filename{quux}.
   1.337 +\interaction{rename.divergent.rename.bob}
   1.338 +
   1.339 +I like to think of this as a conflict because each developer has
   1.340 +expressed different intentions about what the file ought to be named.
   1.341 +
   1.342 +What do you think should happen when they merge their work?
   1.343 +Mercurial's actual behaviour is that it always preserves \emph{both}
   1.344 +names when it merges changesets that contain divergent renames.
   1.345 +\interaction{rename.divergent.merge}
   1.346 +
   1.347 +Notice that Mercurial does warn about the divergent renames, but it
   1.348 +leaves it up to you to do something about the divergence after the merge.
   1.349 +
   1.350 +\subsection{Convergent renames and merging}
   1.351 +
   1.352 +Another kind of rename conflict occurs when two people choose to
   1.353 +rename different \emph{source} files to the same \emph{destination}.
   1.354 +In this case, Mercurial runs its normal merge machinery, and lets you
   1.355 +guide it to a suitable resolution.
   1.356 +
   1.357 +\subsection{Other name-related corner cases}
   1.358 +
   1.359 +Mercurial has a longstanding bug in which it fails to handle a merge
   1.360 +where one side has a file with a given name, while another has a
   1.361 +directory with the same name.  This is documented as~\bug{29}.
   1.362 +\interaction{issue29.go}
   1.363 +
   1.364 +\section{Recovering from mistakes}
   1.365 +
   1.366 +Mercurial has some useful commands that will help you to recover from
   1.367 +some common mistakes.
   1.368 +
   1.369 +The \hgcmd{revert} command lets you undo changes that you have made to
   1.370 +your working directory.  For example, if you \hgcmd{add} a file by
   1.371 +accident, just run \hgcmd{revert} with the name of the file you added,
   1.372 +and while the file won't be touched in any way, it won't be tracked
   1.373 +for adding by Mercurial any longer, either.  You can also use
   1.374 +\hgcmd{revert} to get rid of erroneous changes to a file.
   1.375 +
   1.376 +It's useful to remember that the \hgcmd{revert} command is useful for
   1.377 +changes that you have not yet committed.  Once you've committed a
   1.378 +change, if you decide it was a mistake, you can still do something
   1.379 +about it, though your options may be more limited.
   1.380 +
   1.381 +For more information about the \hgcmd{revert} command, and details
   1.382 +about how to deal with changes you have already committed, see
   1.383 +chapter~\ref{chap:undo}.
   1.384 +
   1.385 +%%% Local Variables: 
   1.386 +%%% mode: latex
   1.387 +%%% TeX-master: "00book"
   1.388 +%%% End: