1.1 --- a/es/concepts.tex	Tue Nov 11 23:21:00 2008 -0500
     1.2 +++ b/es/concepts.tex	Wed Nov 12 22:36:35 2008 -0500
     1.3 @@ -202,31 +202,34 @@
     1.4  
     1.5  \subsection{Identificación e integridad fuerte}
     1.6  
     1.7 -Además de la información de deltas e instantáneas, una entrada en un revlog
     1.8 +Además de la información de deltas e instantáneas, una entrada en un
     1.9  % TODO de pronto aclarar qué diablos es un hash?
    1.10 -contiene un hash criptográfico de los datos que representa. Esto hace difícil 
    1.11 -cryptographic hash of the data that it represents.  This makes it
    1.12 -difficult to forge the contents of a revision, and easy to detect
    1.13 -accidental corruption.  
    1.14 -
    1.15 -Hashes provide more than a mere check against corruption; they are
    1.16 -used as the identifiers for revisions.  The changeset identification
    1.17 -hashes that you see as an end user are from revisions of the
    1.18 -changelog.  Although filelogs and the manifest also use hashes,
    1.19 -Mercurial only uses these behind the scenes.
    1.20 -
    1.21 -Mercurial verifies that hashes are correct when it retrieves file
    1.22 -revisions and when it pulls changes from another repository.  If it
    1.23 -encounters an integrity problem, it will complain and stop whatever
    1.24 -it's doing.
    1.25 -
    1.26 -In addition to the effect it has on retrieval efficiency, Mercurial's
    1.27 -use of periodic snapshots makes it more robust against partial data
    1.28 -corruption.  If a revlog becomes partly corrupted due to a hardware
    1.29 -error or system bug, it's often possible to reconstruct some or most
    1.30 -revisions from the uncorrupted sections of the revlog, both before and
    1.31 -after the corrupted section.  This would not be possible with a
    1.32 -delta-only storage model.
    1.33 +revlog contiene un hash criptográfico de los datos que representa.
    1.34 +Esto hace difícil falsificar el contenido de una revisión, y hace
    1.35 +fácil detectar una corrupción accidental.
    1.36 +
    1.37 +Los hashes proveen más que una simple revisión de corrupción: son
    1.38 +usados como los identificadores para las revisiones. 
    1.39 +% TODO no entendí completamente la frase a continuación
    1.40 +Los hashes de
    1.41 +identificación de conjuntos de cambios que usted ve como usuario final
    1.42 +son de las revisiones de la bitácora de cambios. Aunque los ficheros
    1.43 +de registro y el manifiesto también usan hashes, Mercurial sólo los
    1.44 +usa tras bambalinas.
    1.45 +
    1.46 +Mercurial verifica que los hashes sean correctos cuando recupera
    1.47 +revisiones de ficheros y cuando jala cambios desde otro repositorio.
    1.48 +Si se encuentra un problema de integridad, Mercurial se quejará y
    1.49 +detendrá cualquier operación que esté haciendo.
    1.50 +
    1.51 +Además del efecto que tiene en la eficiencia en la recuperación, el
    1.52 +uso periódico de instantáneas de Mercurial lo hace más robusto frente
    1.53 +a la corrupción parcial de datos. Si un fichero de registro se
    1.54 +corrompe parcialmente debido a un error de hardware o del sistema, a
    1.55 +menudo es posible reconstruir algunas o la mayoría de las revisiones a
    1.56 +partir de las secciones no corrompidas del fichero de registro, tanto
    1.57 +antes como después de la sección corrompida. Esto no sería posible con
    1.58 +un sistema de almacenamiento basado únicamente en deltas.
    1.59  
    1.60  \section{Revision history, branching,
    1.61    and merging}