hgbook
changeset 406:446d1b4b7a71
translated up to section 4.2.1, included
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Sat Nov 08 23:29:59 2008 -0500 (2008-11-08) |
parents | 779944196e2a |
children | 8b564f6f57f2 |
files | es/concepts.tex |
line diff
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}