1.1 --- a/es/Leame.1st	Mon Nov 03 15:11:36 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Nov 03 21:00:32 2008 -0500
     1.3 @@ -101,6 +101,7 @@
     1.4  || tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
     1.5  || undo.tex        || Igor Támara   ||     15%    || 26/10/2008 ||             ||
     1.6  || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
     1.7 +|| concepts.tex    || Javier Rojas  ||      4%    || 03/11/2008 ||             ||
     1.8  
     1.9  == Archivos en proceso de revisión ==
    1.10  ||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||

     2.1 --- a/es/concepts.tex	Mon Nov 03 15:11:36 2008 -0500
     2.2 +++ b/es/concepts.tex	Mon Nov 03 21:00:32 2008 -0500
     2.3 @@ -1,26 +1,29 @@
     2.4 -\chapter{Behind the scenes}
     2.5 +\chapter{Tras bambalinas}
     2.6  \label{chap:concepts}
     2.7  
     2.8 -Unlike many revision control systems, the concepts upon which
     2.9 -Mercurial is built are simple enough that it's easy to understand how
    2.10 -the software really works.  Knowing this certainly isn't necessary,
    2.11 -but I find it useful to have a ``mental model'' of what's going on.
    2.12 -
    2.13 -This understanding gives me confidence that Mercurial has been
    2.14 -carefully designed to be both \emph{safe} and \emph{efficient}.  And
    2.15 -just as importantly, if it's easy for me to retain a good idea of what
    2.16 -the software is doing when I perform a revision control task, I'm less
    2.17 -likely to be surprised by its behaviour.
    2.18 -
    2.19 -In this chapter, we'll initially cover the core concepts behind
    2.20 -Mercurial's design, then continue to discuss some of the interesting
    2.21 -details of its implementation.
    2.22 -
    2.23 -\section{Mercurial's historical record}
    2.24 -
    2.25 -\subsection{Tracking the history of a single file}
    2.26 -
    2.27 -When Mercurial tracks modifications to a file, it stores the history
    2.28 +A diferencia de varios sistemas de control de revisiones, los
    2.29 +conceptos en los que se fundamenta Mercurial son lo suficientemente
    2.30 +simples como para entender fácilmente cómo funciona el software. 
    2.31 +Saber esto no es necesario, pero considero útil tener un ``modelo
    2.32 +mental'' de qué es lo que sucede.
    2.33 +
    2.34 +Comprender esto me da la confianza de que Mercurial ha sido
    2.35 +cuidadosamente diseñado para ser tanto \emph{seguro} como
    2.36 +\emph{eficiente}.  Y tal vez con la misma importancia, si es fácil
    2.37 +para mí hacerme a una idea adecuada de qué está haciendo el software
    2.38 +cuando llevo a cabo una tarea relacionada con control de revisiones,
    2.39 +es menos probable que me sosprenda su comportamiento.
    2.40 +
    2.41 +En este capítulo, cubriremos inicialmente los conceptos centrales
    2.42 +del diseño de Mercurial, y luego discutiremos algunos detalles
    2.43 +interesantes de su implementación.
    2.44 +
    2.45 +\section{Registro del historial de Mercurial}
    2.46 +
    2.47 +\subsection{Seguir el historial de un único fichero}
    2.48 +
    2.49 +Cuando Mercurial sigue las modificaciones a un fichero, guarda el
    2.50 +historial de dicho fichero en un objeto de metadatos llamado
    2.51  of that file in a metadata object called a \emph{filelog}.  Each entry
    2.52  in the filelog contains enough information to reconstruct one revision
    2.53  of the file that is being tracked.  Filelogs are stored as files in