1.1 --- a/es/99defs.tex	Thu Nov 06 23:06:16 2008 -0500
     1.2 +++ b/es/99defs.tex	Thu Nov 06 23:07:42 2008 -0500
     1.3 @@ -122,7 +122,7 @@
     1.4  
     1.5  % Graphics inclusion.
     1.6  \ifpdf
     1.7 -  \newcommand{\grafix}[1]{\includegraphics{#1}}
     1.8 +  \newcommand{\grafix}[2][]{\includegraphics[#1]{#2}}
     1.9  \else
    1.10    \newcommand{\grafix}[1]{\includegraphics{#1.png}}
    1.11  \fi

     2.1 --- a/es/Leame.1st	Thu Nov 06 23:06:16 2008 -0500
     2.2 +++ b/es/Leame.1st	Thu Nov 06 23:07:42 2008 -0500
     2.3 @@ -100,7 +100,8 @@
     2.4  || daily.tex       || Igor Támara   ||    100%    || 19/10/2008 ||  26/10/2008 ||
     2.5  || tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
     2.6  || undo.tex        || Igor Támara   ||     71%    || 26/10/2008 ||             ||
     2.7 -|| tour-merge.tex  || Javier Rojas  ||     10%    || 28/10/2008 ||             ||
     2.8 +|| tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
     2.9 +|| concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
    2.10  
    2.11  == Archivos en proceso de revisión ==
    2.12  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    2.13 @@ -391,6 +392,10 @@
    2.14      la modificación" o algo así es una traducción demasiado literal,
    2.15      así que ojo con el contexto.
    2.16  
    2.17 +track -> seguir, monitorear
    2.18 +    este término suele ser usado cuando se habla de archivos, y de llevar la 
    2.19 +    pista o monitorear los cambios en un archivo.
    2.20 +
    2.21  trunk -> tronco
    2.22      Se refiere al nombre que recibe la línea de desarrollo
    2.23      principal del repositorio que no está asociada a ninguna rama

     3.1 --- a/es/concepts.tex	Thu Nov 06 23:06:16 2008 -0500
     3.2 +++ b/es/concepts.tex	Thu Nov 06 23:07:42 2008 -0500
     3.3 @@ -1,83 +1,92 @@
     3.4 -\chapter{Behind the scenes}
     3.5 +\chapter{Tras bambalinas}
     3.6  \label{chap:concepts}
     3.7  
     3.8 -Unlike many revision control systems, the concepts upon which
     3.9 -Mercurial is built are simple enough that it's easy to understand how
    3.10 -the software really works.  Knowing this certainly isn't necessary,
    3.11 -but I find it useful to have a ``mental model'' of what's going on.
    3.12 -
    3.13 -This understanding gives me confidence that Mercurial has been
    3.14 -carefully designed to be both \emph{safe} and \emph{efficient}.  And
    3.15 -just as importantly, if it's easy for me to retain a good idea of what
    3.16 -the software is doing when I perform a revision control task, I'm less
    3.17 -likely to be surprised by its behaviour.
    3.18 -
    3.19 -In this chapter, we'll initially cover the core concepts behind
    3.20 -Mercurial's design, then continue to discuss some of the interesting
    3.21 -details of its implementation.
    3.22 -
    3.23 -\section{Mercurial's historical record}
    3.24 -
    3.25 -\subsection{Tracking the history of a single file}
    3.26 -
    3.27 -When Mercurial tracks modifications to a file, it stores the history
    3.28 -of that file in a metadata object called a \emph{filelog}.  Each entry
    3.29 -in the filelog contains enough information to reconstruct one revision
    3.30 -of the file that is being tracked.  Filelogs are stored as files in
    3.31 -the \sdirname{.hg/store/data} directory.  A filelog contains two kinds
    3.32 -of information: revision data, and an index to help Mercurial to find
    3.33 -a revision efficiently.
    3.34 -
    3.35 -A file that is large, or has a lot of history, has its filelog stored
    3.36 -in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}''
    3.37 -suffix) files.  For small files without much history, the revision
    3.38 -data and index are combined in a single ``\texttt{.i}'' file.  The
    3.39 -correspondence between a file in the working directory and the filelog
    3.40 -that tracks its history in the repository is illustrated in
    3.41 -figure~\ref{fig:concepts:filelog}.
    3.42 +A diferencia de varios sistemas de control de revisiones, los
    3.43 +conceptos en los que se fundamenta Mercurial son lo suficientemente
    3.44 +simples como para entender fácilmente cómo funciona el software. 
    3.45 +Saber esto no es necesario, pero considero útil tener un ``modelo
    3.46 +mental'' de qué es lo que sucede.
    3.47 +
    3.48 +Comprender esto me da la confianza de que Mercurial ha sido
    3.49 +cuidadosamente diseñado para ser tanto \emph{seguro} como
    3.50 +\emph{eficiente}.  Y tal vez con la misma importancia, si es fácil
    3.51 +para mí hacerme a una idea adecuada de qué está haciendo el software
    3.52 +cuando llevo a cabo una tarea relacionada con control de revisiones,
    3.53 +es menos probable que me sosprenda su comportamiento.
    3.54 +
    3.55 +En este capítulo, cubriremos inicialmente los conceptos centrales
    3.56 +del diseño de Mercurial, y luego discutiremos algunos detalles
    3.57 +interesantes de su implementación.
    3.58 +
    3.59 +\section{Registro del historial de Mercurial}
    3.60 +
    3.61 +\subsection{Seguir el historial de un único fichero}
    3.62 +
    3.63 +Cuando Mercurial sigue las modificaciones a un fichero, guarda el
    3.64 +historial de dicho fichero en un objeto de metadatos llamado
    3.65 +\emph{filelog}\ndt{Fichero de registro}.  Cada entrada en el fichero
    3.66 +de registro contiene suficiente información para reconstruir una
    3.67 +revisión del fichero que se está siguiendo. Los ficheros de registro
    3.68 +son almacenados como ficheros el el directorio
    3.69 +\sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
    3.70 +de información: datos de revisiones, y un índice para ayudar a
    3.71 +Mercurial a buscar revisiones eficientemente.
    3.72 +
    3.73 +El fichero de registro de un fichero grande, o con un historial muy
    3.74 +largo, es guardado como ficheros separados para datos (sufijo
    3.75 +``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
    3.76 +ficheros pequeños con un historial pequeño, los datos de revisiones y
    3.77 +el índice son combinados en un único fichero ``\texttt{.i}''. La
    3.78 +correspondencia entre un fichero en el directorio de trabajo y el
    3.79 +fichero de registro que hace seguimiento a su historial en el
    3.80 +repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
    3.81  
    3.82  \begin{figure}[ht]
    3.83    \centering
    3.84    \grafix{filelog}
    3.85 -  \caption{Relationships between files in working directory and
    3.86 -    filelogs in repository}
    3.87 +  \caption{Relación entre ficheros en el directorio de trabajo y
    3.88 +  ficheros de registro en el repositorio}
    3.89    \label{fig:concepts:filelog}
    3.90  \end{figure}
    3.91  
    3.92 -\subsection{Managing tracked files}
    3.93 -
    3.94 -Mercurial uses a structure called a \emph{manifest} to collect
    3.95 -together information about the files that it tracks.  Each entry in
    3.96 -the manifest contains information about the files present in a single
    3.97 -changeset.  An entry records which files are present in the changeset,
    3.98 -the revision of each file, and a few other pieces of file metadata.
    3.99 -
   3.100 -\subsection{Recording changeset information}
   3.101 -
   3.102 -The \emph{changelog} contains information about each changeset.  Each
   3.103 -revision records who committed a change, the changeset comment, other
   3.104 -pieces of changeset-related information, and the revision of the
   3.105 -manifest to use.
   3.106 -
   3.107 -\subsection{Relationships between revisions}
   3.108 -
   3.109 -Within a changelog, a manifest, or a filelog, each revision stores a
   3.110 -pointer to its immediate parent (or to its two parents, if it's a
   3.111 -merge revision).  As I mentioned above, there are also relationships
   3.112 -between revisions \emph{across} these structures, and they are
   3.113 -hierarchical in nature.
   3.114 -
   3.115 -For every changeset in a repository, there is exactly one revision
   3.116 -stored in the changelog.  Each revision of the changelog contains a
   3.117 -pointer to a single revision of the manifest.  A revision of the
   3.118 -manifest stores a pointer to a single revision of each filelog tracked
   3.119 -when that changeset was created.  These relationships are illustrated
   3.120 -in figure~\ref{fig:concepts:metadata}.
   3.121 +\subsection{Administración de ficheros monitoreados}
   3.122 +
   3.123 +Mercurial usa una estructura llamada \emph{manifiesto} para
   3.124 +% TODO collect together => centralizar
   3.125 +centralizar la información que maneja acerca de los ficheros que
   3.126 +monitorea. Cada entrada en el manifiesto contiene información acerca
   3.127 +de los ficheros involucrados en un único conjunto de cambios. Una
   3.128 +entrada registra qué ficheros están presentes en el conjunto de
   3.129 +cambios, la revisión de cada fichero, y otros cuantos metadatos del
   3.130 +mismo.
   3.131 +
   3.132 +\subsection{Registro de información del conjunto de cambios}
   3.133 +
   3.134 +La \emph{bitácora de cambios} contiene información acerca de cada
   3.135 +conjunto de cambios. Cada revisión indica quién consignó un cambio, el
   3.136 +comentario para el conjunto de cambios, otros datos relacionados con
   3.137 +el conjunto de cambios, y la revisión del manifiesto a usar.
   3.138 +
   3.139 +\subsection{Relaciones entre revisiones}
   3.140 +
   3.141 +Dentro de una bitácora de cambios, un manifiesto, o un fichero de
   3.142 +registro, cada revisión conserva un apuntador a su padre inmediato
   3.143 +(o sus dos padres, si es la revisión de una fusión). Como menciońe
   3.144 +anteriormente, también hay relaciones entre revisiones \emph{a través}
   3.145 +de estas estructuras, y tienen naturaleza jerárquica.
   3.146 +
   3.147 +Por cada conjunto de cambios en un repositorio, hay exactamente una
   3.148 +revisión almacenada en la bitácora de cambios. Cada revisión de la
   3.149 +bitácora de cambios contiene un apuntador a una única revisión del
   3.150 +manifiesto. Una revisión del manifiesto almacena un apuntador a una
   3.151 +única revisión de cada fichero de registro al que se le hacía
   3.152 +seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
   3.153 +se ilustran en la figura~\ref{fig:concepts:metadata}.
   3.154  
   3.155  \begin{figure}[ht]
   3.156    \centering
   3.157    \grafix{metadata}
   3.158 -  \caption{Metadata relationships}
   3.159 +  \caption{Relaciones entre metadatos}
   3.160    \label{fig:concepts:metadata}
   3.161  \end{figure}
   3.162  

     4.1 --- a/es/tour-merge.tex	Thu Nov 06 23:06:16 2008 -0500
     4.2 +++ b/es/tour-merge.tex	Thu Nov 06 23:07:42 2008 -0500
     4.3 @@ -105,185 +105,202 @@
     4.4  
     4.5  \subsection{Consignar los resultados de la fusión}
     4.6  
     4.7 -Whenever we've done a merge, \hgcmd{parents} will display two parents
     4.8 -until we \hgcmd{commit} the results of the merge.
     4.9 +Siempre que hacemos una fusión, \hgcmd{parents} mostrará dos padres
    4.10 +hasta que consignemos (\hgcmd{commit}) los resultados de la fusión.
    4.11  \interaction{tour.merge.commit}
    4.12 -We now have a new tip revision; notice that it has \emph{both} of
    4.13 -our former heads as its parents.  These are the same revisions that
    4.14 -were previously displayed by \hgcmd{parents}.
    4.15 +Ahora tenemos una nueva revisión de punta; note que tiene \emph{los
    4.16 +dos} frentes anteriores como sus padres. Estos son las mismas
    4.17 +revisiones que mostró previamente el comando \hgcmd{parents}.
    4.18  \interaction{tour.merge.tip}
    4.19 -In figure~\ref{fig:tour-merge:merge}, you can see a representation of
    4.20 -what happens to the working directory during the merge, and how this
    4.21 -affects the repository when the commit happens.  During the merge, the
    4.22 -working directory has two parent changesets, and these become the
    4.23 -parents of the new changeset.
    4.24 -
    4.25 -\section{Merging conflicting changes}
    4.26 -
    4.27 -Most merges are simple affairs, but sometimes you'll find yourself
    4.28 -merging changes where each modifies the same portions of the same
    4.29 -files.  Unless both modifications are identical, this results in a
    4.30 -\emph{conflict}, where you have to decide how to reconcile the
    4.31 -different changes into something coherent.
    4.32 +En la figura~\ref{fig:tour-merge:merge} usted puede apreciar una
    4.33 +representación de lo que pasa en el directorio de trabajo durante la
    4.34 +fusión cuando se hace la consignación. Durante la fusión, el
    4.35 +directorio de trabajo tiene dos conjuntos de cambios como sus padres,
    4.36 +y éstos se vuelven los padres del nuevo conjunto de cambios.
    4.37 +
    4.38 +\section{Fusionar cambios con conflictos}
    4.39 +
    4.40 +La mayoría de las fusiones son algo simple, pero a veces usted se
    4.41 +encontrará fusionando cambios donde más de uno de ellos afecta las
    4.42 +mismas secciones de los mismos ficheros. A menos que ambas
    4.43 +modificaciones sean idénticas, el resultado es un \emph{conflicto}, en
    4.44 +donde usted debe decidir cómo reconciliar ambos cambios y producir un
    4.45 +resultado coherente.
    4.46  
    4.47  \begin{figure}[ht]
    4.48    \centering
    4.49    \grafix{tour-merge-conflict}
    4.50 -  \caption{Conflicting changes to a document}
    4.51 +  \caption{Cambios con conflictos a un documento}
    4.52    \label{fig:tour-merge:conflict}
    4.53  \end{figure}
    4.54  
    4.55 -Figure~\ref{fig:tour-merge:conflict} illustrates an instance of two
    4.56 -conflicting changes to a document.  We started with a single version
    4.57 -of the file; then we made some changes; while someone else made
    4.58 -different changes to the same text.  Our task in resolving the
    4.59 -conflicting changes is to decide what the file should look like.
    4.60 -
    4.61 -Mercurial doesn't have a built-in facility for handling conflicts.
    4.62 -Instead, it runs an external program called \command{hgmerge}.  This
    4.63 -is a shell script that is bundled with Mercurial; you can change it to
    4.64 -behave however you please.  What it does by default is try to find one
    4.65 -of several different merging tools that are likely to be installed on
    4.66 -your system.  It first tries a few fully automatic merging tools; if
    4.67 -these don't succeed (because the resolution process requires human
    4.68 -guidance) or aren't present, the script tries a few different
    4.69 -graphical merging tools.
    4.70 -
    4.71 -It's also possible to get Mercurial to run another program or script
    4.72 -instead of \command{hgmerge}, by setting the \envar{HGMERGE}
    4.73 -environment variable to the name of your preferred program.
    4.74 -
    4.75 -\subsection{Using a graphical merge tool}
    4.76 -
    4.77 -My preferred graphical merge tool is \command{kdiff3}, which I'll use
    4.78 -to describe the features that are common to graphical file merging
    4.79 -tools.  You can see a screenshot of \command{kdiff3} in action in
    4.80 -figure~\ref{fig:tour-merge:kdiff3}.  The kind of merge it is
    4.81 -performing is called a \emph{three-way merge}, because there are three
    4.82 -different versions of the file of interest to us.  The tool thus
    4.83 -splits the upper portion of the window into three panes:
    4.84 +La figura~\ref{fig:tour-merge:conflict} ilustra un ejemplo con dos
    4.85 +cambios generando conflictos en un documento. Empezamos con una sola
    4.86 +versión de el fichero; luego hicimos algunos cambios; mientras tanto,
    4.87 +alguien más  hizo cambios diferentes en el mismo texto. Lo que debemos
    4.88 +hacer para resolver el conflicto causado por ambos cambios es decidir
    4.89 +cómo debe quedar finalmente el fichero.
    4.90 +
    4.91 +Mercurial no tiene ninguna utilidad integrada para manejar conflictos.
    4.92 +En vez de eso, ejecuta un programa externo llamado \command{hgmerge}.
    4.93 +Es un guión de línea de comandos que es instalado junto con Mercurial;
    4.94 +usted puede modificarlo para que se comporte como usted lo desee. Por
    4.95 +defecto, lo que hace es tratar de encontrar una de varias herramientas
    4.96 +para fusionar que es probable que estén instaladas en su sistema.
    4.97 +Primero se intenta con unas herramientas para fusionar cambios
    4.98 +automáticamente; si esto no tiene éxito (porque la fusión demanda
    4.99 +una guía humana) o dichas herramientas no están presentes, el guión
   4.100 +intenta con herramientas gráficas para fusionar.
   4.101 +
   4.102 +También es posible hacer que Mercurial ejecute otro programa o guión
   4.103 +en vez de \command{hgmerge}, definiendo la variable de entorno
   4.104 +\envar{HGMERGE} con el nombre del programa de su preferencia.
   4.105 +
   4.106 +\subsection{Usar una herramienta gráfica para fusión}
   4.107 +
   4.108 +Mi herramienta favorita para hacer fusiones es \command{kdiff3}, y la
   4.109 +usaré para describir las características comunes de las herramientas
   4.110 +gráficas para hacer fusiones. Puede ver una captura de pantalla de
   4.111 +\command{kdiff3} ejecutándose, en la
   4.112 +figura~\ref{fig:tour-merge:kdiff3}.  El tipo de fusión que la
   4.113 +herramienta hace se conoce como \emph{fusión de tres vías}, porque hay
   4.114 +tres versiones diferentes del archivo en que estamos interesados.
   4.115 +Debido a esto la herramienta divide la parte superior de la ventana en
   4.116 +tres paneles.
   4.117  \begin{itemize}
   4.118 -\item At the left is the \emph{base} version of the file, i.e.~the
   4.119 -  most recent version from which the two versions we're trying to
   4.120 -  merge are descended.
   4.121 -\item In the middle is ``our'' version of the file, with the contents
   4.122 -  that we modified.
   4.123 -\item On the right is ``their'' version of the file, the one that
   4.124 -  from the changeset that we're trying to merge with.
   4.125 +\item A la izquierda está la revisión \emph{base} del fichero, p.ej.~la
   4.126 +    versión más reciente de la que descienden las dos versiones que
   4.127 +    estamos tratando de fusionar.
   4.128 +\item En la mitad está ``nuestra'' versión del fichero, con las
   4.129 +    modificaciones que hemos hecho.
   4.130 +\item A la derecha está la versión del fichero de ``ellos'', la que
   4.131 +    forma parte del conjunto de cambios que estamos tratando de
   4.132 +    fusionar.
   4.133  \end{itemize}
   4.134 -In the pane below these is the current \emph{result} of the merge.
   4.135 -Our task is to replace all of the red text, which indicates unresolved
   4.136 -conflicts, with some sensible merger of the ``ours'' and ``theirs''
   4.137 -versions of the file.
   4.138 -
   4.139 -All four of these panes are \emph{locked together}; if we scroll
   4.140 -vertically or horizontally in any of them, the others are updated to
   4.141 -display the corresponding sections of their respective files.
   4.142 -
   4.143 -\begin{figure}[ht]
   4.144 -  \centering
   4.145 -  \grafix{kdiff3}
   4.146 -  \caption{Using \command{kdiff3} to merge versions of a file}
   4.147 +En el panel inferior se encuentra el \emph{resultado} actual de la
   4.148 +fusión. Nuestra tarea es reemplazar todo el texto rojo, que muestra
   4.149 +los conflictos sin resolver, con una fusión adecuada de ``nuestra''
   4.150 +versión del fichero y la de ``ellos''.
   4.151 +
   4.152 +Los cuatro paneles están \emph{enlazados}; si avanzamos vertical o
   4.153 +horizontalmente en cualquiera de ellos, los otros son actualizados
   4.154 +para mostrar las secciones correspondientes del fichero que tengan
   4.155 +asociado.
   4.156 +
   4.157 +\begin{figure}[ht]
   4.158 +  \centering
   4.159 +  \grafix[width=\textwidth]{kdiff3}
   4.160 +  \caption{Usando \command{kdiff3} para fusionar versiones de un
   4.161 +  fichero}
   4.162    \label{fig:tour-merge:kdiff3}
   4.163  \end{figure}
   4.164  
   4.165 -For each conflicting portion of the file, we can choose to resolve
   4.166 -the conflict using some combination of text from the base version,
   4.167 -ours, or theirs.  We can also manually edit the merged file at any
   4.168 -time, in case we need to make further modifications.
   4.169 -
   4.170 -There are \emph{many} file merging tools available, too many to cover
   4.171 -here.  They vary in which platforms they are available for, and in
   4.172 -their particular strengths and weaknesses.  Most are tuned for merging
   4.173 -files containing plain text, while a few are aimed at specialised file
   4.174 -formats (generally XML).
   4.175 -
   4.176 -\subsection{A worked example}
   4.177 -
   4.178 -In this example, we will reproduce the file modification history of
   4.179 -figure~\ref{fig:tour-merge:conflict} above.  Let's begin by creating a
   4.180 -repository with a base version of our document.
   4.181 +En cada conflicto del fichero podemos escoger resolverlo usando
   4.182 +cualquier combinación del texto de la revisión base, la nuestra, o la
   4.183 +de ellos. También podemos editar manualmente el fichero en que queda
   4.184 +la fusión, si es necesario hacer cambios adicionales.
   4.185 +
   4.186 +Hay \emph{muchas} herramientas para fusionar ficheros disponibles. Se
   4.187 +diferencian en las plataformas para las que están disponibles, y en
   4.188 +sus fortalezas y debilidades particulares. La mayoría están afinadas
   4.189 +para fusionar texto plano, mientras que otras están pensadas para
   4.190 +formatos de archivos especializados (generalmente XML).
   4.191 +
   4.192 +% TODO traduje "worked" como "real"
   4.193 +\subsection{Un ejemplo real}
   4.194 +
   4.195 +En este ejemplo, reproduciremos el historial de modificaciones al
   4.196 +fichero de la figura~\ref{fig:tour-merge:conflict} mostrada
   4.197 +anteriormente.  Empecemos creando un repositorio con la versión base
   4.198 +de nuestro documento.
   4.199  \interaction{tour-merge-conflict.wife}
   4.200 -We'll clone the repository and make a change to the file.
   4.201 +Clonaremos el repositorio y haremos un cambio al fichero.
   4.202  \interaction{tour-merge-conflict.cousin}
   4.203 -And another clone, to simulate someone else making a change to the
   4.204 -file.  (This hints at the idea that it's not all that unusual to merge
   4.205 -with yourself when you isolate tasks in separate repositories, and
   4.206 -indeed to find and resolve conflicts while doing so.)
   4.207 +Y haremos otro clon, para simular a alguien más haciendo un cambio al
   4.208 +mismo fichero. (Esto introduce la idea de que no es tan inusual hacer
   4.209 +fusiones consigo mismo, cuando usted aísla tareas en repositorios
   4.210 +separados, y de hecho encuentra conflictos al hacerlo.)
   4.211  \interaction{tour-merge-conflict.son}
   4.212 -Having created two different versions of the file, we'll set up an
   4.213 -environment suitable for running our merge.
   4.214 +Ahora que tenemos dos versiones diferentes de nuestro fichero,
   4.215 +crearemos un entorno adecuado para hacer la fusión.
   4.216  \interaction{tour-merge-conflict.pull}
   4.217  
   4.218 -In this example, I won't use Mercurial's normal \command{hgmerge}
   4.219 -program to do the merge, because it would drop my nice automated
   4.220 -example-running tool into a graphical user interface.  Instead, I'll
   4.221 -set \envar{HGMERGE} to tell Mercurial to use the non-interactive
   4.222 -\command{merge} command.  This is bundled with many Unix-like systems.
   4.223 -If you're following this example on your computer, don't bother
   4.224 -setting \envar{HGMERGE}.
   4.225 +En este ejemplo, no usaré el comando normal de Mercurial para hacer la
   4.226 +fusión (\command{hgmerge}), porque lanzaría mi linda herramienta
   4.227 +automatizada para correr ejemplos dentro de una interfaz gráfica de
   4.228 +usuario. En vez de eso, definiré la variable de entorno
   4.229 +\envar{HGMERGE} para indicarle a Mercurial que use el comando
   4.230 +\command{merge}. Este comando forma parte de la instalación base de
   4.231 +muchos sistemas Unix y similares. Si usted está ejecutando este
   4.232 +ejemplo en su computador, no se moleste en definir \envar{HGMERGE}.
   4.233  \interaction{tour-merge-conflict.merge}
   4.234 -Because \command{merge} can't resolve the conflicting changes, it
   4.235 -leaves \emph{merge markers} inside the file that has conflicts,
   4.236 -indicating which lines have conflicts, and whether they came from our
   4.237 -version of the file or theirs.
   4.238 -
   4.239 -Mercurial can tell from the way \command{merge} exits that it wasn't
   4.240 -able to merge successfully, so it tells us what commands we'll need to
   4.241 -run if we want to redo the merging operation.  This could be useful
   4.242 -if, for example, we were running a graphical merge tool and quit
   4.243 -because we were confused or realised we had made a mistake.
   4.244 -
   4.245 -If automatic or manual merges fail, there's nothing to prevent us from
   4.246 -``fixing up'' the affected files ourselves, and committing the results
   4.247 -of our merge:
   4.248 +Debido a que \command{merge} no puede resolver los conflictos que
   4.249 +aparecen, él deja \emph{marcadores de fusión} en el fichero con
   4.250 +conflictos, indicando si provienen de nuestra versión o de la de
   4.251 +ellos.
   4.252 +
   4.253 +Mercurial puede saber ---por el código de salida del comando
   4.254 +\command{merge}--- que no fue posible hacer la fusión exitosamente,
   4.255 +así que nos indica qué comandos debemos ejecutar si queremos rehacer
   4.256 +la fusión. Esto puede ser útil si, por ejemplo, estamos ejecutando una
   4.257 +herramienta gráfica de fusión y salimos de ella porque nos confundimos
   4.258 +o cometimos un error.
   4.259 +
   4.260 +Si la fusión ---automática o manual--- falla, no hay nada que nos
   4.261 +impida ``arreglar'' los ficheros afectados por nosotros mismos, y
   4.262 +consignar los resultados de nuestra fusión:
   4.263 +% TODO este mercurial no tiene el comando resolve. Revisar si sigue
   4.264 +% siendo necesario
   4.265  \interaction{tour-merge-conflict.commit}
   4.266  
   4.267 -\section{Simplifying the pull-merge-commit sequence}
   4.268 +\section{Simplificar el ciclo jalar-fusionar-consignar}
   4.269  \label{sec:tour-merge:fetch}
   4.270  
   4.271 -The process of merging changes as outlined above is straightforward,
   4.272 -but requires running three commands in sequence.
   4.273 +El proceso de fusionar cambios delineado anteriomente es directo, pero
   4.274 +requiere la ejecución de tres comandos en sucesión.
   4.275  \begin{codesample2}
   4.276    hg pull
   4.277    hg merge
   4.278 -  hg commit -m 'Merged remote changes'
   4.279 +  hg commit -m 'Fusionados cambios remotos'
   4.280  \end{codesample2}
   4.281 -In the case of the final commit, you also need to enter a commit
   4.282 -message, which is almost always going to be a piece of uninteresting
   4.283 -``boilerplate'' text.
   4.284 -
   4.285 -It would be nice to reduce the number of steps needed, if this were
   4.286 -possible.  Indeed, Mercurial is distributed with an extension called
   4.287 -\hgext{fetch} that does just this.
   4.288 -
   4.289 -Mercurial provides a flexible extension mechanism that lets people
   4.290 -extend its functionality, while keeping the core of Mercurial small
   4.291 -and easy to deal with.  Some extensions add new commands that you can
   4.292 -use from the command line, while others work ``behind the scenes,''
   4.293 -for example adding capabilities to the server.
   4.294 -
   4.295 -The \hgext{fetch} extension adds a new command called, not
   4.296 -surprisingly, \hgcmd{fetch}.  This extension acts as a combination of
   4.297 -\hgcmd{pull}, \hgcmd{update} and \hgcmd{merge}.  It begins by pulling
   4.298 -changes from another repository into the current repository.  If it
   4.299 -finds that the changes added a new head to the repository, it begins a
   4.300 -merge, then commits the result of the merge with an
   4.301 -automatically-generated commit message.  If no new heads were added,
   4.302 -it updates the working directory to the new tip changeset.
   4.303 -
   4.304 -Enabling the \hgext{fetch} extension is easy.  Edit your
   4.305 -\sfilename{.hgrc}, and either go to the \rcsection{extensions} section
   4.306 -or create an \rcsection{extensions} section.  Then add a line that
   4.307 -simply reads ``\Verb+fetch +''.
   4.308 +En la consignación final usted debe proveer un mensaje adecuado, que
   4.309 +casi siempre es un fragmento de texto ``de relleno'' carente de valor
   4.310 +particular.
   4.311 +
   4.312 +Sería agradable reducir la cantidad de pasos necesarios, si fuera
   4.313 +posible. De hecho, Mercurial es distribuido junto con una extensión
   4.314 +llamada \hgext{fetch}\ndt{Descargar, traer.} que hace precisamente
   4.315 +esto.
   4.316 +
   4.317 +Mercurial cuenta con un mecanismo de extensión flexible que le permite
   4.318 +% TODO lets people => permite a usuarios
   4.319 +a sus usuarios extender su funcionalidad, manteniendo el núcleo de
   4.320 +Mercurial pequeño y fácil de manejar. Algunas extensiones añaden
   4.321 +nuevos comandos que usted puede usar desde la línea de comandos,
   4.322 +mientras que otros funcionan ``tras bambalinas'', por ejemplo,
   4.323 +añadiendo funcionalidad al servidor.
   4.324 +
   4.325 +La extensión \hgext{fetch} añade un comando llamado, no
   4.326 +sorpresivamente, \hgcmd{fetch}.  Esta extensión actúa como una
   4.327 +combinación de \hgcmd{pull}, \hgcmd{update} y \hgcmd{merge}.  Empieza
   4.328 +jalando cambios de otro repositorio al repositorio actual. Si
   4.329 +encuentra que los cambios añaden un nuevo frente en el repositorio
   4.330 +actual, inicia una fusión, y luego consigna el resultado de la misma
   4.331 +con un mensaje generado automáticamente. Si no se añadieron nuevos
   4.332 +frentes, actualiza el directorio de trabajo con el nuevo conjunto de
   4.333 +cambios de punta.
   4.334 +
   4.335 +Activar la extensión \hgext{fetch} es fácil. Edite su
   4.336 +\sfilename{.hgrc}, y vaya a (o cree) la sección
   4.337 +\rcsection{extensions}.  Luego añada una línea que diga simplemente
   4.338 +``\Verb+fetch +''.
   4.339  \begin{codesample2}
   4.340    [extensions]
   4.341    fetch =
   4.342  \end{codesample2}
   4.343 -(Normally, on the right-hand side of the ``\texttt{=}'' would appear
   4.344 -the location of the extension, but since the \hgext{fetch} extension
   4.345 -is in the standard distribution, Mercurial knows where to search for
   4.346 -it.)
   4.347 +(Normalmente, a la derecha del ``\texttt{=}'' debería aparecer la
   4.348 +ubicación de la extensión, pero como el comando \hgext{fetch} es parte
   4.349 +de la distribución estándar, Mercurial sabe dónde buscarla.)
   4.350  
   4.351  %%% Local Variables: 
   4.352  %%% mode: latex