1.1 --- a/es/concepts.tex	Sat Nov 08 23:20:00 2008 -0500
     1.2 +++ b/es/concepts.tex	Sat Nov 08 23:29:59 2008 -0500
     1.3 @@ -90,33 +90,40 @@
     1.4    \label{fig:concepts:metadata}
     1.5  \end{figure}
     1.6  
     1.7 -As the illustration shows, there is \emph{not} a ``one to one''
     1.8 -relationship between revisions in the changelog, manifest, or filelog.
     1.9 -If the manifest hasn't changed between two changesets, the changelog
    1.10 -entries for those changesets will point to the same revision of the
    1.11 -manifest.  If a file that Mercurial tracks hasn't changed between two
    1.12 -changesets, the entry for that file in the two revisions of the
    1.13 -manifest will point to the same revision of its filelog.
    1.14 -
    1.15 -\section{Safe, efficient storage}
    1.16 -
    1.17 -The underpinnings of changelogs, manifests, and filelogs are provided
    1.18 -by a single structure called the \emph{revlog}.
    1.19 -
    1.20 -\subsection{Efficient storage}
    1.21 -
    1.22 -The revlog provides efficient storage of revisions using a
    1.23 -\emph{delta} mechanism.  Instead of storing a complete copy of a file
    1.24 -for each revision, it stores the changes needed to transform an older
    1.25 -revision into the new revision.  For many kinds of file data, these
    1.26 -deltas are typically a fraction of a percent of the size of a full
    1.27 -copy of a file.
    1.28 -
    1.29 -Some obsolete revision control systems can only work with deltas of
    1.30 -text files.  They must either store binary files as complete snapshots
    1.31 -or encoded into a text representation, both of which are wasteful
    1.32 -approaches.  Mercurial can efficiently handle deltas of files with
    1.33 -arbitrary binary contents; it doesn't need to treat text as special.
    1.34 +Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
    1.35 +entre las revisiones en el conjunto de cambios, el manifiesto, o el
    1.36 +fichero de registro. Si el manifiesto no ha sido modificado de un
    1.37 +conjunto de cambios a otro, las entradas en la bitácora de cambios
    1.38 +para esos conjuntos de cambios apuntarán a la misma revisión del
    1.39 +manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
    1.40 +cambio de un conjunto de cambios a otro, la entrada para dicho fichero
    1.41 +en las dos revisiones del manifiesto apuntará a la misma revisión de
    1.42 +su fichero de registro.
    1.43 +
    1.44 +\section{Almacenamiento seguro y eficiente}
    1.45 +
    1.46 +La base común de las bitácoras de cambios, los manifiestos, y los
    1.47 +ficheros de registros es provista por una única estructura llamada el
    1.48 +\emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
    1.49 +revisión.}.
    1.50 +
    1.51 +\subsection{Almacenamiento eficiente}
    1.52 +
    1.53 +El revlog provee almacenamiento eficiente de revisiones por medio del
    1.54 +mecanismo de \emph{deltas}\ndt{Diferencias.}.  En vez de almacenar una
    1.55 +copia completa del fichero por cada revisión, almacena los cambios
    1.56 +necesarios para transformar una revisión anterior en la nueva
    1.57 +revisión. Para muchos tipos de fichero, estos deltas son típicamente
    1.58 +de una fracción porcentual del tamaño de una copia completa del
    1.59 +fichero.
    1.60 +
    1.61 +Algunos sistemas de control de revisiones obsoletos sólo pueden
    1.62 +manipular deltas de ficheros de texto plano. Ellos o bien almacenan
    1.63 +los ficheros binarios como instantáneas completas, o codificados en
    1.64 +alguna representación de texto plano adecuada, y ambas alternativas
    1.65 +son enfoques que desperdician bastantes recursos. Mercurial puede
    1.66 +manejar deltas de ficheros con contenido binario arbitrario; no
    1.67 +necesita tratar el texto plano como un caso especial.
    1.68  
    1.69  \subsection{Safe operation}
    1.70  \label{sec:concepts:txn}