1.1 --- a/es/concepts.tex	Mon Nov 17 20:04:37 2008 -0500
     1.2 +++ b/es/concepts.tex	Tue Nov 18 22:48:55 2008 -0500
     1.3 @@ -443,71 +443,77 @@
     1.4  terminan automáticamente, sin requerir la interacción del usuario para
     1.5  resolver ningún conflicto.
     1.6  
     1.7 -When you're thinking about what happens when you commit after a merge,
     1.8 -once again the working directory is ``the changeset I'm about to
     1.9 -commit''.  After the \hgcmd{merge} command completes, the working
    1.10 -directory has two parents; these will become the parents of the new
    1.11 -changeset.
    1.12 -
    1.13 -Mercurial lets you perform multiple merges, but you must commit the
    1.14 -results of each individual merge as you go.  This is necessary because
    1.15 -Mercurial only tracks two parents for both revisions and the working
    1.16 -directory.  While it would be technically possible to merge multiple
    1.17 -changesets at once, the prospect of user confusion and making a
    1.18 -terrible mess of a merge immediately becomes overwhelming.
    1.19 -
    1.20 -\section{Other interesting design features}
    1.21 -
    1.22 -In the sections above, I've tried to highlight some of the most
    1.23 -important aspects of Mercurial's design, to illustrate that it pays
    1.24 -careful attention to reliability and performance.  However, the
    1.25 -attention to detail doesn't stop there.  There are a number of other
    1.26 -aspects of Mercurial's construction that I personally find
    1.27 -interesting.  I'll detail a few of them here, separate from the ``big
    1.28 -ticket'' items above, so that if you're interested, you can gain a
    1.29 -better idea of the amount of thinking that goes into a well-designed
    1.30 -system.
    1.31 -
    1.32 -\subsection{Clever compression}
    1.33 -
    1.34 -When appropriate, Mercurial will store both snapshots and deltas in
    1.35 -compressed form.  It does this by always \emph{trying to} compress a
    1.36 -snapshot or delta, but only storing the compressed version if it's
    1.37 -smaller than the uncompressed version.
    1.38 -
    1.39 -This means that Mercurial does ``the right thing'' when storing a file
    1.40 -whose native form is compressed, such as a \texttt{zip} archive or a
    1.41 -JPEG image.  When these types of files are compressed a second time,
    1.42 -the resulting file is usually bigger than the once-compressed form,
    1.43 -and so Mercurial will store the plain \texttt{zip} or JPEG.
    1.44 -
    1.45 -Deltas between revisions of a compressed file are usually larger than
    1.46 -snapshots of the file, and Mercurial again does ``the right thing'' in
    1.47 -these cases.  It finds that such a delta exceeds the threshold at
    1.48 -which it should store a complete snapshot of the file, so it stores
    1.49 -the snapshot, again saving space compared to a naive delta-only
    1.50 -approach.
    1.51 -
    1.52 -\subsubsection{Network recompression}
    1.53 -
    1.54 -When storing revisions on disk, Mercurial uses the ``deflate''
    1.55 -compression algorithm (the same one used by the popular \texttt{zip}
    1.56 -archive format), which balances good speed with a respectable
    1.57 -compression ratio.  However, when transmitting revision data over a
    1.58 -network connection, Mercurial uncompresses the compressed revision
    1.59 -data.
    1.60 -
    1.61 -If the connection is over HTTP, Mercurial recompresses the entire
    1.62 -stream of data using a compression algorithm that gives a better
    1.63 -compression ratio (the Burrows-Wheeler algorithm from the widely used
    1.64 -\texttt{bzip2} compression package).  This combination of algorithm
    1.65 -and compression of the entire stream (instead of a revision at a time)
    1.66 -substantially reduces the number of bytes to be transferred, yielding
    1.67 -better network performance over almost all kinds of network.
    1.68 -
    1.69 -(If the connection is over \command{ssh}, Mercurial \emph{doesn't}
    1.70 -recompress the stream, because \command{ssh} can already do this
    1.71 -itself.)
    1.72 +Cuando considere qué pasa cuando usted hace una consignación después
    1.73 +de una fusión, de nuevo el directorio de trabajo es ``el conjunto de
    1.74 +cambios que estoy a punto de consignar''. Una vez termina su trabajo
    1.75 +el comando \hgcmd{merge}, el directorio de trabajo tiene dos padre;
    1.76 +éstos se convertirán en los padres del nuevo conjunto de cambios.
    1.77 +
    1.78 +Mercurial le permite hacer múltiples fusiones, pero usted debe
    1.79 +consignar los resultados de cada fusión sucesivamente. Esto es
    1.80 +necesario porque Mercurial sólo monitorea dos padres, tanto para las
    1.81 +revisiones como para los directorios de trabajo. Aunque técnicamente
    1.82 +es posible fusionar varios conjuntos de trabajo en una sola operación,
    1.83 +la posibilidad de confundir al usuario y crear un desorden terrible en
    1.84 +la fusión se hace incontenible de inmediato.
    1.85 +
    1.86 +\section{Otras características de diseño interesantes}
    1.87 +
    1.88 +En las secciones anteriores, he tratado de resaltar algunos de los
    1.89 +aspectos más importantes del diseño de Mercurial, para mostrar que se
    1.90 +presta gran cuidado y atención a la confiabilidad y el desempeño. Sin
    1.91 +embargo, la atención a los detalles no para ahí. Hay una cantidad de
    1.92 +aspectos de la construcción de Mercurial que encuentro interesantes
    1.93 +personalmente. Detallaré unos cuantos de ellos aquí, aparte de los
    1.94 +elementos ``importantes'' de arriba, para que, si usted está
    1.95 +% TODO the amount of thinking => (la cantidad de) esfuerzo mental
    1.96 +interesado, pueda obetener una idea mejor de la cantidad de esfuerzo
    1.97 +mental invertido en el diseño de un sistema bien diseñado.
    1.98 +
    1.99 +
   1.100 +\subsection{Compresión ingeniosa}
   1.101 +
   1.102 +Cuando es adecuado, Mercurial almacenará tanto las instantáneas como
   1.103 +los deltas en formato comprimido. Lo hace \emph{tratando} siempre de
   1.104 +comprimir una instantánea o delta, y conservando la versión comprimida
   1.105 +sólo si es más pequeña que la versión sin compresión.
   1.106 +
   1.107 +Esto implica que Mercurial hace ``lo correcto'' cuando almacena un
   1.108 +fichero cuyo formato original está comprimido, como un fichero
   1.109 +\texttt{zip} o una imagen JPEG.  Cuando estos tipos de ficheros son
   1.110 +comprimidos por segunda vez, el fichero resultante usualmente es más
   1.111 +grande que la versión comprimida una sola vez, por lo que Mercurial
   1.112 +almacenará el fichero \texttt{zip} o JPEG original.
   1.113 +
   1.114 +Los deltas entre revisiones de un fichero comprimido usualmente son
   1.115 +más grandes que las instantáneas del mismo fichero, y Mercurial de
   1.116 +nuevo hace ``lo correcto'' en estos casos. Él encuentra que dicho
   1.117 +delta excede el umbral respecto al cual se debería almacenar una
   1.118 +instantánea completa del fichero, así que almacena la instantánea,
   1.119 +ahorrando espacio de nuevo respecto al enfoque simplista de usar
   1.120 +únicamente deltas.
   1.121 +
   1.122 +\subsubsection{Recompresión de red}
   1.123 +
   1.124 +Cuando almacena las revisiones en disco, Mercurial usa el algoritmo de
   1.125 +compresión ``deflación'' (el mismo usado en el popular formato de
   1.126 +fichero \texttt{zip}), que provee una buena velocidad con una tasa de
   1.127 +compresión respetable. Sin embargo, cuando se transmiten datos de
   1.128 +revisiones a través de una conexión de red, Mercurial descomprime los
   1.129 +datos comprimidos de las revisiones.
   1.130 +
   1.131 +Si la conexión es hecha a través de HTTP, Mercurial recomprime el
   1.132 +flujo completo de datos usando un algoritmo de compresión que brinda
   1.133 +una mejor tasa de compresión (el algoritmo Burrows-Wheeler de el
   1.134 +ampliamente usado paquete de compresión \texttt{bzip2}). Esta
   1.135 +combinación de algoritmo y compresión del flujo completo de datos
   1.136 +(en vez de una revisión a la vez) reduce sustancialmente la cantidad
   1.137 +de bytes a transferir, brindando así un mejor desempeño de red sobre
   1.138 +casi todo tipo de redes.
   1.139 +
   1.140 +(Si la conexión se hace sobre \command{ssh}, Mercurial \emph{no}
   1.141 +recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
   1.142 +mismo.)
   1.143  
   1.144  \subsection{Read/write ordering and atomicity}
   1.145