hgbook
changeset 410:7c84967093e1
translated some paragraphs, and updated the project status file
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Mon Nov 10 22:18:24 2008 -0500 (2008-11-10) |
parents | 04ba1c7785ae |
children | 006cd2b41d11 |
files | es/Leame.1st es/concepts.tex |
line diff
1.1 --- a/es/Leame.1st Sun Nov 09 23:50:07 2008 -0500 1.2 +++ b/es/Leame.1st Mon Nov 10 22:18:24 2008 -0500 1.3 @@ -101,7 +101,7 @@ 1.4 || tour-basic.tex || Javier Rojas || 100% || 19/10/2008 || 27/10/2008 || 1.5 || undo.tex || Igor Támara || 100% || 26/10/2008 || 07/11/2008 || 1.6 || tour-merge.tex || Javier Rojas || 100% || 28/10/2008 || 03/11/2008 || 1.7 -|| concepts.tex || Javier Rojas || 7% || 03/11/2008 || || 1.8 +|| concepts.tex || Javier Rojas || 32% || 03/11/2008 || || 1.9 || intro.tex || Igor Támara || 100% || 08/11/2008 || 09/11/2008 || 1.10 || collab.tex || Igor Támara || 0% || 10/11/2008 || || 1.11
2.1 --- a/es/concepts.tex Sun Nov 09 23:50:07 2008 -0500 2.2 +++ b/es/concepts.tex Mon Nov 10 22:18:24 2008 -0500 2.3 @@ -125,66 +125,71 @@ 2.4 manejar deltas de ficheros con contenido binario arbitrario; no 2.5 necesita tratar el texto plano como un caso especial. 2.6 2.7 -\subsection{Safe operation} 2.8 +\subsection{Operación segura} 2.9 \label{sec:concepts:txn} 2.10 2.11 -Mercurial only ever \emph{appends} data to the end of a revlog file. 2.12 -It never modifies a section of a file after it has written it. This 2.13 -is both more robust and efficient than schemes that need to modify or 2.14 -rewrite data. 2.15 - 2.16 -In addition, Mercurial treats every write as part of a 2.17 -\emph{transaction} that can span a number of files. A transaction is 2.18 -\emph{atomic}: either the entire transaction succeeds and its effects 2.19 -are all visible to readers in one go, or the whole thing is undone. 2.20 -This guarantee of atomicity means that if you're running two copies of 2.21 -Mercurial, where one is reading data and one is writing it, the reader 2.22 -will never see a partially written result that might confuse it. 2.23 - 2.24 -The fact that Mercurial only appends to files makes it easier to 2.25 -provide this transactional guarantee. The easier it is to do stuff 2.26 -like this, the more confident you should be that it's done correctly. 2.27 - 2.28 -\subsection{Fast retrieval} 2.29 - 2.30 -Mercurial cleverly avoids a pitfall common to all earlier 2.31 -revision control systems: the problem of \emph{inefficient retrieval}. 2.32 -Most revision control systems store the contents of a revision as an 2.33 -incremental series of modifications against a ``snapshot''. To 2.34 -reconstruct a specific revision, you must first read the snapshot, and 2.35 -then every one of the revisions between the snapshot and your target 2.36 -revision. The more history that a file accumulates, the more 2.37 -revisions you must read, hence the longer it takes to reconstruct a 2.38 -particular revision. 2.39 +Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca 2.40 +modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más 2.41 +robusto y eficiente que otros esquemas que requieren modificar o reescribir 2.42 +datos. 2.43 + 2.44 +Adicionalmente, Mercurial trata cada escritura como parte de una 2.45 +\emph{transacción}, que puede cubrir varios ficheros. Una transacción es 2.46 +\emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos 2.47 +son visibles para todos los lectores, o la operación completa es cancelada. 2.48 +% TODO atomicidad no existe de acuerdo a DRAE, reemplazar 2.49 +Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de 2.50 +Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo, 2.51 +el lector nunca verá un resultado escrito parcialmente que podría confundirlo. 2.52 + 2.53 +El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil 2.54 +proveer esta garantía transaccional. A medida que sea más fácil hacer 2.55 +operaciones como ésta, más confianza tendrá usted en que sean hechas 2.56 +correctamente. 2.57 + 2.58 +\subsection{Recuperación rápida de datos} 2.59 + 2.60 +Mercurial evita ingeniosamente un problema común a todos los sistemas de control 2.61 +de revisiones anteriores> el problema de la 2.62 +\emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los 2.63 +datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o 2.64 +calamidad, sino a la operación normal del sistema.} ineficiente de datos}. 2.65 +Muchos sistemas de control de revisiones almacenan los contenidos de una 2.66 +revisión como una serie incremental de modificaciones a una ``instantánea''. 2.67 +Para reconstruir una versión cualquiera, primero usted debe leer la instantánea, 2.68 +y luego cada una de las revisiones entre la instantánea y su versión objetivo. 2.69 +Entre más largo sea el historial de un fichero, más revisiones deben ser leídas, 2.70 +y por tanto toma más tiempo reconstruir una versión particular. 2.71 2.72 \begin{figure}[ht] 2.73 \centering 2.74 \grafix{snapshot} 2.75 - \caption{Snapshot of a revlog, with incremental deltas} 2.76 + \caption{Instantánea de un revlog, con deltas incrementales} 2.77 \label{fig:concepts:snapshot} 2.78 \end{figure} 2.79 2.80 -The innovation that Mercurial applies to this problem is simple but 2.81 -effective. Once the cumulative amount of delta information stored 2.82 -since the last snapshot exceeds a fixed threshold, it stores a new 2.83 -snapshot (compressed, of course), instead of another delta. This 2.84 -makes it possible to reconstruct \emph{any} revision of a file 2.85 -quickly. This approach works so well that it has since been copied by 2.86 -several other revision control systems. 2.87 - 2.88 -Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry 2.89 -in a revlog's index file, Mercurial stores the range of entries from 2.90 -the data file that it must read to reconstruct a particular revision. 2.91 - 2.92 -\subsubsection{Aside: the influence of video compression} 2.93 - 2.94 -If you're familiar with video compression or have ever watched a TV 2.95 -feed through a digital cable or satellite service, you may know that 2.96 -most video compression schemes store each frame of video as a delta 2.97 -against its predecessor frame. In addition, these schemes use 2.98 -``lossy'' compression techniques to increase the compression ratio, so 2.99 -visual errors accumulate over the course of a number of inter-frame 2.100 -deltas. 2.101 +La innovación que aplica Mercurial a este problema es simple pero efectiva. 2.102 +Una vez la cantidad de información de deltas acumulada desde la última 2.103 +instantánea excede un umbral fijado de antemano, se almacena una nueva 2.104 +instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace 2.105 +posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este 2.106 +enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas 2.107 +de control de revisiones. 2.108 + 2.109 +La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el 2.110 +fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas) 2.111 +del fichero de datos que se deben leer para reconstruir una revisión en 2.112 +particular. 2.113 + 2.114 +\subsubsection{Nota al margen: la influencia de la compresión de vídeo} 2.115 + 2.116 +Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de 2.117 +TV a través de cable digital o un servicio de satélite, puede que sepa que la 2.118 +mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del 2.119 +mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas 2.120 +usan técnicas de compresión ``con pérdida'' para incrementar la tasa de 2.121 +compresión, por lo que los errores visuales se acumulan a lo largo de una 2.122 +cantidad de deltas inter-cuadros. 2.123 2.124 Because it's possible for a video stream to ``drop out'' occasionally 2.125 due to signal glitches, and to limit the accumulation of artefacts