1.1 --- a/es/Leame.1st	Mon Nov 10 23:38:36 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Nov 10 23:39: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   ||     10%    || 10/11/2008 ||             ||
    1.11  

     2.1 --- a/es/concepts.tex	Mon Nov 10 23:38:36 2008 -0500
     2.2 +++ b/es/concepts.tex	Mon Nov 10 23:39: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 aumentar 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