hgbook
diff en/daily.tex @ 118:1ee53cb37a99
More progress on daily work.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Wed Nov 15 12:12:36 2006 -0800 (2006-11-15) |
parents | 6b0f4498569e |
children | 9094c9fda8ec |
line diff
1.1 --- a/en/daily.tex Tue Nov 14 15:11:22 2006 -0800 1.2 +++ b/en/daily.tex Wed Nov 15 12:12:36 2006 -0800 1.3 @@ -90,6 +90,33 @@ 1.4 \hgcmd{status} with a ``\texttt{R}''. 1.5 \interaction{daily.files.remove} 1.6 1.7 +After you \hgcmd{remove} a file, Mercurial will no longer track 1.8 +changes to that file, even if you recreate a file with the same name 1.9 +in your working directory. If you do recreate a file with the same 1.10 +name and want Mercurial to track the new file, simply \hgcmd{add} it. 1.11 +Mercurial will know that the newly added file is not related to the 1.12 +old file of the same name. 1.13 + 1.14 +\subsection{Removing a file does not affect its history} 1.15 + 1.16 +It is important to understand that removing a file has only two 1.17 +effects. 1.18 +\begin{itemize} 1.19 +\item It removes the current version of the file from the working 1.20 + directory. 1.21 +\item It stops Mercurial from tracking changes to the file, from the 1.22 + time of the next commit. 1.23 +\end{itemize} 1.24 +Removing a file \emph{does not} in any way alter the \emph{history} of 1.25 +the file. 1.26 + 1.27 +If you update the working directory to a changeset in which a file 1.28 +that you have removed was still tracked, it will reappear in the 1.29 +working directory, with the contents it had when you committed that 1.30 +changeset. If you then update the working directory to a later 1.31 +changeset, in which the file had been removed, Mercurial will once 1.32 +again remove the file from the working directory. 1.33 + 1.34 \subsection{Missing files} 1.35 1.36 Mercurial considers a file that you have deleted, but not used 1.37 @@ -216,11 +243,17 @@ 1.38 1.39 \subsection{Behaviour of the \hgcmd{copy} command} 1.40 1.41 +When you use the \hgcmd{copy} command, Mercurial makes a copy of each 1.42 +source file as it currently stands in the working directory. This 1.43 +means that if you make some modifications to a file, then copy it 1.44 +without first having committed those changes, the new copy will 1.45 +contain your modifications. 1.46 + 1.47 The \hgcmd{copy} command acts similarly to the Unix \command{cp} 1.48 -command. The last argument is the \emph{destination}, and all prior 1.49 -arguments are \emph{sources}. 1.50 -If you pass it a single file as the source, and the destination 1.51 -does not exist, it creates a new file with that name. 1.52 +command (you can use the \hgcmd{cp} alias if you prefer). The last 1.53 +argument is the \emph{destination}, and all prior arguments are 1.54 +\emph{sources}. If you pass it a single file as the source, and the 1.55 +destination does not exist, it creates a new file with that name. 1.56 \interaction{daily.copy.simple} 1.57 If the destination is a directory, Mercurial copies its sources into 1.58 that directory. 1.59 @@ -232,18 +265,47 @@ 1.60 recreated in the destination directory. 1.61 \interaction{daily.copy.dir-src-dest} 1.62 1.63 +As with the \hgcmd{rename} command, if you copy a file manually and 1.64 +then want Mercurial to know that you've copied the file, simply use 1.65 +the \hgopt{--after} option to \hgcmd{copy}. 1.66 +\interaction{daily.copy.after} 1.67 + 1.68 \section{Renaming files} 1.69 1.70 -To rename a file that is tracked by Mercurial, use the \hgcmd{rename} 1.71 -command. This command behaves similarly to the Unix \command{mv} 1.72 -command (and in fact you can use the alias \hgcmd{mv} if you wish). 1.73 -If the last argument is a directory, \hgcmd{rename} moves all files 1.74 -identified by earlier arguments into that directory. Otherwise, it 1.75 -renames a single file or directory to the name given in the last 1.76 -argument. 1.77 - 1.78 -As with \hgcmd{remove}, you can tell Mercurial about a rename after 1.79 -the fact using the \hgopt{remove}{--after} option. 1.80 +It's rather more common to need to rename a file than to make a copy 1.81 +of it. The reason I discussed the \hgcmd{copy} command before talking 1.82 +about renaming files is that Mercurial treats a rename in essentially 1.83 +the same way as a copy. Therefore, knowing what Mercurial does when 1.84 +you copy a file tells you what to expect when you rename a file. 1.85 + 1.86 +When you use the \hgcmd{rename} command, Mercurial makes a copy of 1.87 +each source file, then deletes it and marks the file as removed. 1.88 +\interaction{daily.rename.rename} 1.89 +The \hgcmd{status} command shows the newly copied file as added, and 1.90 +the copied-from file as removed. 1.91 +\interaction{daily.rename.status} 1.92 +As with the results of a \hgcmd{copy}, we must use the 1.93 +\hgopt{status}{-C} option to \hgcmd{status} to see that the added file 1.94 +is really being tracked by Mercurial as a copy of the original, now 1.95 +removed, file. 1.96 +\interaction{daily.rename.status-copy} 1.97 + 1.98 +As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about 1.99 +a rename after the fact using the \hgopt{rename}{--after} option. In 1.100 +most other respects, the behaviour of the \hgcmd{rename} command, and 1.101 +the options it accepts, are similar to the \hgcmd{copy} command. 1.102 + 1.103 +\subsection{Renaming files and merging changes} 1.104 + 1.105 +Since Mercurial's rename is implemented as copy-and-remove, the same 1.106 +propagation of changes happens when you merge after a rename as after 1.107 +a copy. 1.108 + 1.109 +If I modify a file, and you rename it to a new name, then we merge our 1.110 +respective changes, my modifications to the file under its original 1.111 +name will be propagated into the file under its new name. (This is 1.112 +something you might expect to ``simply work,'' but not all revision 1.113 +control systems actually do this.) 1.114 1.115 %%% Local Variables: 1.116 %%% mode: latex