hgbook
changeset 426:e5739e8d708f
finished file "concepts.tex". Upgraded project status file
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Sun Nov 23 13:22:45 2008 -0500 (2008-11-23) |
parents | 2b4022f9e3f8 |
children | 4a1dc5e8e2ff |
files | es/Leame.1st es/concepts.tex |
line diff
1.1 --- a/es/Leame.1st Fri Nov 21 00:07:44 2008 -0500 1.2 +++ b/es/Leame.1st Sun Nov 23 13:22:45 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 || 81% || 03/11/2008 || || 1.8 +|| concepts.tex || Javier Rojas || 100% || 03/11/2008 || 23/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 Fri Nov 21 00:07:44 2008 -0500 2.2 +++ b/es/concepts.tex Sun Nov 23 13:22:45 2008 -0500 2.3 @@ -549,88 +549,100 @@ 2.4 está escribiendo al mismo o no. 2.5 2.6 La naturaleza carente de bloqueos de la lectura significa que si usted 2.7 -está compartiendo un repositorio 2.8 -The lockless nature of reading means that if you're sharing a 2.9 -repository on a multi-user system, you don't need to grant other local 2.10 -users permission to \emph{write} to your repository in order for them 2.11 -to be able to clone it or pull changes from it; they only need 2.12 -\emph{read} permission. (This is \emph{not} a common feature among 2.13 -revision control systems, so don't take it for granted! Most require 2.14 -readers to be able to lock a repository to access it safely, and this 2.15 -requires write permission on at least one directory, which of course 2.16 -makes for all kinds of nasty and annoying security and administrative 2.17 -problems.) 2.18 - 2.19 -Mercurial uses locks to ensure that only one process can write to a 2.20 -repository at a time (the locking mechanism is safe even over 2.21 -filesystems that are notoriously hostile to locking, such as NFS). If 2.22 -a repository is locked, a writer will wait for a while to retry if the 2.23 -repository becomes unlocked, but if the repository remains locked for 2.24 -too long, the process attempting to write will time out after a while. 2.25 -This means that your daily automated scripts won't get stuck forever 2.26 -and pile up if a system crashes unnoticed, for example. (Yes, the 2.27 -timeout is configurable, from zero to infinity.) 2.28 - 2.29 -\subsubsection{Safe dirstate access} 2.30 - 2.31 -As with revision data, Mercurial doesn't take a lock to read the 2.32 -dirstate file; it does acquire a lock to write it. To avoid the 2.33 -possibility of reading a partially written copy of the dirstate file, 2.34 -Mercurial writes to a file with a unique name in the same directory as 2.35 -the dirstate file, then renames the temporary file atomically to 2.36 -\filename{dirstate}. The file named \filename{dirstate} is thus 2.37 -guaranteed to be complete, not partially written. 2.38 - 2.39 -\subsection{Avoiding seeks} 2.40 - 2.41 -Critical to Mercurial's performance is the avoidance of seeks of the 2.42 -disk head, since any seek is far more expensive than even a 2.43 -comparatively large read operation. 2.44 - 2.45 -This is why, for example, the dirstate is stored in a single file. If 2.46 -there were a dirstate file per directory that Mercurial tracked, the 2.47 -disk would seek once per directory. Instead, Mercurial reads the 2.48 -entire single dirstate file in one step. 2.49 - 2.50 -Mercurial also uses a ``copy on write'' scheme when cloning a 2.51 -repository on local storage. Instead of copying every revlog file 2.52 -from the old repository into the new repository, it makes a ``hard 2.53 -link'', which is a shorthand way to say ``these two names point to the 2.54 -same file''. When Mercurial is about to write to one of a revlog's 2.55 -files, it checks to see if the number of names pointing at the file is 2.56 -greater than one. If it is, more than one repository is using the 2.57 -file, so Mercurial makes a new copy of the file that is private to 2.58 -this repository. 2.59 - 2.60 -A few revision control developers have pointed out that this idea of 2.61 -making a complete private copy of a file is not very efficient in its 2.62 -use of storage. While this is true, storage is cheap, and this method 2.63 -gives the highest performance while deferring most book-keeping to the 2.64 -operating system. An alternative scheme would most likely reduce 2.65 -performance and increase the complexity of the software, each of which 2.66 -is much more important to the ``feel'' of day-to-day use. 2.67 - 2.68 -\subsection{Other contents of the dirstate} 2.69 - 2.70 -Because Mercurial doesn't force you to tell it when you're modifying a 2.71 -file, it uses the dirstate to store some extra information so it can 2.72 -determine efficiently whether you have modified a file. For each file 2.73 -in the working directory, it stores the time that it last modified the 2.74 -file itself, and the size of the file at that time. 2.75 - 2.76 -When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or 2.77 -\hgcmd{copy} files, Mercurial updates the dirstate so that it knows 2.78 -what to do with those files when you commit. 2.79 - 2.80 -When Mercurial is checking the states of files in the working 2.81 -directory, it first checks a file's modification time. If that has 2.82 -not changed, the file must not have been modified. If the file's size 2.83 -has changed, the file must have been modified. If the modification 2.84 -time has changed, but the size has not, only then does Mercurial need 2.85 -to read the actual contents of the file to see if they've changed. 2.86 -Storing these few extra pieces of information dramatically reduces the 2.87 -amount of data that Mercurial needs to read, which yields large 2.88 -performance improvements compared to other revision control systems. 2.89 +está compartiendo un repositorio en un sistema multiusuario, no 2.90 +necesita dar a los usuarios locales permisos de \emph{escritura} a su 2.91 +repositorio para que ellos puedan clonarlo o jalar cambios; sólo 2.92 +necesitan permisos de \emph{lectura}. (Esta \emph{no} es una 2.93 +%TODO signo de admiración de apertura 2.94 +característica común entre los sistemas de control de revisiones, así 2.95 +que no la dé por hecha! Muchos de ellos requieren que los lectores 2.96 +sean capaces de bloquear el repositorio antes de poder leerlo, y esto 2.97 +requiere acceso de escritura en al menos un directorio, lo que por 2.98 +supuesto se convierte en una fuente de todo tipo de problemas 2.99 +administrativos y de seguridad bastante molestos.) 2.100 + 2.101 +Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda 2.102 +escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es 2.103 +seguro incluso sobre sistemas de archivos notoriamente hostiles al 2.104 +bloqueo, como NFS). Si un repositorio está bloqueado, los escritores 2.105 +esperarán un buen rato para revisar si el repositorio ya ha sido 2.106 +desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo, 2.107 +el proceso que intenta escribir fallará por tiempo de espera máximo. 2.108 +Esto significa que sus guiones automáticos diarios no se quedarán 2.109 +esperando para siempre, apilándose si el sistema se cayó sin que nadie 2.110 +se diera cuenta, por ejemplo. (Sí, el tiempo de espera máximo es 2.111 +configurable, de cero a infinito). 2.112 + 2.113 + 2.114 +\subsubsection{Acceso seguro al estado de directorio} 2.115 + 2.116 +Al igual que con los datos de revisión, Mercurial no requiere un 2.117 +bloqueo para leer el fichero de estado de directorio; sí se usa un 2.118 +bloqueo para escribir a él. Para evitar la posibilidad de leer una 2.119 +copia parcialmente escrita del fichero de estado de directorio, 2.120 +Mercurial escribe a un fichero con un nombre único en el mismo 2.121 +directorio del fichero de estado de directorio, y luego renombra 2.122 +atómicamente este fichero temporal a \filename{dirstate}\ndt{Estado de 2.123 +directorio.}. Así se garantiza que el fichero llamado 2.124 +\filename{dirstate} esté completo, y no parcialmente escrito. 2.125 + 2.126 +\subsection{Evitar movimientos de brazo} 2.127 + 2.128 +Un aspecto crítico para el desempeño de Mercurial es evitar los 2.129 +movimientos del brazo de lectura del disco duro, ya que cualquier 2.130 +movimiento de brazo es mucho más costoso que incluso una operación de 2.131 +lectura relativamente grande. 2.132 + 2.133 +Es por esto que, por ejemplo, el estado de directorio es almacenado 2.134 +como un solo fichero. Si hubiera un estado de directorio por cada 2.135 +directorio que Mercurial monitorea, el disco haría un movimiento de 2.136 +brazo por cada directorio. En cambio, Mercurial lee el estado de 2.137 +directorio completo en un solo paso. 2.138 + 2.139 +Mercurial también usa un esquema de ``copiar al escribir'' cuando 2.140 +clona un repositorio en un mismo medio de almacenamiento local. En vez 2.141 +de copiar cada fichero de revlog del repositorio viejo al nuevo, se 2.142 +crea un ``enlace duro'', que es una manera sucinta de decir 2.143 +``estos dos nombres apuntan al mismo fichero''. Cuando Mercurial está 2.144 +a punto de escribir a uno de los ficheros de revlog, revisa si la 2.145 +cantidad de nombres apuntando al fichero es de más de uno. Si lo es, 2.146 +más de un repositorio está usando el fichero, así que Mercurial hace 2.147 +una nueva copia del fichero, privada para este repositorio. 2.148 + 2.149 +Algunos desarrolladores de control de revisiones han indicado que la 2.150 +idea de hacer una copia privada completa de un fichero no es eficiente 2.151 +desde el punto de vista de almacenamiento. Aunque esto es cierto, el 2.152 +almacenamiento es barato, y este método brinda el máximo rendimiento 2.153 +al tiempo que delega la mayor parte del trabajo de manejo de ficheros 2.154 +al sistema operativo. Un esquema alternativo seguramente reduciría el 2.155 +desempeño y aumentaría la complejidad del software, cada uno de los 2.156 +cuales es mucho más importante para la ``sensación'' que se tiene del 2.157 +software en el trabajo día a día. 2.158 + 2.159 +\subsection{Otros contenidos del estado de directorio} 2.160 + 2.161 +Debido a que Mercurial no lo fuerza a indicar si usted está 2.162 +modificando un fichero, se usa el estado de directorio para almacenar 2.163 +información extra para poder determinar efecientemente si usted ha 2.164 +modificado un fichero. Por cada fichero en el directorio de trabajo, 2.165 +se almacena el momento en que Mercurial modificó por última vez el 2.166 +fichero, y el tamaño del fichero en ese momento. 2.167 + 2.168 +cuando usted añade (\hgcmd{add}), remueve (\hgcmd{remove}), renombra 2.169 +(\hgcmd{rename}) o copia (\hgcmd{copy}) ficheros, Mercurial actualiza 2.170 +el estado de directorio para saber qué hacer con dichos ficheros 2.171 +cuando usted haga la consignación. 2.172 + 2.173 +Cuando Mercurial está revisando el estado de los ficheros en el 2.174 +directorio de trabajo, revisa primero la fecha de modificación del 2.175 +fichero. Si no ha cambiado, el fichero no ha sido modificado. Si el 2.176 +tamaño del fichero ha cambiado, el fichero ha sido modificado. Sólo en 2.177 +el caso en que el tiempo de modificación ha cambiado, pero el tamaño 2.178 +no, es necesario leer el contenido del fichero para revisar si ha 2.179 +cambiado. Almacenar estos pocos datos reduce dramáticamente la 2.180 +cantidad de datos que Mercurial debe leer, lo que brinda una mejora en 2.181 +el rendimiento grande, comparado con otros sistemas de control de 2.182 +revisiones. 2.183 2.184 %%% Local Variables: 2.185 %%% mode: latex