1.1 --- a/es/Leame.1st	Mon Nov 17 20:04:37 2008 -0500
     1.2 +++ b/es/Leame.1st	Tue Nov 18 22:48:55 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  ||     55%    || 03/11/2008 ||             ||
     1.8 +|| concepts.tex    || Javier Rojas  ||     81%    || 03/11/2008 ||             ||
     1.9  || intro.tex	   || Igor Támara   ||	  100%	  || 08/11/2008	||  09/11/2008 ||
    1.10  || collab.tex      || Igor Támara   ||     39%    || 10/11/2008 ||             ||
    1.11  

     2.1 --- a/es/concepts.tex	Mon Nov 17 20:04:37 2008 -0500
     2.2 +++ b/es/concepts.tex	Tue Nov 18 22:48:55 2008 -0500
     2.3 @@ -443,71 +443,77 @@
     2.4  terminan automáticamente, sin requerir la interacción del usuario para
     2.5  resolver ningún conflicto.
     2.6  
     2.7 -When you're thinking about what happens when you commit after a merge,
     2.8 -once again the working directory is ``the changeset I'm about to
     2.9 -commit''.  After the \hgcmd{merge} command completes, the working
    2.10 -directory has two parents; these will become the parents of the new
    2.11 -changeset.
    2.12 -
    2.13 -Mercurial lets you perform multiple merges, but you must commit the
    2.14 -results of each individual merge as you go.  This is necessary because
    2.15 -Mercurial only tracks two parents for both revisions and the working
    2.16 -directory.  While it would be technically possible to merge multiple
    2.17 -changesets at once, the prospect of user confusion and making a
    2.18 -terrible mess of a merge immediately becomes overwhelming.
    2.19 -
    2.20 -\section{Other interesting design features}
    2.21 -
    2.22 -In the sections above, I've tried to highlight some of the most
    2.23 -important aspects of Mercurial's design, to illustrate that it pays
    2.24 -careful attention to reliability and performance.  However, the
    2.25 -attention to detail doesn't stop there.  There are a number of other
    2.26 -aspects of Mercurial's construction that I personally find
    2.27 -interesting.  I'll detail a few of them here, separate from the ``big
    2.28 -ticket'' items above, so that if you're interested, you can gain a
    2.29 -better idea of the amount of thinking that goes into a well-designed
    2.30 -system.
    2.31 -
    2.32 -\subsection{Clever compression}
    2.33 -
    2.34 -When appropriate, Mercurial will store both snapshots and deltas in
    2.35 -compressed form.  It does this by always \emph{trying to} compress a
    2.36 -snapshot or delta, but only storing the compressed version if it's
    2.37 -smaller than the uncompressed version.
    2.38 -
    2.39 -This means that Mercurial does ``the right thing'' when storing a file
    2.40 -whose native form is compressed, such as a \texttt{zip} archive or a
    2.41 -JPEG image.  When these types of files are compressed a second time,
    2.42 -the resulting file is usually bigger than the once-compressed form,
    2.43 -and so Mercurial will store the plain \texttt{zip} or JPEG.
    2.44 -
    2.45 -Deltas between revisions of a compressed file are usually larger than
    2.46 -snapshots of the file, and Mercurial again does ``the right thing'' in
    2.47 -these cases.  It finds that such a delta exceeds the threshold at
    2.48 -which it should store a complete snapshot of the file, so it stores
    2.49 -the snapshot, again saving space compared to a naive delta-only
    2.50 -approach.
    2.51 -
    2.52 -\subsubsection{Network recompression}
    2.53 -
    2.54 -When storing revisions on disk, Mercurial uses the ``deflate''
    2.55 -compression algorithm (the same one used by the popular \texttt{zip}
    2.56 -archive format), which balances good speed with a respectable
    2.57 -compression ratio.  However, when transmitting revision data over a
    2.58 -network connection, Mercurial uncompresses the compressed revision
    2.59 -data.
    2.60 -
    2.61 -If the connection is over HTTP, Mercurial recompresses the entire
    2.62 -stream of data using a compression algorithm that gives a better
    2.63 -compression ratio (the Burrows-Wheeler algorithm from the widely used
    2.64 -\texttt{bzip2} compression package).  This combination of algorithm
    2.65 -and compression of the entire stream (instead of a revision at a time)
    2.66 -substantially reduces the number of bytes to be transferred, yielding
    2.67 -better network performance over almost all kinds of network.
    2.68 -
    2.69 -(If the connection is over \command{ssh}, Mercurial \emph{doesn't}
    2.70 -recompress the stream, because \command{ssh} can already do this
    2.71 -itself.)
    2.72 +Cuando considere qué pasa cuando usted hace una consignación después
    2.73 +de una fusión, de nuevo el directorio de trabajo es ``el conjunto de
    2.74 +cambios que estoy a punto de consignar''. Una vez termina su trabajo
    2.75 +el comando \hgcmd{merge}, el directorio de trabajo tiene dos padre;
    2.76 +éstos se convertirán en los padres del nuevo conjunto de cambios.
    2.77 +
    2.78 +Mercurial le permite hacer múltiples fusiones, pero usted debe
    2.79 +consignar los resultados de cada fusión sucesivamente. Esto es
    2.80 +necesario porque Mercurial sólo monitorea dos padres, tanto para las
    2.81 +revisiones como para los directorios de trabajo. Aunque técnicamente
    2.82 +es posible fusionar varios conjuntos de trabajo en una sola operación,
    2.83 +la posibilidad de confundir al usuario y crear un desorden terrible en
    2.84 +la fusión se hace incontenible de inmediato.
    2.85 +
    2.86 +\section{Otras características de diseño interesantes}
    2.87 +
    2.88 +En las secciones anteriores, he tratado de resaltar algunos de los
    2.89 +aspectos más importantes del diseño de Mercurial, para mostrar que se
    2.90 +presta gran cuidado y atención a la confiabilidad y el desempeño. Sin
    2.91 +embargo, la atención a los detalles no para ahí. Hay una cantidad de
    2.92 +aspectos de la construcción de Mercurial que encuentro interesantes
    2.93 +personalmente. Detallaré unos cuantos de ellos aquí, aparte de los
    2.94 +elementos ``importantes'' de arriba, para que, si usted está
    2.95 +% TODO the amount of thinking => (la cantidad de) esfuerzo mental
    2.96 +interesado, pueda obetener una idea mejor de la cantidad de esfuerzo
    2.97 +mental invertido en el diseño de un sistema bien diseñado.
    2.98 +
    2.99 +
   2.100 +\subsection{Compresión ingeniosa}
   2.101 +
   2.102 +Cuando es adecuado, Mercurial almacenará tanto las instantáneas como
   2.103 +los deltas en formato comprimido. Lo hace \emph{tratando} siempre de
   2.104 +comprimir una instantánea o delta, y conservando la versión comprimida
   2.105 +sólo si es más pequeña que la versión sin compresión.
   2.106 +
   2.107 +Esto implica que Mercurial hace ``lo correcto'' cuando almacena un
   2.108 +fichero cuyo formato original está comprimido, como un fichero
   2.109 +\texttt{zip} o una imagen JPEG.  Cuando estos tipos de ficheros son
   2.110 +comprimidos por segunda vez, el fichero resultante usualmente es más
   2.111 +grande que la versión comprimida una sola vez, por lo que Mercurial
   2.112 +almacenará el fichero \texttt{zip} o JPEG original.
   2.113 +
   2.114 +Los deltas entre revisiones de un fichero comprimido usualmente son
   2.115 +más grandes que las instantáneas del mismo fichero, y Mercurial de
   2.116 +nuevo hace ``lo correcto'' en estos casos. Él encuentra que dicho
   2.117 +delta excede el umbral respecto al cual se debería almacenar una
   2.118 +instantánea completa del fichero, así que almacena la instantánea,
   2.119 +ahorrando espacio de nuevo respecto al enfoque simplista de usar
   2.120 +únicamente deltas.
   2.121 +
   2.122 +\subsubsection{Recompresión de red}
   2.123 +
   2.124 +Cuando almacena las revisiones en disco, Mercurial usa el algoritmo de
   2.125 +compresión ``deflación'' (el mismo usado en el popular formato de
   2.126 +fichero \texttt{zip}), que provee una buena velocidad con una tasa de
   2.127 +compresión respetable. Sin embargo, cuando se transmiten datos de
   2.128 +revisiones a través de una conexión de red, Mercurial descomprime los
   2.129 +datos comprimidos de las revisiones.
   2.130 +
   2.131 +Si la conexión es hecha a través de HTTP, Mercurial recomprime el
   2.132 +flujo completo de datos usando un algoritmo de compresión que brinda
   2.133 +una mejor tasa de compresión (el algoritmo Burrows-Wheeler de el
   2.134 +ampliamente usado paquete de compresión \texttt{bzip2}). Esta
   2.135 +combinación de algoritmo y compresión del flujo completo de datos
   2.136 +(en vez de una revisión a la vez) reduce sustancialmente la cantidad
   2.137 +de bytes a transferir, brindando así un mejor desempeño de red sobre
   2.138 +casi todo tipo de redes.
   2.139 +
   2.140 +(Si la conexión se hace sobre \command{ssh}, Mercurial \emph{no}
   2.141 +recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
   2.142 +mismo.)
   2.143  
   2.144  \subsection{Read/write ordering and atomicity}
   2.145