1.1 --- a/en/Makefile	Tue Nov 14 15:11:22 2006 -0800
     1.2 +++ b/en/Makefile	Wed Nov 15 12:12:36 2006 -0800
     1.3 @@ -43,6 +43,7 @@
     1.4  example-sources := \
     1.5  	daily.copy \
     1.6  	daily.files \
     1.7 +	daily.rename \
     1.8  	hook.msglen \
     1.9  	hook.simple \
    1.10  	hook.ws \

     2.1 --- a/en/daily.tex	Tue Nov 14 15:11:22 2006 -0800
     2.2 +++ b/en/daily.tex	Wed Nov 15 12:12:36 2006 -0800
     2.3 @@ -90,6 +90,33 @@
     2.4  \hgcmd{status} with a ``\texttt{R}''.
     2.5  \interaction{daily.files.remove}
     2.6  
     2.7 +After you \hgcmd{remove} a file, Mercurial will no longer track
     2.8 +changes to that file, even if you recreate a file with the same name
     2.9 +in your working directory.  If you do recreate a file with the same
    2.10 +name and want Mercurial to track the new file, simply \hgcmd{add} it.
    2.11 +Mercurial will know that the newly added file is not related to the
    2.12 +old file of the same name.
    2.13 +
    2.14 +\subsection{Removing a file does not affect its history}
    2.15 +
    2.16 +It is important to understand that removing a file has only two
    2.17 +effects.
    2.18 +\begin{itemize}
    2.19 +\item It removes the current version of the file from the working
    2.20 +  directory.
    2.21 +\item It stops Mercurial from tracking changes to the file, from the
    2.22 +  time of the next commit.
    2.23 +\end{itemize}
    2.24 +Removing a file \emph{does not} in any way alter the \emph{history} of
    2.25 +the file.
    2.26 +
    2.27 +If you update the working directory to a changeset in which a file
    2.28 +that you have removed was still tracked, it will reappear in the
    2.29 +working directory, with the contents it had when you committed that
    2.30 +changeset.  If you then update the working directory to a later
    2.31 +changeset, in which the file had been removed, Mercurial will once
    2.32 +again remove the file from the working directory.
    2.33 +
    2.34  \subsection{Missing files}
    2.35  
    2.36  Mercurial considers a file that you have deleted, but not used
    2.37 @@ -216,11 +243,17 @@
    2.38  
    2.39  \subsection{Behaviour of the \hgcmd{copy} command}
    2.40  
    2.41 +When you use the \hgcmd{copy} command, Mercurial makes a copy of each
    2.42 +source file as it currently stands in the working directory.  This
    2.43 +means that if you make some modifications to a file, then copy it
    2.44 +without first having committed those changes, the new copy will
    2.45 +contain your modifications.
    2.46 +
    2.47  The \hgcmd{copy} command acts similarly to the Unix \command{cp}
    2.48 -command.  The last argument is the \emph{destination}, and all prior
    2.49 -arguments are \emph{sources}.
    2.50 -If you pass it a single file as the source, and the destination
    2.51 -does not exist, it creates a new file with that name.
    2.52 +command (you can use the \hgcmd{cp} alias if you prefer).  The last
    2.53 +argument is the \emph{destination}, and all prior arguments are
    2.54 +\emph{sources}.  If you pass it a single file as the source, and the
    2.55 +destination does not exist, it creates a new file with that name.
    2.56  \interaction{daily.copy.simple}
    2.57  If the destination is a directory, Mercurial copies its sources into
    2.58  that directory.
    2.59 @@ -232,18 +265,47 @@
    2.60  recreated in the destination directory.
    2.61  \interaction{daily.copy.dir-src-dest}
    2.62  
    2.63 +As with the \hgcmd{rename} command, if you copy a file manually and
    2.64 +then want Mercurial to know that you've copied the file, simply use
    2.65 +the \hgopt{--after} option to \hgcmd{copy}.
    2.66 +\interaction{daily.copy.after}
    2.67 +
    2.68  \section{Renaming files}
    2.69  
    2.70 -To rename a file that is tracked by Mercurial, use the \hgcmd{rename}
    2.71 -command.  This command behaves similarly to the Unix \command{mv}
    2.72 -command (and in fact you can use the alias \hgcmd{mv} if you wish).
    2.73 -If the last argument is a directory, \hgcmd{rename} moves all files
    2.74 -identified by earlier arguments into that directory.  Otherwise, it
    2.75 -renames a single file or directory to the name given in the last
    2.76 -argument.
    2.77 -
    2.78 -As with \hgcmd{remove}, you can tell Mercurial about a rename after
    2.79 -the fact using the \hgopt{remove}{--after} option.
    2.80 +It's rather more common to need to rename a file than to make a copy
    2.81 +of it.  The reason I discussed the \hgcmd{copy} command before talking
    2.82 +about renaming files is that Mercurial treats a rename in essentially
    2.83 +the same way as a copy.  Therefore, knowing what Mercurial does when
    2.84 +you copy a file tells you what to expect when you rename a file.
    2.85 +
    2.86 +When you use the \hgcmd{rename} command, Mercurial makes a copy of
    2.87 +each source file, then deletes it and marks the file as removed.
    2.88 +\interaction{daily.rename.rename}
    2.89 +The \hgcmd{status} command shows the newly copied file as added, and
    2.90 +the copied-from file as removed.
    2.91 +\interaction{daily.rename.status}
    2.92 +As with the results of a \hgcmd{copy}, we must use the
    2.93 +\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
    2.94 +is really being tracked by Mercurial as a copy of the original, now
    2.95 +removed, file.
    2.96 +\interaction{daily.rename.status-copy}
    2.97 +
    2.98 +As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
    2.99 +a rename after the fact using the \hgopt{rename}{--after} option.  In
   2.100 +most other respects, the behaviour of the \hgcmd{rename} command, and
   2.101 +the options it accepts, are similar to the \hgcmd{copy} command.
   2.102 +
   2.103 +\subsection{Renaming files and merging changes}
   2.104 +
   2.105 +Since Mercurial's rename is implemented as copy-and-remove, the same
   2.106 +propagation of changes happens when you merge after a rename as after
   2.107 +a copy.
   2.108 +
   2.109 +If I modify a file, and you rename it to a new name, then we merge our
   2.110 +respective changes, my modifications to the file under its original
   2.111 +name will be propagated into the file under its new name.  (This is
   2.112 +something you might expect to ``simply work,'' but not all revision
   2.113 +control systems actually do this.)
   2.114  
   2.115  %%% Local Variables: 
   2.116  %%% mode: latex

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/en/examples/daily.rename	Wed Nov 15 12:12:36 2006 -0800
     3.3 @@ -0,0 +1,18 @@
     3.4 +#!/bin/bash
     3.5 +
     3.6 +hg init a
     3.7 +cd a
     3.8 +echo a > a
     3.9 +hg ci -Ama
    3.10 +
    3.11 +#$ name: rename
    3.12 +
    3.13 +hg rename a b
    3.14 +
    3.15 +#$ name: status
    3.16 +
    3.17 +hg status
    3.18 +
    3.19 +#$ name: status-copy
    3.20 +
    3.21 +hg status -C