hgbook
changeset 423:f907df38efef
translated some paragraphs. updated project status info
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Tue Nov 18 22:48:55 2008 -0500 (2008-11-18) |
parents | 59fbfb7e790c |
children | 9221accc2ccc |
files | es/Leame.1st es/concepts.tex |
line diff
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