diff es/tour-basic.tex @ 442:2fb78d342e07

changed es/Leame.1st upgraded the list of files on translation and revision. added a term (builtin) to the glossary changed es/concepts.tex file added to define labels needed by other tex files changed es/preface.tex killed a TODO changed es/tour-basic.tex I have began the translation of this file. 34% completed, according to vim changed es/undo.tex file added to define labels needed by other tex files

--- a/es/tour-basic.tex	Sun Oct 19 17:08:11 2008 -0500
+++ b/es/tour-basic.tex	Sun Oct 19 19:56:21 2008 -0500
@@ -0,0 +1,631 @@
+\chapter{Una gira de Mercurial: lo básico}
+\label{chap:tour-basic}
+
+\section{Instalar Mercurial en su sistema}
+\label{sec:tour:install}
+Hay paquetes binarios precompilados de Mercurial disponibles para cada
+sistema operativo popular. Esto hace fácil empezar a usar Mercurial
+en su computador inmediatamente.
+
+\subsection{Linux}
+
+Dado que cada distribución de Linux tiene sus propias herramientas de
+manejo de paquetes, políticas, y ritmos de desarrollo, es difícil dar
+un conjunto exhaustivo de instrucciones sobre cómo instalar el paquete
+de Mercurial. La versión de Mercurial que usted tenga a disposición
+puede variar dependiendo de qué tan activa sea la persona que mantiene
+el paquete para su distribución.
+
+Para mantener las cosas simples, me enfocaré en instalar Mercurial
+desde la línea de comandos en las distribuciones de Linux más
+populares. La mayoría de estas distribuciones proveen administradores
+de paquetes gráficos que le permitirán instalar Mercurial con un solo
+clic; el nombre de paquete a buscar es \texttt{mercurial}.
+
+\begin{itemize}
+\item[Debian]
+  \begin{codesample4}
+    apt-get install mercurial
+  \end{codesample4}
+
+\item[Fedora Core]
+  \begin{codesample4}
+    yum install mercurial
+  \end{codesample4}
+
+\item[Gentoo]
+  \begin{codesample4}
+    emerge mercurial
+  \end{codesample4}
+
+\item[OpenSUSE]
+  \begin{codesample4}
+    yum install mercurial
+  \end{codesample4}
+
+\item[Ubuntu] El paquete de Mercurial de Ubuntu está basado en el de
+    Debian. Para instalarlo, ejecute el siguiente comando.
+  \begin{codesample4}
+    apt-get install mercurial
+  \end{codesample4}
+  El paquete de Mercurial para Ubuntu tiende a atrasarse con respecto
+  a la versión de Debian por un margen de tiempo considerable
+  (al momento de escribir esto, 7 meses), lo que en algunos casos
+  significará que usted puede encontrarse con problemas que ya habrán
+  sido resueltos en el paquete de Debian.
+\end{itemize}
+
+\subsection{Solaris}
+
+SunFreeWare, en \url{http://www.sunfreeware.com}, es una buena fuente
+para un gran número de paquetes compilados para Solaris para las
+arquitecturas Intel y Sparc de 32 y 64 bits, incluyendo versiones
+actuales de Mercurial.
+
+\subsection{Mac OS X}
+
+Lee Cantey publica un instalador de Mercurial para Mac OS~X en 
+\url{http://mercurial.berkwood.com}.  Este paquete funciona en tanto
+en Macs basados en Intel como basados en PowerPC. Antes de que pueda
+usarlo, usted debe instalar una versión compatible de Universal
+MacPython~\cite{web:macpython}. Esto es fácil de hacer; simplemente
+siga las instrucciones de el sitio de Lee.
+
+También es posible instalar Mercurial usando Fink o MacPorts, dos
+administradores de paquetes gratuitos y populares para Mac OS X. Si
+usted tiene Fink, use \command{sudo apt-get install mercurial-py25}.
+Si usa MacPorts, \command{sudo port install mercurial}.
+
+\subsection{Windows}
+
+Lee Cantey publica un instalador de Mercurial para Windows en
+\url{http://mercurial.berkwood.com}. Este paquete no tiene
+% TODO traducción de it just works. Agreed?
+dependencias externas; ``simplemente funciona''.
+
+\begin{note}
+    La versión de Windows de Mercurial no convierte automáticamente
+    los fines de línea entre estilos Windows y Unix. Si usted desea
+    compartir trabajo con usuarios de Unix, deberá hacer un trabajo
+    adicional de configuración. XXX Terminar esto.
+\end{note}
+
+\section{Arrancando}
+
+Para empezar, usaremos el comando \hgcmd{version} para revisar si
+Mercurial está instalado adecuadamente. La información de la versión
+que es impresa no es tan importante; lo que nos importa es si imprime
+algo en absoluto.
+
+\interaction{tour.version}
+
+% TODO builtin-> integrado?
+\subsection{Ayuda integrada}
+
+Mercurial provee un sistema de ayuda integrada. Esto es invaluable
+para ésas ocasiones en la que usted está atorado tratando de recordar
+cómo ejecutar un comando. Si está completamente atorado, simplemente
+ejecute \hgcmd{help}; esto imprimirá una breve lista de comandos,
+junto con una descripción de qué hace cada uno. Si usted solicita
+ayuda sobre un comando específico (como abajo), se imprime información
+más detallada.
+\interaction{tour.help}
+Para un nivel más impresionante de detalle (que usted no va a
+necesitar usualmente) ejecute \hgcmdargs{help}{\hggopt{-v}}. La opción
+\hggopt{-v} es la abreviación para \hggopt{--verbose}, y le indica a
+Mercurial que imprima más información de lo que haría usualmente.
+
+\section{Working with a repository}
+
+In Mercurial, everything happens inside a \emph{repository}.  The
+repository for a project contains all of the files that ``belong to''
+that project, along with a historical record of the project's files.
+
+There's nothing particularly magical about a repository; it is simply
+a directory tree in your filesystem that Mercurial treats as special.
+You can rename or delete a repository any time you like, using either the
+command line or your file browser.
+
+\subsection{Making a local copy of a repository}
+
+\emph{Copying} a repository is just a little bit special.  While you
+could use a normal file copying command to make a copy of a
+repository, it's best to use a built-in command that Mercurial
+provides.  This command is called \hgcmd{clone}, because it creates an
+identical copy of an existing repository.
+\interaction{tour.clone}
+If our clone succeeded, we should now have a local directory called
+\dirname{hello}.  This directory will contain some files.
+\interaction{tour.ls}
+These files have the same contents and history in our repository as
+they do in the repository we cloned.
+
+Every Mercurial repository is complete, self-contained, and
+independent.  It contains its own private copy of a project's files
+and history.  A cloned repository remembers the location of the
+repository it was cloned from, but it does not communicate with that
+repository, or any other, unless you tell it to.
+
+What this means for now is that we're free to experiment with our
+repository, safe in the knowledge that it's a private ``sandbox'' that
+won't affect anyone else.
+
+\subsection{What's in a repository?}
+
+When we take a more detailed look inside a repository, we can see that
+it contains a directory named \dirname{.hg}.  This is where Mercurial
+keeps all of its metadata for the repository.
+\interaction{tour.ls-a}
+
+The contents of the \dirname{.hg} directory and its subdirectories are
+private to Mercurial.  Every other file and directory in the
+repository is yours to do with as you please.
+
+To introduce a little terminology, the \dirname{.hg} directory is the
+``real'' repository, and all of the files and directories that coexist
+with it are said to live in the \emph{working directory}.  An easy way
+to remember the distinction is that the \emph{repository} contains the
+\emph{history} of your project, while the \emph{working directory}
+contains a \emph{snapshot} of your project at a particular point in
+history.
+
+\section{A tour through history}
+
+One of the first things we might want to do with a new, unfamiliar
+repository is understand its history.  The \hgcmd{log} command gives
+us a view of history.
+\interaction{tour.log}
+By default, this command prints a brief paragraph of output for each
+change to the project that was recorded.  In Mercurial terminology, we
+call each of these recorded events a \emph{changeset}, because it can
+contain a record of changes to several files.
+
+The fields in a record of output from \hgcmd{log} are as follows.
+\begin{itemize}
+\item[\texttt{changeset}] This field has the format of a number,
+  followed by a colon, followed by a hexadecimal string.  These are
+  \emph{identifiers} for the changeset.  There are two identifiers
+  because the number is shorter and easier to type than the hex
+  string.
+\item[\texttt{user}] The identity of the person who created the
+  changeset.  This is a free-form field, but it most often contains a
+  person's name and email address.
+\item[\texttt{date}] The date and time on which the changeset was
+  created, and the timezone in which it was created.  (The date and
+  time are local to that timezone; they display what time and date it
+  was for the person who created the changeset.)
+\item[\texttt{summary}] The first line of the text message that the
+  creator of the changeset entered to describe the changeset.
+\end{itemize}
+The default output printed by \hgcmd{log} is purely a summary; it is
+missing a lot of detail.
+
+Figure~\ref{fig:tour-basic:history} provides a graphical representation of
+the history of the \dirname{hello} repository, to make it a little
+easier to see which direction history is ``flowing'' in.  We'll be
+returning to this figure several times in this chapter and the chapter
+that follows.
+
+\begin{figure}[ht]
+  \centering
+  \grafix{tour-history}
+  \caption{Graphical history of the \dirname{hello} repository}
+  \label{fig:tour-basic:history}
+\end{figure}
+
+\subsection{Changesets, revisions, and talking to other 
+  people}
+
+As English is a notoriously sloppy language, and computer science has
+a hallowed history of terminological confusion (why use one term when
+four will do?), revision control has a variety of words and phrases
+that mean the same thing.  If you are talking about Mercurial history
+with other people, you will find that the word ``changeset'' is often
+compressed to ``change'' or (when written) ``cset'', and sometimes a
+changeset is referred to as a ``revision'' or a ``rev''.
+
+While it doesn't matter what \emph{word} you use to refer to the
+concept of ``a~changeset'', the \emph{identifier} that you use to
+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.
+\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
+  \emph{every} copy of the repository.
+\end{itemize}
+This distinction is important.  If you send someone an email talking
+about ``revision~33'', there's a high likelihood that their
+revision~33 will \emph{not be the same} as yours.  The reason for this
+is that a revision number depends on the order in which changes
+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$.
+
+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.
+
+\subsection{Viewing specific revisions}
+
+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}
+
+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
+description of the change, or a list of the files changed, if you're
+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}
+
+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}
+
+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
+than cloning over the network, and cloning a local repository uses
+less disk space in most cases, too.
+\interaction{tour.reclone}
+As an aside, it's often good practice to keep a ``pristine'' copy of a
+remote repository around, which you can then make temporary clones of
+to create sandboxes for each task you want to work on.  This lets you
+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}
+
+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}
+
+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}
+\label{sec:tour-basic:username}
+
+To set a user name, use your favourite editor to create a file called
+\sfilename{.hgrc} in your home directory.  Mercurial will use this
+file to look up your personalised configuration settings.  The initial
+contents of your \sfilename{.hgrc} should look like this.
+\begin{codesample2}
+  # This is a Mercurial configuration file.
+  [ui]
+  username = Firstname Lastname <[e-mail]>
+\end{codesample2}
+The ``\texttt{[ui]}'' line begins a \emph{section} of the config file,
+so you can read the ``\texttt{username = ...}'' line as meaning ``set
+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}
+
+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}
+
+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}
+  \emph{empty line}
+  HG: changed hello.c
+\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}
+
+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
+alone.  Here's a real example of a commit message that \emph{doesn't}
+follow this guideline, and hence has a summary that is not readable.
+\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.
+
+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}
+
+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}
+
+Once we've finished the commit, we can use the \hgcmd{tip} command to
+display the changeset we just created.  This command produces output
+that is identical to \hgcmd{log}, but it only displays the newest
+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}
+
+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}
+\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
+what changes the \hgcmd{pull} command \emph{would} pull into the
+repository, without actually pulling the changes in.
+\interaction{tour.incoming}
+(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}
+
+We have so far glossed over the relationship between a repository and
+its working directory.  The \hgcmd{pull} command that we ran in
+section~\ref{sec:tour:pull} brought changes into the repository, but
+if we check, there's no sign of those changes in the working
+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}
+  hg pull -u
+\end{codesample2}
+If you look back at the output of \hgcmd{pull} in
+section~\ref{sec:tour:pull} when we ran it without \hgopt{pull}{-u},
+you can see that it printed a helpful reminder that we'd have to take
+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}
+
+Mercurial lets us push changes to another repository, from the
+repository we're currently visiting.  As with the example of
+\hgcmd{pull} above, we'll create a temporary repository to push our
+changes into.
+\interaction{tour.clone-push}
+The \hgcmd{outgoing} command tells us what changes would be pushed
+into another repository.
+\interaction{tour.outgoing}
+And the \hgcmd{push} command does the actual push.
+\interaction{tour.push}
+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}
+
+The commands we have covered in the previous few sections are not
+limited to working with local repositories.  Each works in exactly the
+same fashion over a network connection; simply pass in a URL instead
+of a local path.
+\interaction{tour.outgoing.net}
+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: latex
+%%% TeX-master: "00book"
+%%% End: