comparison ja/tour-basic.tex @ 786:11bc9d788428

finished tour-basic.tex

785:7dd855842de4

%refer to ``a~\emph{specific} changeset'' is of great importance.
%Recall that the \texttt{changeset} field in the output from
%\hgcmd{log} identifies a changeset using both a number and a
%hexadecimal string.

\emph{$BMQ8l(B}

%\begin{itemize}
%\item The revision number is \emph{only valid in that repository},
%\item while the hex string is the \emph{permanent, unchanging
%    identifier} that will always identify that exact changeset in

%arrived in a repository, and there is no guarantee that the same
%changes will happen in the same order in different repositories.
%Three changes $a,b,c$ can easily appear in one repository as $0,1,2$,
%while in another as $1,0,2$.

$B$3$N6hJL$O=EMW$G$"$k!%(B``revision~33''


%Mercurial uses revision numbers purely as a convenient shorthand.  If
%you need to discuss a changeset with someone, or make a record of a
%changeset for some other reason (for example, in a bug report), use
%the hexadecimal identifier.

Mercurial$B$O%j%S%8%g%sHV9f$rC1$KJXMx$N$?$a$NN,5-J}$H$7$FMQ$$$k!%C/$+$H%A%'(B
$B%s%8%;%C%H$K$D$$$F5DO@$7$?$j!$!J%P%0Js9p$J$I$N$?$a$K!K%A%'%s%8%;%C%H$r5-(B
$BO?$7$?$$>l9g$O(B16$B?J$N<1JL;R$rMxMQ$9$Y$-$G$"$k!%(B




%\subsection{Viewing specific revisions}
\subsection{$BFCDj$N%j%S%8%g%s$r8+$k(B}

%To narrow the output of \hgcmd{log} down to a single revision, use the
%\hgopt{log}{-r} (or \hgopt{log}{--rev}) option.  You can use either a
%revision number or a long-form changeset identifier, and you can
%provide as many revisions as you want.  \interaction{tour.log-r}

%If you want to see the history of several revisions without having to
%list each one, you can use \emph{range notation}; this lets you
%express the idea ``I want all revisions between $a$ and $b$,
%inclusive''.
%\interaction{tour.log.range}
%Mercurial also honours the order in which you specify revisions, so
%\hgcmdargs{log}{-r 2:4} prints $2,3,4$ while \hgcmdargs{log}{-r 4:2}
%prints $4,3,2$.

%\subsection{More detailed information}
\subsection{$B$h$j>\:Y$J>pJs(B}

%While the summary information printed by \hgcmd{log} is useful if you
%already know what you're looking for, you may need to see a complete

%trying to decide whether a changeset is the one you're looking for.
%The \hgcmd{log} command's \hggopt{-v} (or \hggopt{--verbose})
%option gives you this extra detail.
%\interaction{tour.log-v}

%If you want to see both the description and content of a change, add
%the \hgopt{log}{-p} (or \hgopt{log}{--patch}) option.  This displays
%the content of a change as a \emph{unified diff} (if you've never seen
%a unified diff before, see section~\ref{sec:mq:patch} for an overview).
%\interaction{tour.log-vp}

%\section{All about command options}
\section{$B%3%^%s%I%*%W%7%g%s$N$9$Y$F(B}

%Let's take a brief break from exploring Mercurial commands to discuss
%a pattern in the way that they work; you may find this useful to keep
%in mind as we continue our tour.

%Mercurial has a consistent and straightforward approach to dealing
%with the options that you can pass to commands.  It follows the
%conventions for options that are common to modern Linux and Unix
%systems.
%\begin{itemize}
%\item Every option has a long name.  For example, as we've already
%  seen, the \hgcmd{log} command accepts a \hgopt{log}{--rev} option.
%\item Most options have short names, too.  Instead of
%  \hgopt{log}{--rev}, we can use \hgopt{log}{-r}.  (The reason that
%  some options don't have short names is that the options in question
%  are rarely used.)
%\item Long options start with two dashes (e.g.~\hgopt{log}{--rev}),
%  while short options start with one (e.g.~\hgopt{log}{-r}).
%\item Option naming and usage is consistent across commands.  For
%  example, every command that lets you specify a changeset~ID or
%  revision number accepts both \hgopt{log}{-r} and \hgopt{log}{--rev}
%  arguments.
%\end{itemize}
%In the examples throughout this book, I use short options instead of
%long.  This just reflects my own preference, so don't read anything
%significant into it.

%Most commands that print output of some kind will print more output
%when passed a \hggopt{-v} (or \hggopt{--verbose}) option, and less
%when passed \hggopt{-q} (or \hggopt{--quiet}).

%\section{Making and reviewing changes}
\section{$BJQ99$N;EJ}!$JQ99$N%l%S%e!<(B}

%Now that we have a grasp of viewing history in Mercurial, let's take a
%look at making some changes and examining them.

%The first thing we'll do is isolate our experiment in a repository of
%its own.  We use the \hgcmd{clone} command, but we don't need to
%clone a copy of the remote repository.  Since we already have a copy
%of it locally, we can just clone that instead.  This is much faster

%work on multiple tasks in parallel, each isolated from the others
%until it's complete and you're ready to integrate it back.  Because
%local clones are so cheap, there's almost no overhead to cloning and
%destroying repositories whenever you want.

%In our \dirname{my-hello} repository, we have a file
%\filename{hello.c} that contains the classic ``hello, world'' program.
%Let's use the ancient and venerable \command{sed} command to edit this
%file so that it prints a second line of output.  (I'm only using
%\command{sed} to do this because it's easy to write a scripted example
%this way.  Since you're not under the same constraint, you probably
%won't want to use \command{sed}; simply use your preferred text editor to
%do the same thing.)
%\interaction{tour.sed}

%Mercurial's \hgcmd{status} command will tell us what Mercurial knows
%about the files in the repository.
%\interaction{tour.status}
%The \hgcmd{status} command prints no output for some files, but a line
%starting with ``\texttt{M}'' for \filename{hello.c}.  Unless you tell
%it to, \hgcmd{status} will not print any output for files that have
%not been modified.

%The ``\texttt{M}'' indicates that Mercurial has noticed that we
%modified \filename{hello.c}.  We didn't need to \emph{inform}
%Mercurial that we were going to modify the file before we started, or
%that we had modified the file after we were done; it was able to
%figure this out itself.

%It's a little bit helpful to know that we've modified
%\filename{hello.c}, but we might prefer to know exactly \emph{what}
%changes we've made to it.  To do this, we use the \hgcmd{diff}
%command.
%\interaction{tour.diff}

%\section{Recording changes in a new changeset}
\section{$B?7$?$J%A%'%s%8%;%C%H$XJQ99$r5-O?$9$k(B}

%We can modify files, build and test our changes, and use
%\hgcmd{status} and \hgcmd{diff} to review our changes, until we're
%satisfied with what we've done and arrive at a natural stopping point
%where we want to record our work in a new changeset.

%The \hgcmd{commit} command lets us create a new changeset; we'll
%usually refer to this as ``making a commit'' or ``committing''.

%\subsection{Setting up a username}
\subsection{$B%f!<%6L>$r@_Dj$9$k(B}

%When you try to run \hgcmd{commit} for the first time, it is not
%guaranteed to succeed.  Mercurial records your name and address with
%each change that you commit, so that you and others will later be able
%to tell who made each change.  Mercurial tries to automatically figure
%out a sensible username to commit the change with.  It will attempt
%each of the following methods, in order:
%\begin{enumerate}
%\item If you specify a \hgopt{commit}{-u} option to the \hgcmd{commit}
%  command on the command line, followed by a username, this is always
%  given the highest precedence.
%\item If you have set the \envar{HGUSER} environment variable, this is
%  checked next.
%\item If you create a file in your home directory called
%  \sfilename{.hgrc}, with a \rcitem{ui}{username} entry, that will be
%  used next.  To see what the contents of this file should look like,
%  refer to section~\ref{sec:tour-basic:username} below.
%\item If you have set the \envar{EMAIL} environment variable, this
%  will be used next.
%\item Mercurial will query your system to find out your local user
%  name and host name, and construct a username from these components.
%  Since this often results in a username that is not very useful, it
%  will print a warning if it has to do this.
%\end{enumerate}
%If all of these mechanisms fail, Mercurial will fail, printing an
%error message.  In this case, it will not let you commit until you set
%up a username.

%You should think of the \envar{HGUSER} environment variable and the
%\hgopt{commit}{-u} option to the \hgcmd{commit} command as ways to
%\emph{override} Mercurial's default selection of username.  For normal
%use, the simplest and most robust way to set a username for yourself
%is by creating a \sfilename{.hgrc} file; see below for details.

%\subsubsection{Creating a Mercurial configuration file}
\subsubsection{Mercurial$B$N@_Dj%U%!%$%k$r:n@.$9$k(B}
\label{sec:tour-basic:username}

%the value of the \texttt{username} item in the \texttt{ui} section''.
%A section continues until a new section begins, or the end of the
%file.  Mercurial ignores empty lines and treats any text from
%``\texttt{\#}'' to the end of a line as a comment.

%\subsubsection{Choosing a user name}
\subsubsection{$B%f!<%6L>$rA*$V(B}

%You can use any text you like as the value of the \texttt{username}
%config item, since this information is for reading by other people,
%but for interpreting by Mercurial.  The convention that most people
%follow is to use their name and email address, as in the example
%above.

%\begin{note}
%  Mercurial's built-in web server obfuscates email addresses, to make
%  it more difficult for the email harvesting tools that spammers use.
%  This reduces the likelihood that you'll start receiving more junk
%  email if you publish a Mercurial repository on the web.
%\end{note}

%\subsection{Writing a commit message}
\subsection{$B%3%_%C%H%a%C%;!<%8$r=q$/(B}

%When we commit a change, Mercurial drops us into a text editor, to
%enter a message that will describe the modifications we've made in
%this changeset.  This is called the \emph{commit message}.  It will be
%a record for readers of what we did and why, and it will be printed by
%\hgcmd{log} after we've finished committing.
%\interaction{tour.commit}

%The editor that the \hgcmd{commit} command drops us into will contain
%an empty line, followed by a number of lines starting with
%``\texttt{HG:}''.
%\begin{codesample2}

%\end{codesample2}
%Mercurial ignores the lines that start with ``\texttt{HG:}''; it uses
%them only to tell us which files it's recording changes to.  Modifying
%or deleting these lines has no effect.

%\subsection{Writing a good commit message}
\subsection{$B$h$$%3%_%C%H%a%C%;!<%8$N=q$-J}(B}

%Since \hgcmd{log} only prints the first line of a commit message by
%default, it's best to write a commit message whose first line stands

%  user:        Censored Person <[e-mail]>
%  date:        Tue Sep 26 21:37:07 2006 -0700
%  summary:     include buildmeister/commondefs.   Add an exports and install
%\end{codesample2}

%As far as the remainder of the contents of the commit message are
%concerned, there are no hard-and-fast rules.  Mercurial itself doesn't
%interpret or care about the contents of the commit message, though
%your project may have policies that dictate a certain kind of
%formatting.

%My personal preference is for short, but informative, commit messages
%that tell me something that I can't figure out with a quick glance at
%the output of \hgcmdargs{log}{--patch}.

%\subsection{Aborting a commit}
\subsection{$B%3%_%C%H$rCf;_$9$k(B}

%If you decide that you don't want to commit while in the middle of
%editing a commit message, simply exit from your editor without saving
%the file that it's editing.  This will cause nothing to happen to
%either the repository or the working directory.

%If we run the \hgcmd{commit} command without any arguments, it records
%all of the changes we've made, as reported by \hgcmd{status} and
%\hgcmd{diff}.

%\subsection{Admiring our new handiwork}
\subsection{$B?7$?$J:n6H$r>N;?$9$k(B}

%Once we've finished the commit, we can use the \hgcmd{tip} command to

%revision in the repository.
%\interaction{tour.tip}
%We refer to the newest revision in the repository as the tip revision,
%or simply the tip.

%\section{Sharing changes}
\section{$BJQ99$r6&M-$9$k(B}

%We mentioned earlier that repositories in Mercurial are
%self-contained.  This means that the changeset we just created exists
%only in our \dirname{my-hello} repository.  Let's look at a few ways
%that we can propagate this change into other repositories.

%\subsection{Pulling changes from another repository}
\subsection{$BB>$N%j%]%8%H%j$+$iJQ99$r(Bpull$B$9$k(B}
\label{sec:tour:pull}

%To get started, let's clone our original \dirname{hello} repository,
%which does not contain the change we just committed.  We'll call our
%temporary repository \dirname{hello-pull}.
%\interaction{tour.clone-pull}

%We'll use the \hgcmd{pull} command to bring changes from
%\dirname{my-hello} into \dirname{hello-pull}.  However, blindly
%pulling unknown changes into a repository is a somewhat scary
%prospect.  Mercurial provides the \hgcmd{incoming} command to tell us

%(Of course, someone could cause more changesets to appear in the
%repository that we ran \hgcmd{incoming} in, before we get a chance to
%\hgcmd{pull} the changes, so that we could end up pulling changes that we
%didn't expect.)

%Bringing changes into a repository is a simple matter of running the
%\hgcmd{pull} command, and telling it which repository to pull from.
%\interaction{tour.pull}
%As you can see from the before-and-after output of \hgcmd{tip}, we
%have successfully pulled changes into our repository.  There remains
%one step before we can see these changes in the working directory.

%\subsection{Updating the working directory}
\subsection{$B%o!<%-%s%0%G%#%l%/%H%j$r99?7$9$k(B}

%We have so far glossed over the relationship between a repository and

%directory.  This is because \hgcmd{pull} does not (by default) touch
%the working directory.  Instead, we use the \hgcmd{update} command to
%do this.
%\interaction{tour.update}

%It might seem a bit strange that \hgcmd{pull} doesn't update the
%working directory automatically.  There's actually a good reason for
%this: you can use \hgcmd{update} to update the working directory to
%the state it was in at \emph{any revision} in the history of the
%repository.  If you had the working directory updated to an old
%revision---to hunt down the origin of a bug, say---and ran a
%\hgcmd{pull} which automatically updated the working directory to a
%new revision, you might not be terribly happy.

%However, since pull-then-update is such a common thing to do,
%Mercurial lets you combine the two by passing the \hgopt{pull}{-u}
%option to \hgcmd{pull}.
%\begin{codesample2}

%an explicit step to update the working directory:
%\begin{codesample2}
%  (run 'hg update' to get a working copy)
%\end{codesample2}

%To find out what revision the working directory is at, use the
%\hgcmd{parents} command.
%\interaction{tour.parents}
%If you look back at figure~\ref{fig:tour-basic:history}, you'll see
%arrows connecting each changeset.  The node that the arrow leads
%\emph{from} in each case is a parent, and the node that the arrow
%leads \emph{to} is its child.  The working directory has a parent in
%just the same way; this is the changeset that the working directory
%currently contains.

%To update the working directory to a particular revision, give a
%revision number or changeset~ID to the \hgcmd{update} command.
%\interaction{tour.older}
%If you omit an explicit revision, \hgcmd{update} will update to the
%tip revision, as shown by the second call to \hgcmd{update} in the
%example above.

%\subsection{Pushing changes to another repository}
\subsection{$BB>$N%j%]%8%H%j$KJQ99$r(Bpush$B$9$k(B}

%Mercurial lets us push changes to another repository, from the

%As with \hgcmd{pull}, the \hgcmd{push} command does not update the
%working directory in the repository that it's pushing changes into.
%(Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u}
%option that updates the other repository's working directory.)

%What happens if we try to pull or push changes and the receiving
%repository already has those changes?  Nothing too exciting.
%\interaction{tour.push.nothing}

%\subsection{Sharing changes over a network}
\subsection{$BJQ99$r%M%C%H%o!<%/$rDL$8$F6&M-$9$k(B}

%The commands we have covered in the previous few sections are not

%In this example, we can see what changes we could push to the remote
%repository, but the repository is understandably not set up to let
%anonymous users push to it.
%\interaction{tour.push.net}




%%% Local Variables:
%%% mode: yatex
%%% TeX-master: "00book"
%%% End:

786:11bc9d788428

%refer to ``a~\emph{specific} changeset'' is of great importance.
%Recall that the \texttt{changeset} field in the output from
%\hgcmd{log} identifies a changeset using both a number and a
%hexadecimal string.

``a~changeset''$B$H$$$&%A%'%s%8%;%C%H$N(B\emph{$B8F$SL>(B}$B$O<+M3$@$,!$(B
``a~\emph{specific} changeset''$B$r;2>H$9$k(B\emph{$B<1JL;R(B}$B$OHs>o$K=EMW$G$"$k!%(B
\hgcmd{log}$B%3%^%s%I$N=PNO$K4^$^$l$k(B\texttt{changeset}$B%U%#!<%k%I$O!$$"$k%A%'(B
$B%s%8%;%C%H$rHV9f$H(B16$B?JJ8;zNs$GI=$7$F$$$?$3$H$r;W$$=P$7$FM_$7$$!%(B

%\begin{itemize}
%\item The revision number is \emph{only valid in that repository},
%\item while the hex string is the \emph{permanent, unchanging
%    identifier} that will always identify that exact changeset in

%arrived in a repository, and there is no guarantee that the same
%changes will happen in the same order in different repositories.
%Three changes $a,b,c$ can easily appear in one repository as $0,1,2$,
%while in another as $1,0,2$.

$B$3$N6hJL$O=EMW$G$"$k!%C/$+$K(B``revision~33''$B$H8@$C$?;~!$$=$N%j%S%8%g%s(B33$B$,(B
$B<+J,$N%j%]%8%H%j$N%j%]%8%H%j$N$b$N$H$O(B\emph{$B0c$&$b$N$G$"$k(B}$B2DG=@-$O9b$$!%(B
$B$=$NM}M3$O!$%j%S%8%g%sHV9f$O%j%]%8%H%j$KJQ99$,8=$l$?=g=x$K$h$C$F7h$^(B
$B$j!$(BMercurial$B$G$OJL$N%j%]%8%H%j$GF1$8JQ99$,F1$8=g=x$G5/$3$kJ]>Z$O$J$$$?$a(B
$B$G$"$k!%(B 3$B$D$NJQ99(B$a,b,c$$B$O!$$"$k%j%]%8%H%j$G(B$0,1,2$$B$N=g$G5/$3$j!$JL$N%j(B
$B%]%8%H%j$G$O(B$1,0,2$$B$N=g=x$G5/$3$jF@$k!%(B

%Mercurial uses revision numbers purely as a convenient shorthand.  If
%you need to discuss a changeset with someone, or make a record of a
%changeset for some other reason (for example, in a bug report), use
%the hexadecimal identifier.

Mercurial$B$O%j%S%8%g%sHV9f$rC1$KJXMx$N$?$a$NN,5-K!$H$7$FMQ$$$k!%C/$+$H%A%'(B
$B%s%8%;%C%H$K$D$$$F5DO@$7$?$j!$!J%P%0Js9p$J$I$N$?$a$K!K%A%'%s%8%;%C%H$r5-(B
$BO?$7$?$$>l9g$O(B16$B?J$N<1JL;R$rMxMQ$9$Y$-$G$"$k!%(B

%\subsection{Viewing specific revisions}
\subsection{$BFCDj$N%j%S%8%g%s$r8+$k(B}

%To narrow the output of \hgcmd{log} down to a single revision, use the
%\hgopt{log}{-r} (or \hgopt{log}{--rev}) option.  You can use either a
%revision number or a long-form changeset identifier, and you can
%provide as many revisions as you want.  \interaction{tour.log-r}

\hgcmd{log}$B$N=PNO$r$"$k(B1$B$D$N%j%S%8%g%s$K@)8B$9$k$?$a$K$O!$(B
\hgopt{log}{-r}$B!J$^$?$O(B \hgopt{log}{--rev}$B!K%*%W%7%g%s$rMQ$$$k!%%j%S%8%g(B
$B%sHV9f$bD97A<0$N%A%'%s%8%;%C%H<1JL;R$bMxMQ2DG=$G$"$j!$;XDj$G$-$k%j%S%8%g(B
$B%s$N?t$K@)8B$O$J$$!%(B
\interaction{tour.log-r}

%If you want to see the history of several revisions without having to
%list each one, you can use \emph{range notation}; this lets you
%express the idea ``I want all revisions between $a$ and $b$,
%inclusive''.
%\interaction{tour.log.range}
%Mercurial also honours the order in which you specify revisions, so
%\hgcmdargs{log}{-r 2:4} prints $2,3,4$ while \hgcmdargs{log}{-r 4:2}
%prints $4,3,2$.

$B$$$/$D$+$N%j%S%8%g%s$NMzNr$r!$$$$A$$$A%j%S%8%g%s$r;XDj$9$k$3$H$J$/8+$?$$(B
$B;~$O!$(B\emph{$BHO0O5-K!(B}$B$,;H$($k!%$3$l$K$h$j(B``$a$$B$+$i(B$b$$B$^$G$K4^$^$l$kA4$F$N(B
$B%j%S%8%g%s(B''$B$r;XDj$9$k$3$H$,$G$-$k!%(B
\interaction{tour.log.range}
Mercurial$B$O%j%S%8%g%s$,;XDj$5$l$?=g=x$r9MN8$9$k!%(B\hgcmdargs{log}{-r 2:4}
$B$O(B$2,3,4$$B$N=g$KI=<($7!$(B\hgcmdargs{log}{-r 4:2}$B$O(B$4,3,2$$B$N=g$KI=<($r9T$&!%(B

%\subsection{More detailed information}
\subsection{$B$h$j>\:Y$J>pJs(B}

%While the summary information printed by \hgcmd{log} is useful if you
%already know what you're looking for, you may need to see a complete

%trying to decide whether a changeset is the one you're looking for.
%The \hgcmd{log} command's \hggopt{-v} (or \hggopt{--verbose})
%option gives you this extra detail.
%\interaction{tour.log-v}

$BC5$7$F$$$k$b$N$,$O$C$-$j$7$F$$$k>l9g$O(B\hgcmd{log}$B%3%^%s%I$K$h$k%5%^%j!<>p(B
$BJs$OM-MQ$@$,!$$I$N%A%'%s%8%;%C%H$,8+$D$1$h$&$H$9$k%A%'%s%8%;%C%H$J$N$+7h(B
$B$a$k;~$K$OJQ99$N40A4$J5-=R$dJQ99$5$l$?%U%!%$%k$N%j%9%H$,I,MW$K$J$k$+$b$7(B
$B$l$J$$!%(B\hgcmd{log}$B%3%^%s%I$N(B\hggopt{-v}$B!J$^$?$O(B\hggopt{--verbose}$B!K%*%W(B
$B%7%g%s$G$h$j>\:Y$J>pJs$r8+$k$3$H$,$G$-$k!%(B
\interaction{tour.log-v}

%If you want to see both the description and content of a change, add
%the \hgopt{log}{-p} (or \hgopt{log}{--patch}) option.  This displays
%the content of a change as a \emph{unified diff} (if you've never seen
%a unified diff before, see section~\ref{sec:mq:patch} for an overview).
%\interaction{tour.log-vp}

$B@bL@$HJQ99$NFbMF$NN>J}$r8+$?$$>l9g$O(B\hgopt{log}{-p}$B!J$^$?$O(B
\hgopt{log}{--patch}$B!K%*%W%7%g%s$rDI2C$9$k!%$3$N%*%W%7%g%s$OJQ99$NFbMF$r(B
\emph{unified diff}$B7A<0$GI=<($9$k!%!J(Bunified diff$B7A<0$r8+$?$3$H$,$J$1$l(B
$B$P35N,$r(B\ref{sec:mq:patch}$B@a$G8+$k$3$H$,$G$-$k!%!K(B
\interaction{tour.log-vp}

%\section{All about command options}
\section{$B%3%^%s%I%*%W%7%g%s$N$9$Y$F(B}

%Let's take a brief break from exploring Mercurial commands to discuss
%a pattern in the way that they work; you may find this useful to keep
%in mind as we continue our tour.

Mercurial$B%3%^%s%I$r;n$9$N$r0l5Y$_$7$F!$%3%^%s%I$NF0:n%Q%?!<%s$K$D$$$F5D(B
$BO@$7$F$_$h$&!%$3$l$O$3$N%D%"!<$rB3$1$k>e$GLr$KN)$D$@$m$&!%(B

%Mercurial has a consistent and straightforward approach to dealing
%with the options that you can pass to commands.  It follows the
%conventions for options that are common to modern Linux and Unix
%systems.
Mercurial$B$O%3%^%s%I$K%*%W%7%g%s$rEO$9:]$K0l4S@-$N$"$kD>@\E*$J%"%W%m!<%A$r(B
$B<h$C$F$$$k!%$3$l$O8=Be$N(BLinux$B$*$h$S(BUnix$B$K6&DL$N%*%W%7%g%s$K4X$9$k=,47$K4p(B
$B$E$$$F$$$k!%(B
\begin{itemize}
%\item Every option has a long name.  For example, as we've already
%  seen, the \hgcmd{log} command accepts a \hgopt{log}{--rev} option.
 \item $BA4$F$N%*%W%7%g%s$OD97A<0$N%*%W%7%g%s$r;}$D!%Nc$($P!$$9$G$K8+$F$$$k(B
       $B$h$&$K(B\hgcmd{log}$B%3%^%s%I$O(B\hgopt{log}{--rev}$B%*%W%7%g%s$r<u$1IU$1(B
       $B$k!%(B
%\item Most options have short names, too.  Instead of
%  \hgopt{log}{--rev}, we can use \hgopt{log}{-r}.  (The reason that
%  some options don't have short names is that the options in question
%  are rarely used.)
 \item $B$[$H$s$I$N%*%W%7%g%s$OC;=LL>$r;}$D!%(B\hgopt{log}{--rev}$B%*%W%7%g%s$N(B
       $BBe$o$j$K(B\hgopt{log}{-r}$B$,;H$($k!%!J$$$/$D$+$N%*%W%7%g%s$GC;=LL>$,(B
       $B;H$($J$$M}M3$O!$$=$N%*%W%7%g%s$,$[$H$s$I;HMQ$5$l$J$$$?$a$G$"$k!%!K(B
%\item Long options start with two dashes (e.g.~\hgopt{log}{--rev}),
%  while short options start with one (e.g.~\hgopt{log}{-r}).
 \item $BD97A<0$N%*%W%7%g%s$O(B2$B$D$N%@%C%7%e$G;O$^$k!JNc(B
       ~\hgopt{log}{--rev}$B!K!%0lJ}C;7A<0$N%*%W%7%g%s$O(B1$B$D$N%@%C%7%e$G;O$^(B
       $B$k!JNc(B ~\hgopt{log}{-r}$B!K!%(B
%\item Option naming and usage is consistent across commands.  For
%  example, every command that lets you specify a changeset~ID or
%  revision number accepts both \hgopt{log}{-r} and \hgopt{log}{--rev}
%  arguments.
 \item $B%*%W%7%g%s$NL?L>$H;HMQK!$O%3%^%s%I4V$G0l4S$7$F$$$k!%Nc$r5s$2$k$H!$(B
       $B%A%'%s%8%;%C%H(BID$B$^$?$O%j%S%8%g%sHV9f$r;XDj$5$;$k%3%^%s%I$NA4$F$G(B
       \hgopt{log}{-r}$B$H(B\hgopt{log}{--rev}$B$NN>J}$r<u$1IU$1$k!%(B
\end{itemize}
%In the examples throughout this book, I use short options instead of
%long.  This just reflects my own preference, so don't read anything
%significant into it.
$B$3$NK\$NNc$NA4$F$GC;7A<0$N%*%W%7%g%s$rMQ$$$k!%$3$l$OC1$KI.<T$N9%$_$N$?$a(B
$B$G!$?<$$0UL#$O$J$$!%(B

%Most commands that print output of some kind will print more output
%when passed a \hggopt{-v} (or \hggopt{--verbose}) option, and less
%when passed \hggopt{-q} (or \hggopt{--quiet}).
$BI=<(=PNO$r9T$&$[$H$s$I$N%3%^%s%I$G(B\hggopt{-v}$B!J$^$?$O(B\hggopt{--verbose}$B!K(B
$B%*%W%7%g%s$rIU$1$k$H$h$j>\:Y$J=PNO$r9T$$!$(B\hggopt{-q}$B!J$^$?$O(B
\hggopt{--quiet}$B!K%*%W%7%g%s$rIU$1$k$H$h$j4J7i$J=PNO$H$J$k!%(B

%\section{Making and reviewing changes}
\section{$BJQ99$N;EJ}!$JQ99$N%l%S%e!<(B}

%Now that we have a grasp of viewing history in Mercurial, let's take a
%look at making some changes and examining them.

Mercurial$B$GMzNr$r8+$kJ}K!$K$D$$$F$OM}2r$7$?!%$3$3$G$O2?$+JQ99$r9T$C$F!$(B
$B$3$l$r8+$F$_$h$&!%(B

%The first thing we'll do is isolate our experiment in a repository of
%its own.  We use the \hgcmd{clone} command, but we don't need to
%clone a copy of the remote repository.  Since we already have a copy
%of it locally, we can just clone that instead.  This is much faster

%work on multiple tasks in parallel, each isolated from the others
%until it's complete and you're ready to integrate it back.  Because
%local clones are so cheap, there's almost no overhead to cloning and
%destroying repositories whenever you want.

$B$^$::G=i$K$3$N<B83$rK\Mh$N%j%]%8%H%j$+$i3VN%$9$k$?$a$K(B\hgcmd{clone}$B$r9T(B
$B$&!%$9$G$K%m!<%+%k$J%j%]%8%H%j$r;}$C$F$$$k$N$G!$$3$l$r%/%m!<%s$9$k$@$1$G(B
$B$h$/!$%j%b!<%H$N%j%]%8%H%j$r%3%T!<$9$kI,MW$O$J$$!%%m!<%+%k$J%/%m!<%s$O%M%C(B
$B%H%o!<%/1[$7$K9T$&%/%m!<%s$h$j$b$:$C$HB.$/!$B?$/$N>l9g;HMQ$9$k%G%#%9%/MF(B
$BNL$b>/$J$$!%(B
\interaction{tour.reclone}
$B$^$?!$2?$+:n6H$r$7$?$$;~$K%5%s%I%\%C%/%9$H$9$k$?$a$K0l;~E*$J%/%m!<%s$r:n(B
$B@.$7!$%j%b!<%H%j%]%8%H%j$N%3%T!<$r(B``$B@67i(B''$B$KJ]$D$3$H$O$7$P$7$PLr$KN)$D!%(B
$B$3$l$K$h$jJ#?t$N:n6H$rJB9T$7$F9T$&$3$H$,$G$-!$$+$D!$:n6H$,40N;$7!$:F$SE}(B
$B9g$9$k$^$GB>$N:n6H$+$i3VN%$5$l$?$^$^$K$7$F$*$/$3$H$,$G$-$k!%%j%]%8%H%j$N(B
$B%m!<%+%k%/%m!<%s$O$H$F$b<j7Z$G!$%/%m!<%s$HGQ4~$K$[$H$s$I%*!<%P%X%C%I$,$J(B
$B$$!%(B

%In our \dirname{my-hello} repository, we have a file
%\filename{hello.c} that contains the classic ``hello, world'' program.
%Let's use the ancient and venerable \command{sed} command to edit this
%file so that it prints a second line of output.  (I'm only using
%\command{sed} to do this because it's easy to write a scripted example
%this way.  Since you're not under the same constraint, you probably
%won't want to use \command{sed}; simply use your preferred text editor to
%do the same thing.)
%\interaction{tour.sed}

\dirname{my-hello}$B%j%]%8%H%jFb$K$O%/%i%7%C%/$J(B``hello, world''$B%W%m%0%i%`(B
$B$G$"$k(B\filename{hello.c}$B$,$"$k!%8E$/$5$/?987$J(B\command{sed}$B$rMQ$$$F(B2$B9TL\(B
$B$N=PNO$r9T$&$h$&$KJQ99$9$k!%!J(B\command{sed}$B$r;H$&$N$O%9%/%j%W%H$K$h$kNc$r(B
$B:n$k$N$,4JC1$@$+$i$K2a$.$J$$!%FI<T$^$G(B\command{sed}$B$r;H$&I,MW$O$J$/!$9%$-(B
$B$J%F%-%9%H%(%G%#%?$GJT=8$7$F$h$$!%!K(B
\interaction{tour.sed}

%Mercurial's \hgcmd{status} command will tell us what Mercurial knows
%about the files in the repository.
%\interaction{tour.status}
%The \hgcmd{status} command prints no output for some files, but a line
%starting with ``\texttt{M}'' for \filename{hello.c}.  Unless you tell
%it to, \hgcmd{status} will not print any output for files that have
%not been modified.

$B%j%]%8%H%jFb$N%U%!%$%k$KBP$7$F(BMercurial$B$,GD0.$7$F$$$kFbMF$r(B
\hgcmd{status}$B%3%^%s%I$G8+$k$3$H$,$G$-$k!%(B
\interaction{tour.status}
\hgcmd{status}$B%3%^%s%I$O$$$/$D$+$N%U%!%$%k$KBP$7$F$O=PNO$r9T$o$J$$$,!$(B
\filename{hello.c}$B$KBP$7$F(B``\texttt{M}''$B$rI=<($9$k!%FC$K;X<($r$7$J$$>l(B
$B9g!$(B\hgcmd{status}$B%3%^%s%I$OJQ99$5$l$F$$$J$$%U%!%$%k$KBP$7$F$O2?$b=PNO$7(B
$B$J$$!%(B

%The ``\texttt{M}'' indicates that Mercurial has noticed that we
%modified \filename{hello.c}.  We didn't need to \emph{inform}
%Mercurial that we were going to modify the file before we started, or
%that we had modified the file after we were done; it was able to
%figure this out itself.

``\texttt{M}''$B$N0UL#$O!$(B\filename{hello.c}$B$KBP$7$F9T$o$l$?JQ99$r(B
Mercurial$B$,GD0.$7$?$H$$$&$3$H$G$"$k!%%U%!%$%k$NJQ99A0$K(BMercurial$B$K$3$l$+(B
$B$iJQ99$9$k%U%!%$%k$rEPO?$9$kI,MW$O$J$$$7!$JQ998e$K9T$&I,MW$b$J$$!%JQ99$5(B
$B$l$?%U%!%$%k$NH/8+$O<+F0E*$K9T$o$l$k!%(B

%It's a little bit helpful to know that we've modified
%\filename{hello.c}, but we might prefer to know exactly \emph{what}
%changes we've made to it.  To do this, we use the \hgcmd{diff}
%command.
%\interaction{tour.diff}

\filename{hello.c}$B$rJT=8$7$?$3$H$,J,$+$k$N$OB?>/Lr$KN)$D$,!$CN$j$?$$$N$O(B
$B$`$7$m(B\emph{$B2?$r(B}$BJQ99$7$?$N$+$G$"$k!%(B\hgcmd{diff}$B%3%^%s%I$r;H$($P$3$l$rCN(B
$B$k$3$H$,$G$-$k!%(B \interaction{tour.diff}

%\section{Recording changes in a new changeset}
\section{$B?7$?$J%A%'%s%8%;%C%H$XJQ99$r5-O?$9$k(B}

%We can modify files, build and test our changes, and use
%\hgcmd{status} and \hgcmd{diff} to review our changes, until we're
%satisfied with what we've done and arrive at a natural stopping point
%where we want to record our work in a new changeset.

$B%U%!%$%k$rJQ99$7!$%S%k%I$H%F%9%H$r9T$$!$(B\hgcmd{status}$B$H(B\hgcmd{diff}$B$r;H$C(B
$B$FJQ99$N%l%S%e!<$r9T$$!$5$$N:Q$`$H$3$m$^$G$3$l$r7+JV$7!$;E;v$N7k2L$r?7$?(B
$B$J%A%'%s%8%;%C%H$K5-O?$9$k!%(B

%The \hgcmd{commit} command lets us create a new changeset; we'll
%usually refer to this as ``making a commit'' or ``committing''.

$B?7$?$J%A%'%s%8%;%C%H$r:n@.$9$k$K$O(B\hgcmd{commit}$B%3%^%s%I$r;H$&!%(B
$B$3$NA`:n$r$h$/(B``$B%3%_%C%H$9$k(B''$B$H$+(B``$B%3%_%C%H(B''$B$H8F$V!%(B

%\subsection{Setting up a username}
\subsection{$B%f!<%6L>$r@_Dj$9$k(B}

%When you try to run \hgcmd{commit} for the first time, it is not
%guaranteed to succeed.  Mercurial records your name and address with
%each change that you commit, so that you and others will later be able
%to tell who made each change.  Mercurial tries to automatically figure
%out a sensible username to commit the change with.  It will attempt
%each of the following methods, in order:

$B:G=i$K(B\hgcmd{commit}$B$r<B9T$9$k>l9g!$<B9T$,@.8y$9$k$+$I$&$+$OJ]>Z$5$l$F$$(B
$B$J$$!%$9$Y$F$N%3%_%C%H$G(BMercurial$B$O%f!<%6$NL>A0$H%"%I%l%9$r5-O?$7!$8e$GC/(B
$B$,$=$NJQ99$r9T$C$?$N$+J,$+$k$h$&$K$7$F$$$k!%(B Mercurial$B$OJQ99$r%3%_%C%H$9(B
$B$k:]$K<+F0E*$KBEEv$J%f!<%6L>$rIU$1$h$&$H$9$k!%(B
$B%f!<%6L>$N?dB,$O0J2<$N$h$&$J=g=x$G9T$o$l$k!'(B
\begin{enumerate}
%\item If you specify a \hgopt{commit}{-u} option to the \hgcmd{commit}
%  command on the command line, followed by a username, this is always
%  given the highest precedence.
 \item \hgcmd{commit}$B%3%^%s%I$K(B\hgopt{commit}{-u}$B%*%W%7%g%s$H%f!<%6L>$rIU(B
       $B$1$?>l9g!$$3$l$,:G$bM%@h$5$l$k!%(B
%\item If you have set the \envar{HGUSER} environment variable, this is
%  checked next.
 \item $B4D6-JQ?t(B\envar{HGUSER}$B$r@_Dj$7$F$$$k>l9g$O<!$K$3$l$,;2>H$5$l$k!%(B
%\item If you create a file in your home directory called
%  \sfilename{.hgrc}, with a \rcitem{ui}{username} entry, that will be
%  used next.  To see what the contents of this file should look like,
%  refer to section~\ref{sec:tour-basic:username} below.
 \item $B%[!<%`%G%#%l%/%H%j$K(B\sfilename{.hgrc}$B%U%!%$%k$r:n$C$F$$$k>l(B
       $B9g!$(B\rcitem{ui}{username}$B%(%s%H%j$,<!$K;2>H$5$l$k!%$3$N%U%!%$%k$N(B
       $BFbMF$O(B\ref{sec:tour-basic:username}$B@a$G@bL@$7$F$$$k!%(B
%\item If you have set the \envar{EMAIL} environment variable, this
%  will be used next.
 \item $B4D6-JQ?t(B\envar{EMAIL}$B$r@_Dj$7$F$$$k$J$i<!$K$3$l$,;2>H$5$l$k!%(B
%\item Mercurial will query your system to find out your local user
%  name and host name, and construct a username from these components.
%  Since this often results in a username that is not very useful, it
%  will print a warning if it has to do this.
 \item Mercurial$B$O%7%9%F%`$K%m!<%+%k%f!<%6L>$H%[%9%HL>$rLd$$9g$o$;!$$3$l(B
       $B$i$+$i%3%_%C%H%f!<%6L>$r9=@.$9$k!%$3$N%f!<%6L>$OLr$KN)$?$J$$$3$H$,(B
       $BB?$$$?$a!$$3$NJ}K!$r;H$C$?>l9g$O7Y9p%a%C%;!<%8$,I=<($5$l$k!%(B
\end{enumerate}
%If all of these mechanisms fail, Mercurial will fail, printing an
%error message.  In this case, it will not let you commit until you set
%up a username.
$B$3$l$i$N%a%+%K%:%`$N$9$Y$F$,<:GT$7$?>l9g!$(BMercurial$B$O%(%i!<%a%C%;!<%8$r(B
$BI=<($7$F<B9T$rCGG0$9$k!%$3$N>l9g!$%f!<%6L>$r@_Dj$9$k$^$G%3%_%C%H$9$k$3$H(B
$B$O$G$-$J$$!%(B

%You should think of the \envar{HGUSER} environment variable and the
%\hgopt{commit}{-u} option to the \hgcmd{commit} command as ways to
%\emph{override} Mercurial's default selection of username.  For normal
%use, the simplest and most robust way to set a username for yourself
%is by creating a \sfilename{.hgrc} file; see below for details.

$B4D6-JQ?t(B\envar{HGUSER}$B$H(B\hgcmd{commit}$B%3%^%s%I$N(B\hgopt{commit}{-u}$B%*%W%7%g(B
$B%s$O!$(BMercurial$B$,%G%U%)%k%H$G@_Dj$9$k%f!<%6L>$r(B\emph{$B%*!<%P%i%$%I(B}$B$9$kJ}(B
$BK!$@$H9M$($k$H$h$$!%DL>o$NMxMQK!$G%f!<%6L>$r@_Dj$9$k:G$b4JC1$G:G$b4h6/$J(B
$BJ}K!$O(B\sfilename{.hgrc}$B%U%!%$%k$r:n@.$9$k$3$H$G$"$k!%$3$N$d$jJ}$K$D$$$F<!(B
$B$K=R$Y$k!%(B

%\subsubsection{Creating a Mercurial configuration file}
\subsubsection{Mercurial$B$N@_Dj%U%!%$%k$r:n@.$9$k(B}
\label{sec:tour-basic:username}

%the value of the \texttt{username} item in the \texttt{ui} section''.
%A section continues until a new section begins, or the end of the
%file.  Mercurial ignores empty lines and treats any text from
%``\texttt{\#}'' to the end of a line as a comment.

$B%f!<%6L>$r@_Dj$9$k$K$O9%$_$N%(%G%#%?$G%[!<%`%G%#%l%/%H%j$K(B
\sfilename{.hgrc}$B$H$$$&%U%!%$%k$r:n@.$9$k!%(B Mercurial$B$O$3$N%U%!%$%k$+$i8D(B
$B?M@_Dj$r<hF@$7!$;HMQ$9$k!%(B\sfilename{.hgrc}$B%U%!%$%k$N:G=i$NFbMF$O0J2<$N$h(B
$B$&$J=q<0$K$9$k!%(B
\begin{codesample2}
  # This is a Mercurial configuration file.
  [ui]
  username = Firstname Lastname <[e-mail]>
\end{codesample2}
``\texttt{[ui]}''$B$N9T$G@_Dj%U%!%$%k$N(B\emph{$B%;%/%7%g%s(B}$B$,;O$^$k!%(B
``\texttt{username = ...}''$B$N9T$O(B``\texttt{ui}$B%;%/%7%g%s$N(B
\texttt{username}$B9`L\$NCM$r@_Dj$9$k(B''$B$HFI$`$3$H$,$G$-$k!%(B
$B%;%/%7%g%s$O?7$?$JJL$N%;%/%7%g%s$,;O$^$k$+!$%U%!%$%k$,=*N;$9$k$^$GB3(B
$B$/!%(BMercurial$B$O6u9T$rL5;k$7!$(B``\texttt{\#}''$B$+$i9TKv$^$G$r%3%a%s%H$H$7$F(B
$B07$&!%(B

%\subsubsection{Choosing a user name}
\subsubsection{$B%f!<%6L>$rA*$V(B}

%You can use any text you like as the value of the \texttt{username}
%config item, since this information is for reading by other people,
%but for interpreting by Mercurial.  The convention that most people
%follow is to use their name and email address, as in the example
%above.

\texttt{username}$B$N@_Dj$K;HMQ$9$kJ8;zNs$O!$$3$l$,(BMercurial$B$K$h$C$F=hM}$5(B
$B$l$k$H$$$&E@$r=|$1$P!$C1$KB>$N%f!<%6$,FI$`$H$$$&$@$1$N>pJs$G$"$k$3$H$+(B
$B$i!$$I$N$h$&$JJ8;zNs$G$b9=$o$J$$!%B?$/$N%f!<%6$,=>$&=,47$O!$>e$NNc$N$h$&(B
$B$KL>A0$H(Bemail$B%"%I%l%9$r;H$&$b$N$G$"$k!%(B

\begin{note}
%  Mercurial's built-in web server obfuscates email addresses, to make
%  it more difficult for the email harvesting tools that spammers use.
%  This reduces the likelihood that you'll start receiving more junk
%  email if you publish a Mercurial repository on the web.
Mercurial$B$NAH$_9~$_%&%'%V%5!<%P$O(Bemail$B%"%I%l%9$r%9%Q%^!<$,;H$&(Bemail$B<}=&%D!<(B
$B%k$K=&$o$lFq$/$9$k$h$&$K2~JQ$7!$(BMercurial$B%j%]%8%H%j$r%&%'%V$G8x3+$7$F$b%9(B
$B%Q%`$r<u$1<h$jFq$/$7$F$$$k!%(B
\end{note}

%\subsection{Writing a commit message}
\subsection{$B%3%_%C%H%a%C%;!<%8$r=q$/(B}

%When we commit a change, Mercurial drops us into a text editor, to
%enter a message that will describe the modifications we've made in
%this changeset.  This is called the \emph{commit message}.  It will be
%a record for readers of what we did and why, and it will be printed by
%\hgcmd{log} after we've finished committing.
%\interaction{tour.commit}

$BJQ99$r%3%_%C%H$9$k;~!$(BMercurial$B$O%A%'%s%8%;%C%H$G9T$C$?JQ99$K$D$$$F@bL@$9(B
$B$k%a%C%;!<%8$rF~NO$5$;$k$?$a$K%F%-%9%H%(%G%#%?$r5/F0$9$k!%(B
$B$3$l$O(B\emph{$B%3%_%C%H%a%C%;!<%8(B}$B$H8F$P$l$k!%(B
$B$3$l$O2?$r$J$<JQ99$7$?$N$+FI$_<j$KEA$($k$b$N$G!$%3%_%C%H40N;8e$K(B
\hgcmd{log}$B$GI=<($9$k$3$H$,$G$-$k!%(B
\interaction{tour.commit}

%The editor that the \hgcmd{commit} command drops us into will contain
%an empty line, followed by a number of lines starting with
%``\texttt{HG:}''.
%\begin{codesample2}

%\end{codesample2}
%Mercurial ignores the lines that start with ``\texttt{HG:}''; it uses
%them only to tell us which files it's recording changes to.  Modifying
%or deleting these lines has no effect.

\hgcmd{commit}$B%3%^%s%I$,5/F0$9$k%(%G%#%?$O!$6u9T$H(B``\texttt{HG:}''$B$G;O$^(B
$B$k?t9T$r$9$G$K4^$s$G$$$k!%(B
\begin{codesample2}
  \emph{empty line}
  HG: changed hello.c
\end{codesample2}
Mercurial$B$O(B``\texttt{HG:}''$B$G;O$^$k9T$rL5;k$9$k!%$3$l$i$N9T$O$I$N%U%!%$%k(B
$B$X$NJQ99$J$N$+$r%f!<%6$KEA$($k$@$1$NL\E*$GB8:_$9$k!%$3$l$i$N9T$rJQ99$7$?(B
$B$j>C5n$7$?$j$7$F$b2?$N1F6A$bM?$($J$$!%(B

%\subsection{Writing a good commit message}
\subsection{$B$h$$%3%_%C%H%a%C%;!<%8$N=q$-J}(B}

%Since \hgcmd{log} only prints the first line of a commit message by
%default, it's best to write a commit message whose first line stands

%  user:        Censored Person <[e-mail]>
%  date:        Tue Sep 26 21:37:07 2006 -0700
%  summary:     include buildmeister/commondefs.   Add an exports and install
%\end{codesample2}

$B%G%U%)%k%H$G$O(B\hgcmd{log}$B$O%3%_%C%H%a%C%;!<%8$N:G=i$N9T$7$+I=<($7$J$$$?$a(B
$B%3%_%C%H%a%C%;!<%8$N:G=i$N9T$O(B1$B9T$G407k$9$k$h$&$K=q$/$H$h$$!%(B
$B%,%$%I%i%$%s$K(B\emph{$B=>$o$J$$(B}$B$?$aFI$a$J$$%3%_%C%H%a%C%;!<%8$NNc$r<($9!%(B
\begin{codesample2}
  changeset:   73:584af0e231be
  user:        Censored Person <[e-mail]>
  date:        Tue Sep 26 21:37:07 2006 -0700
  summary:     include buildmeister/commondefs.   Add an exports and install
\end{codesample2}

%As far as the remainder of the contents of the commit message are
%concerned, there are no hard-and-fast rules.  Mercurial itself doesn't
%interpret or care about the contents of the commit message, though
%your project may have policies that dictate a certain kind of
%formatting.

$B%3%_%C%H%a%C%;!<%8$N;D$j$NItJ,$K$O873J$J%k!<%k$O$J$$!%%W%m%8%'%/%H$G%U%)!<(B
$B%^%C%H$K4X$7$FMW5a$9$k%]%j%7!<$,$"$C$?$H$7$F$b!$(BMercurial$B$O%3%_%C%H%a%C%;!<(B
$B%8$rCfCG$7$?$j!$FCJL$NG[N8$r$9$k$3$H$O$J$$!%(B

%My personal preference is for short, but informative, commit messages
%that tell me something that I can't figure out with a quick glance at
%the output of \hgcmdargs{log}{--patch}.

$B8D?ME*$K$O!$4J7i$+$D>pJs$,$"$j!$(B \hgcmdargs{log}{--patch}$B$r0l8+$7$?$@$1$G(B
$B$O$o$+$i$J$$ItJ,$K$D$$$F@bL@$7$?%3%_%C%H%a%C%;!<%8$,9%$_$G$"$k!%(B

%\subsection{Aborting a commit}
\subsection{$B%3%_%C%H$rCf;_$9$k(B}

%If you decide that you don't want to commit while in the middle of
%editing a commit message, simply exit from your editor without saving
%the file that it's editing.  This will cause nothing to happen to
%either the repository or the working directory.

$B%3%_%C%H%a%C%;!<%8$rJT=8Cf$K%3%_%C%H$r<h$j;_$a$?$/$J$C$?;~$O!$JT=8Cf$N%U%!(B
$B%$%k$r%;!<%V$;$:$K%(%G%#%?$r=*N;$9$l$P$h$$!%$3$&$9$k$H%j%]%8%H%j$K$b%o!<(B
$B%-%s%0%G%#%l%/%H%j$K$b2?$b5/$-$J$$!%(B

%If we run the \hgcmd{commit} command without any arguments, it records
%all of the changes we've made, as reported by \hgcmd{status} and
%\hgcmd{diff}.

\hgcmd{commit}$B%3%^%s%I$r0z?t$J$7$G<B9T$7$F$$$k>l9g!$(B\hgcmd{status}$B%3%^%s(B
$B%I$d(B\hgcmd{diff}$B%3%^%s%I$K8=$l$k$=$l$^$G$K9T$C$?JQ99$OJ]B8$5$l$k!%(B

%\subsection{Admiring our new handiwork}
\subsection{$B?7$?$J:n6H$r>N;?$9$k(B}

%Once we've finished the commit, we can use the \hgcmd{tip} command to

%revision in the repository.
%\interaction{tour.tip}
%We refer to the newest revision in the repository as the tip revision,
%or simply the tip.

$B%3%_%C%H$N40N;8e!$(B\hgcmd{tip}$B%3%^%s%I$G:#:n@.$7$?%A%'%s%8%;%C%H$rCN$k$3$H(B
$B$,$G$-$k!%$3$N%3%^%s%I$N=PNO$O%j%]%8%H%j$N:G?7%j%S%8%g%s$N$_$rI=<($9$k$H(B
$B$$$&E@$r=|$1$P(B\hgcmd{log}$B$HA4$/F1$8$G$"$k!%(B
\interaction{tour.tip}
$B%j%]%8%H%j$N:G?7%j%S%8%g%s$O(Btip$B%j%S%8%g%s$^$?$OC1$K(Btip$B$H8F$P$l$k!%(B

%\section{Sharing changes}
\section{$BJQ99$r6&M-$9$k(B}

%We mentioned earlier that repositories in Mercurial are
%self-contained.  This means that the changeset we just created exists
%only in our \dirname{my-hello} repository.  Let's look at a few ways
%that we can propagate this change into other repositories.

Mercurial$B$N%j%]%8%H%j$O<+8J=<B-E*$G$"$k$H$9$G$K=R$Y$?!%$D$^$j!$:#:n@.$7$?(B
$B%A%'%s%8%;%C%H$O(B\dirname{my-hello}$B%j%]%8%H%j$K$N$_B8:_$7$F$$$k!%$3$NJQ99(B
$B$rB>$N%j%]%8%H%j$KGH5Z$5$;$k$$$/$D$+$NJ}K!$r8+$F$_$h$&!%(B

%\subsection{Pulling changes from another repository}
\subsection{$BB>$N%j%]%8%H%j$+$iJQ99$r(Bpull$B$9$k(B}
\label{sec:tour:pull}

%To get started, let's clone our original \dirname{hello} repository,
%which does not contain the change we just committed.  We'll call our
%temporary repository \dirname{hello-pull}.
%\interaction{tour.clone-pull}

$B;O$a$k$KEv$?$C$F!$:#%3%_%C%H$7$?JQ99$r4^$^$J$$%*%j%8%J%k$N(B
\dirname{hello}$B%j%]%8%H%j$r%/%m!<%s$9$k!%$3$N0l;~E*$J%j%]%8%H%j$r(B
\dirname{hello-pull}$B$H8F$V$3$H$K$9$k!%(B
\interaction{tour.clone-pull}

%We'll use the \hgcmd{pull} command to bring changes from
%\dirname{my-hello} into \dirname{hello-pull}.  However, blindly
%pulling unknown changes into a repository is a somewhat scary
%prospect.  Mercurial provides the \hgcmd{incoming} command to tell us

%(Of course, someone could cause more changesets to appear in the
%repository that we ran \hgcmd{incoming} in, before we get a chance to
%\hgcmd{pull} the changes, so that we could end up pulling changes that we
%didn't expect.)

\hgcmd{pull}$B%3%^%s%I$GJQ99$r(B\dirname{my-hello}$B$+$i(B\dirname{hello-pull}$B$K(B
$B<h$j9~$`!%L$CN$NJQ99$rLUL\E*$K%j%]%8%H%j$K(Bpull$B$9$k$3$H$O>/!962$m$7(B
$B$$!%(BMercurial$B$K$O(B\hgcmd{pull}$B%3%^%s%I$G$I$N$h$&$JJQ99$,%j%]%8%H%j$K<h$j9~(B
$B$^$l$k$N$+$r<B:]$K$O(Bpull$B$9$k$3$H$J$/I=<($9$k(B\hgcmd{incoming}$B%3%^%s%I$,$"(B
$B$k!%(B
\interaction{tour.incoming}
$B!J$b$A$m$s(B\hgcmd{incoming}$B$r<B9T$7$F$+$i<B:]$K(B\hgcmd{pull}$B$9$k$^$G$N4V$K(B
$BC/$+$,?7$?$J%A%'%s%8%;%C%H$rDI2C$7!$$=$N7k2L!$M=4|$7$J$$%A%'%s%8%;%C%H$r(B
pull$B$7$F$7$^$&2DG=@-$O$"$k!%!K(B

%Bringing changes into a repository is a simple matter of running the
%\hgcmd{pull} command, and telling it which repository to pull from.
%\interaction{tour.pull}
%As you can see from the before-and-after output of \hgcmd{tip}, we
%have successfully pulled changes into our repository.  There remains
%one step before we can see these changes in the working directory.

$BJQ99$r%j%]%8%H%j$K<h$j9~$`$N$O!$<h$j9~$_85$N%j%]%8%H%j$r;XDj$7$F(B
\hgcmd{pull}$B%3%^%s%I$r<B9T$9$k$@$1$N%7%s%W%k$JA`:n$G$"$k!%(B
\interaction{tour.pull}
pull$B$NA08e$N(B\hgcmd{tip}$B=PNO$G%j%]%8%H%j$X$NJQ99$N<h$j9~$_$K@.8y$7$?$+$I$&(B
$B$+$,$o$+$k!%%o!<%-%s%0%G%#%l%/%H%j$KJQ99$rH?1G$5$;$k$K$O$b$&(B1$B%9%F%C%W$,I,(B
$BMW$G$"$k!%(B

%\subsection{Updating the working directory}
\subsection{$B%o!<%-%s%0%G%#%l%/%H%j$r99?7$9$k(B}

%We have so far glossed over the relationship between a repository and

%directory.  This is because \hgcmd{pull} does not (by default) touch
%the working directory.  Instead, we use the \hgcmd{update} command to
%do this.
%\interaction{tour.update}

$B$3$3$^$G$O%j%]%8%H%j$H%o!<%-%s%0%G%#%l%/%H%j$N4X78$r$"$^$jL@3N$K$;$:$KMh(B
$B$?!%(B \ref{sec:tour:pull}$B@a$G(B\hgcmd{pull}$B%3%^%s%I$r;H$C$FJQ99$r%j%]%8%H%j(B
$B$K<h$j9~$s$@$,!$Cm0U?<$/8+$k$H!$$=$l$i$NJQ99$O%o!<%-%s%0%G%#%l%/%H%j$KH?(B
$B1G$5$l$F$$$J$+$C$?!%$3$l$O!$(B\hgcmd{pull}$B%3%^%s%I$O!J%G%U%)%k%H$G$O!K%o!<(B
$B%-%s%0%G%#%l%/%H%j$K<j$rIU$1$J$$$?$a$G$"$k!%%o!<%-%s%0%G%#%l%/%H%j$rA`:n(B
$B$9$k$?$a$K$O(B\hgcmd{update}$B%3%^%s%I$r;H$&!%(B
\interaction{tour.update}

%It might seem a bit strange that \hgcmd{pull} doesn't update the
%working directory automatically.  There's actually a good reason for
%this: you can use \hgcmd{update} to update the working directory to
%the state it was in at \emph{any revision} in the history of the
%repository.  If you had the working directory updated to an old
%revision---to hunt down the origin of a bug, say---and ran a
%\hgcmd{pull} which automatically updated the working directory to a
%new revision, you might not be terribly happy.

\hgcmd{pull}$B$,%o!<%-%s%0%G%#%l%/%H%j$r<+F0E*$K99?7$7$J$$$N$O$$$5$5$+4qL/(B
$B$K8+$($k$+$b$7$l$J$$!%$7$+$7$3$l$K$O$A$c$s$H$7$?M}M3$,$"$k!%%o!<%-%s%0%G%#(B
$B%l%/%H%j$O(B\hgcmd{update}$B$G%j%]%8%H%j$N$$$+$J$k%P!<%8%g%s$K$b99?7$G$-$k!%(B
$B%P%0$N860x$rC5$k$?$a$K%o!<%-%s%0%G%#%l%/%H%j$r8E$$%j%S%8%g%s$K$7$F$$$k;~!$(B
\hgcmd{pull}$B$r<B9T$7$?$?$a$K%o!<%-%s%0%G%#%l%/%H%j$,:G?7$N%j%S%8%g%s$K$J$C(B
$B$?$H$7$?$i!$<u$1$kHo32$O>/$J$/$J$$!%(B

%However, since pull-then-update is such a common thing to do,
%Mercurial lets you combine the two by passing the \hgopt{pull}{-u}
%option to \hgcmd{pull}.
%\begin{codesample2}

%an explicit step to update the working directory:
%\begin{codesample2}
%  (run 'hg update' to get a working copy)
%\end{codesample2}

$B$7$+$7$J$,$i!$!V(Bpull$B8e$K99?7!W$H$$$&A`:n$O$H$F$b$h$/9T$o$l$k$?$a!$(B
\hgcmd{pull}$B%3%^%s%I$K$O$3$l$i(B2$B$D$NA`:n$r0lEY$K9T$&%*%W%7%g%s!$(B
\hgopt{pull}{-u}$B$,$"$k!%(B
\begin{codesample2}
  hg pull -u
\end{codesample2}
\ref{sec:tour:pull}$B@a$G(B\hgopt{pull}{-u}$B%*%W%7%g%s$J$7$G<B9T$5$l$F$$$k(B
\hgcmd{pull}$B%3%^%s%I$N=PNO$r2~$a$F8+$F$_$k$H!$%o!<%-%s%0%G%#%l%/%H%j$r(B
$BL@<(E*$K99?7$7$J$1$l$P$J$i$J$$$3$H$r<($9(B
\begin{codesample2}
  (run 'hg update' to get a working copy)
\end{codesample2}
$B$H$$$&Cm0U=q$-$,$"$k$N$K5$$E$/!%(B

%To find out what revision the working directory is at, use the
%\hgcmd{parents} command.
%\interaction{tour.parents}
%If you look back at figure~\ref{fig:tour-basic:history}, you'll see
%arrows connecting each changeset.  The node that the arrow leads
%\emph{from} in each case is a parent, and the node that the arrow
%leads \emph{to} is its child.  The working directory has a parent in
%just the same way; this is the changeset that the working directory
%currently contains.

$B%o!<%-%s%0%G%#%l%/%H%j$N8=:_$N%j%S%8%g%s$rD4$Y$k$K$O(B\hgcmd{parents}$B%3%^(B
$B%s%I$r;H$&!%(B
\interaction{tour.parents}
$B?^(B~\ref{fig:tour-basic:history}$B$r8+D>$9$H!$3F!9$N%A%'%s%8%;%C%H$r7k$VLp0u(B
$B$,$"$k!%Lp0u$N=P$F$$$k$H$3$m$,?F$G!$Lp0u$,<($7$F$$$k$H$3$m$,;R$G$"$k!%%o!<(B
$B%-%s%0%G%#%l%/%H%j$OF1MM$K(B1$B$D$N?F$r;}$A!$$3$l$,%o!<%-%s%0%G%#%l%/%H%j$,8=(B
$B:_99?7$5$l$F$$$k%A%'%s%8%;%C%H$G$"$k!%(B

%To update the working directory to a particular revision, give a
%revision number or changeset~ID to the \hgcmd{update} command.
%\interaction{tour.older}
%If you omit an explicit revision, \hgcmd{update} will update to the
%tip revision, as shown by the second call to \hgcmd{update} in the
%example above.

$BFCDj$N%j%S%8%g%s$K%o!<%-%s%0%G%#%l%/%H%j$r99?7$9$k$?$a$K(B
$B$O!$(B\hgcmd{update}$B%3%^%s%I$K%j%S%8%g%sHV9f$^$?$O%A%'%s%8%;%C%H(BID$B$rEO$9!%(B
\interaction{tour.older}
$BL@<(E*$K%j%S%8%g%s$rEO$5$J$+$C$?>l9g!$>e$NNc$G(B2$B2sL\$N(B\hgcmd{update}$B$N<B9T(B
$B$N$h$&$K(B\hgcmd{update}$B%3%^%s%I$O%o!<%-%s%0%G%#%l%/%H%j$r(Btip$B%j%S%8%g%s$X99(B
$B?7$9$k!%(B

%\subsection{Pushing changes to another repository}
\subsection{$BB>$N%j%]%8%H%j$KJQ99$r(Bpush$B$9$k(B}

%Mercurial lets us push changes to another repository, from the

%As with \hgcmd{pull}, the \hgcmd{push} command does not update the
%working directory in the repository that it's pushing changes into.
%(Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u}
%option that updates the other repository's working directory.)

Mercurial$B$G$O8=:_;HMQ$7$F$$$k%j%]%8%H%j$+$iB>$N%j%]%8%H%j$KJQ99$r(Bpush$B$9$k(B
$B$3$H$,$G$-$k!%A0=R$N(B\hgcmd{pull}$B%3%^%s%I$N$h$&$K!$0l;~E*$J%j%]%8%H%j$r:n$C(B
$B$F$=$3$KJQ99$r(Bpush$B$7$F$_$h$&!%(B
\interaction{tour.clone-push}
$BB>$N%j%]%8%H%j$K(Bpush$B$5$l$kJQ99$O(B\hgcmd{outgoing}$B%3%^%s%I$GCN$k$3$H$,$G$-(B
$B$k!%(B
\interaction{tour.outgoing}
\hgcmd{push}$B%3%^%s%I$G<B:]$K(Bpush$B$r9T$&!%(B
\interaction{tour.push}
\hgcmd{pull}$B%3%^%s%I$HF1MM$K!$(B\hgcmd{push}$B%3%^%s%I$O(Bpush$B@h$N%j%]%8%H%j$N(B
$B%o!<%-%s%0%G%#%l%/%H%j$N99?7$r9T$o$J$$!%!J(B\hgcmd{pull}$B%3%^%s%I$H0c$C$F(B
\hgcmd{push}$B%3%^%s%I$O!$%o!<%-%s%0%G%#%l%/%H%j$N99?7$r9T$&(B\texttt{-u}$B%*%W(B
$B%7%g%s$r;}$?$J$$!%!K(B

%What happens if we try to pull or push changes and the receiving
%repository already has those changes?  Nothing too exciting.
%\interaction{tour.push.nothing}

$B%j%]%8%H%j$,$"$kJQ99$r$9$G$K;}$C$F$$$k$H$-!$F1$8JQ99$r(Bpull$B$^$?$O(Bpush$B$7$h(B
$B$&$H$9$k$H2?$,5/$-$k$@$m$&$+!)FC$K6C$/$h$&$J$3$H$O5/$-$J$$!%(B
\interaction{tour.push.nothing}

%\subsection{Sharing changes over a network}
\subsection{$BJQ99$r%M%C%H%o!<%/$rDL$8$F6&M-$9$k(B}

%The commands we have covered in the previous few sections are not

%In this example, we can see what changes we could push to the remote
%repository, but the repository is understandably not set up to let
%anonymous users push to it.
%\interaction{tour.push.net}

$B$3$l$h$jA0$N$$$/$D$+$N@a$G07$C$?%3%^%s%I$O!$%m!<%+%k%j%]%8%H%j$@$1$K8BDj(B
$B$5$l$J$$!%$I$N%3%^%s%I$b%M%C%H%o!<%/7PM3$G$bA4$/F1$8$KF0:n$9$k!%0c$$$O%m!<(B
$B%+%k%Q%9$NBe$o$j$K(BURL$B$rEO$9$@$1$G$"$k!%(B
\interaction{tour.outgoing.net}
$B$3$NNc$G$O!$%j%]!<%H%j%]%8%H%j$K(Bpush$B$7$h$&$H$9$k$,!$EvA3$N$3$H$J$,$iF?L>(B
$B$N%f!<%6$K(Bpush$B$r5v2D$7$J$$$h$&$K@_Dj$5$l$F$$$k$?$a!$(Bpush$B$G$-$J$$!%(B
\interaction{tour.push.net}

%%% Local Variables:
%%% mode: yatex
%%% TeX-master: "00book"
%%% End: