1.1 --- a/es/concepts.tex	Sat Nov 15 20:04:33 2008 -0500
     1.2 +++ b/es/concepts.tex	Mon Nov 17 20:04:37 2008 -0500
     1.3 @@ -339,99 +339,109 @@
     1.4  hace la consignación; sólo modifica el estado de directorio para
     1.5  anotar sus nuevos padres.
     1.6  
     1.7 -\subsection{Creating a new head}
     1.8 -
     1.9 -It's perfectly normal to update the working directory to a changeset
    1.10 -other than the current tip.  For example, you might want to know what
    1.11 -your project looked like last Tuesday, or you could be looking through
    1.12 -changesets to see which one introduced a bug.  In cases like this, the
    1.13 -natural thing to do is update the working directory to the changeset
    1.14 -you're interested in, and then examine the files in the working
    1.15 -directory directly to see their contents as they werea when you
    1.16 -committed that changeset.  The effect of this is shown in
    1.17 -figure~\ref{fig:concepts:wdir-pre-branch}.
    1.18 +\subsection{Creación de un nuevo frente}
    1.19 +
    1.20 +Es perfectamente normal actualizar el directorio de trabajo a un
    1.21 +conjunto de cambios diferente a la punta actual. Por ejemplo, usted
    1.22 +podría desear saber en qué estado se encontraba su proyecto el martes
    1.23 +pasado, o podría estar buscando en todos los conjuntos de cambios para
    1.24 +saber cuándo se introdujo un fallo. En casos como éstos, la acción
    1.25 +natural es actualizar el directorio de trabajo al conjunto de cambios
    1.26 +de su interés, y examinar directamente los ficheros en el directorio
    1.27 +de trabajo para ver sus contenidos tal como estaban en el momento de
    1.28 +hacer la consignación. El efecto que tiene esto se muestra en la
    1.29 +figura~\ref{fig:concepts:wdir-pre-branch}.
    1.30  
    1.31  \begin{figure}[ht]
    1.32    \centering
    1.33    \grafix{wdir-pre-branch}
    1.34 -  \caption{The working directory, updated to an older changeset}
    1.35 +  \caption{El directorio de trabajo, actualizado a un conjunto de
    1.36 +  cambios anterior}
    1.37    \label{fig:concepts:wdir-pre-branch}
    1.38  \end{figure}
    1.39  
    1.40 -Having updated the working directory to an older changeset, what
    1.41 -happens if you make some changes, and then commit?  Mercurial behaves
    1.42 -in the same way as I outlined above.  The parents of the working
    1.43 -directory become the parents of the new changeset.  This new changeset
    1.44 -has no children, so it becomes the new tip.  And the repository now
    1.45 -contains two changesets that have no children; we call these
    1.46 -\emph{heads}.  You can see the structure that this creates in
    1.47 -figure~\ref{fig:concepts:wdir-branch}.
    1.48 +Una vez se ha actualizado el directorio de trabajo a un conjunto de
    1.49 +cambios anterior, qué pasa si se hacen cambios, y luego se hace una
    1.50 +consignación? Mercurial se comporta en la misma forma que describí
    1.51 +anteriormente. Los padres del directorio de trabajo se convierten en
    1.52 +los padres del nuevo conjunto de cambios. Este nuevo conjunto de
    1.53 +cambios no tiene hijos, así que se convierte en la nueva punta. Y el
    1.54 +repositorio tiene ahora dos conjuntos de cambios que no tienen hijos;
    1.55 +a éstos los llamamos \emph{frentes}. Usted puede apreciar la
    1.56 +estructura que esto crea en la figura~\ref{fig:concepts:wdir-branch}.
    1.57  
    1.58  \begin{figure}[ht]
    1.59    \centering
    1.60    \grafix{wdir-branch}
    1.61 -  \caption{After a commit made while synced to an older changeset}
    1.62 +  \caption{Después de una consignación hecha mientras se usaba un
    1.63 +  conjunto de cambios anterior}
    1.64    \label{fig:concepts:wdir-branch}
    1.65  \end{figure}
    1.66  
    1.67  \begin{note}
    1.68 -  If you're new to Mercurial, you should keep in mind a common
    1.69 -  ``error'', which is to use the \hgcmd{pull} command without any
    1.70 -  options.  By default, the \hgcmd{pull} command \emph{does not}
    1.71 -  update the working directory, so you'll bring new changesets into
    1.72 -  your repository, but the working directory will stay synced at the
    1.73 -  same changeset as before the pull.  If you make some changes and
    1.74 -  commit afterwards, you'll thus create a new head, because your
    1.75 -  working directory isn't synced to whatever the current tip is.
    1.76 -
    1.77 -  I put the word ``error'' in quotes because all that you need to do
    1.78 -  to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}.  In
    1.79 -  other words, this almost never has negative consequences; it just
    1.80 -  surprises people.  I'll discuss other ways to avoid this behaviour,
    1.81 -  and why Mercurial behaves in this initially surprising way, later
    1.82 -  on.
    1.83 +    Si usted es nuevo en Mercurial, debería tener en mente un
    1.84 +    ``error'' común, que es usar el comando \hgcmd{pull} sin ninguna
    1.85 +    opción. Por defecto, el comando \hgcmd{pull} \emph{no} actualiza
    1.86 +    el directorio de trabajo, así que usted termina trayendo nuevos
    1.87 +    conjuntos de cambios a su repositorio, pero el directorio de
    1.88 +    trabajo sigue usando el mismo conjunto de cambios que tenía antes
    1.89 +    de jalar. Si usted hace algunos cambios, y luego hace una
    1.90 +    consignación, estará creando un nuevo frente, porque su directorio
    1.91 +    de trabajo no es sincronizado a cualquiera que sea la nueva punta.
    1.92 +
    1.93 +    Pongo la palabra ``error'' en comillas porque todo lo que usted
    1.94 +    debe hacer para rectificar la situación es hacer una fusión
    1.95 +    (\hgcmd{merge}), y luego una consignación (\hgcmd{commit}). En
    1.96 +    otras palabras, esto casi nunca tiene consecuencias negativas;
    1.97 +    sólo sorprende a la gente. Discutiré otras formas de evitar este
    1.98 +    comportamiento, y porqué Mercurial se comporta de esta forma,
    1.99 +    inicialmente sorprendente, más adelante.
   1.100  \end{note}
   1.101  
   1.102 -\subsection{Merging heads}
   1.103 -
   1.104 -When you run the \hgcmd{merge} command, Mercurial leaves the first
   1.105 -parent of the working directory unchanged, and sets the second parent
   1.106 -to the changeset you're merging with, as shown in
   1.107 -figure~\ref{fig:concepts:wdir-merge}.
   1.108 +\subsection{Fusión de frentes}
   1.109 +
   1.110 +Cuando usted ejecuta el comando \hgcmd{merge}, Mercurial deja el
   1.111 +primer padre del directorio de trabajo intacto, y escribe como segundo
   1.112 +padre el conjunto de cambios contra el cual usted está haciendo la
   1.113 +fusión, como se muestra en la figura~\ref{fig:concepts:wdir-merge}.
   1.114  
   1.115  \begin{figure}[ht]
   1.116    \centering
   1.117    \grafix{wdir-merge}
   1.118 -  \caption{Merging two heads}
   1.119 +  \caption{Fusión de dos frentes}
   1.120    \label{fig:concepts:wdir-merge}
   1.121  \end{figure}
   1.122  
   1.123 -Mercurial also has to modify the working directory, to merge the files
   1.124 -managed in the two changesets.  Simplified a little, the merging
   1.125 -process goes like this, for every file in the manifests of both
   1.126 -changesets.
   1.127 +Mercurial también debe modificar el directorio de trabajo, para
   1.128 +fusionar los ficheros que él monitorea en los dos conjuntos de
   1.129 +cambios. Con algunas simplificaciones, el proceso es el siguiente, por
   1.130 +cada fichero en los manifiestos de ambos conjuntos de cambios.
   1.131  \begin{itemize}
   1.132 -\item If neither changeset has modified a file, do nothing with that
   1.133 -  file.
   1.134 -\item If one changeset has modified a file, and the other hasn't,
   1.135 -  create the modified copy of the file in the working directory.
   1.136 -\item If one changeset has removed a file, and the other hasn't (or
   1.137 -  has also deleted it), delete the file from the working directory.
   1.138 -\item If one changeset has removed a file, but the other has modified
   1.139 -  the file, ask the user what to do: keep the modified file, or remove
   1.140 -  it?
   1.141 -\item If both changesets have modified a file, invoke an external
   1.142 -  merge program to choose the new contents for the merged file.  This
   1.143 -  may require input from the user.
   1.144 -\item If one changeset has modified a file, and the other has renamed
   1.145 -  or copied the file, make sure that the changes follow the new name
   1.146 -  of the file.
   1.147 +\item Si ningún conjunto de cambios ha modificado un fichero, no se
   1.148 +    hace nada con el mismo.
   1.149 +\item Si un conjunto de cambios ha modificado un fichero, y el otro no
   1.150 +    lo ha hecho, se crea una copia del fichero con las modificaciones
   1.151 +    pertinentes en el directorio de trabajo.
   1.152 +\item Si un conjunto de cambios borra un fichero, y el otro no lo ha
   1.153 +    hecho (o también lo borró), se borra dicho fichero del directorio
   1.154 +    de trabajo.
   1.155 +\item Si un conjunto de cambios ha borrado un fichero, pero el otro lo ha
   1.156 +    modificado, se le pregunta al usuario qué hacer: conservar el
   1.157 +    fichero modificado, o borrarlo?
   1.158 +\item Si ambos conjuntos de cambios han modificado un fichero, se
   1.159 +    invoca el programa externo de fusión para definir el nuevo
   1.160 +    contenido del fichero fusionado. Esto puede requerir interacción
   1.161 +    directa de parte del usuario.
   1.162 +\item Si un conjunto de cambios ha modificado un fichero, y el otro ha
   1.163 +    renombrado o copiado el mismo, asegurarse de que los cambios sigan
   1.164 +    al nuevo nombre de fichero.
   1.165  \end{itemize}
   1.166 -There are more details---merging has plenty of corner cases---but
   1.167 -these are the most common choices that are involved in a merge.  As
   1.168 -you can see, most cases are completely automatic, and indeed most
   1.169 -merges finish automatically, without requiring your input to resolve
   1.170 -any conflicts.
   1.171 +Hay más detalles---hacer una fusión tiene una gran cantidad de casos
   1.172 +especiales---pero éstas son las elecciones más comunes que se ven
   1.173 +involucradas en una fusión. Como usted puede ver, muchos de los casos
   1.174 +son completamente automáticos, y de hecho la mayoría de las fusiones
   1.175 +terminan automáticamente, sin requerir la interacción del usuario para
   1.176 +resolver ningún conflicto.
   1.177  
   1.178  When you're thinking about what happens when you commit after a merge,
   1.179  once again the working directory is ``the changeset I'm about to