hgbook
changeset 416:15bf7d50b586
Translated a couple of paragraphs
author | jerojasro@devnull.li |
---|---|
date | Wed Nov 12 22:36:35 2008 -0500 (2008-11-12) |
parents | 0eda2936ef77 |
children | 7e838acf7350 |
files | es/concepts.tex |
line diff
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}