1.1 --- a/es/concepts.tex	Fri Nov 21 00:07:44 2008 -0500
     1.2 +++ b/es/concepts.tex	Mon Jan 12 22:25:40 2009 -0500
     1.3 @@ -549,88 +549,100 @@
     1.4  está escribiendo al mismo o no.
     1.5  
     1.6  La naturaleza carente de bloqueos de la lectura significa que si usted
     1.7 -está compartiendo un repositorio
     1.8 -The lockless nature of reading means that if you're sharing a
     1.9 -repository on a multi-user system, you don't need to grant other local
    1.10 -users permission to \emph{write} to your repository in order for them
    1.11 -to be able to clone it or pull changes from it; they only need
    1.12 -\emph{read} permission.  (This is \emph{not} a common feature among
    1.13 -revision control systems, so don't take it for granted!  Most require
    1.14 -readers to be able to lock a repository to access it safely, and this
    1.15 -requires write permission on at least one directory, which of course
    1.16 -makes for all kinds of nasty and annoying security and administrative
    1.17 -problems.)
    1.18 -
    1.19 -Mercurial uses locks to ensure that only one process can write to a
    1.20 -repository at a time (the locking mechanism is safe even over
    1.21 -filesystems that are notoriously hostile to locking, such as NFS).  If
    1.22 -a repository is locked, a writer will wait for a while to retry if the
    1.23 -repository becomes unlocked, but if the repository remains locked for
    1.24 -too long, the process attempting to write will time out after a while.
    1.25 -This means that your daily automated scripts won't get stuck forever
    1.26 -and pile up if a system crashes unnoticed, for example.  (Yes, the
    1.27 -timeout is configurable, from zero to infinity.)
    1.28 -
    1.29 -\subsubsection{Safe dirstate access}
    1.30 -
    1.31 -As with revision data, Mercurial doesn't take a lock to read the
    1.32 -dirstate file; it does acquire a lock to write it.  To avoid the
    1.33 -possibility of reading a partially written copy of the dirstate file,
    1.34 -Mercurial writes to a file with a unique name in the same directory as
    1.35 -the dirstate file, then renames the temporary file atomically to
    1.36 -\filename{dirstate}.  The file named \filename{dirstate} is thus
    1.37 -guaranteed to be complete, not partially written.
    1.38 -
    1.39 -\subsection{Avoiding seeks}
    1.40 -
    1.41 -Critical to Mercurial's performance is the avoidance of seeks of the
    1.42 -disk head, since any seek is far more expensive than even a
    1.43 -comparatively large read operation.
    1.44 -
    1.45 -This is why, for example, the dirstate is stored in a single file.  If
    1.46 -there were a dirstate file per directory that Mercurial tracked, the
    1.47 -disk would seek once per directory.  Instead, Mercurial reads the
    1.48 -entire single dirstate file in one step.
    1.49 -
    1.50 -Mercurial also uses a ``copy on write'' scheme when cloning a
    1.51 -repository on local storage.  Instead of copying every revlog file
    1.52 -from the old repository into the new repository, it makes a ``hard
    1.53 -link'', which is a shorthand way to say ``these two names point to the
    1.54 -same file''.  When Mercurial is about to write to one of a revlog's
    1.55 -files, it checks to see if the number of names pointing at the file is
    1.56 -greater than one.  If it is, more than one repository is using the
    1.57 -file, so Mercurial makes a new copy of the file that is private to
    1.58 -this repository.
    1.59 -
    1.60 -A few revision control developers have pointed out that this idea of
    1.61 -making a complete private copy of a file is not very efficient in its
    1.62 -use of storage.  While this is true, storage is cheap, and this method
    1.63 -gives the highest performance while deferring most book-keeping to the
    1.64 -operating system.  An alternative scheme would most likely reduce
    1.65 -performance and increase the complexity of the software, each of which
    1.66 -is much more important to the ``feel'' of day-to-day use.
    1.67 -
    1.68 -\subsection{Other contents of the dirstate}
    1.69 -
    1.70 -Because Mercurial doesn't force you to tell it when you're modifying a
    1.71 -file, it uses the dirstate to store some extra information so it can
    1.72 -determine efficiently whether you have modified a file.  For each file
    1.73 -in the working directory, it stores the time that it last modified the
    1.74 -file itself, and the size of the file at that time.  
    1.75 -
    1.76 -When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
    1.77 -\hgcmd{copy} files, Mercurial updates the dirstate so that it knows
    1.78 -what to do with those files when you commit.
    1.79 -
    1.80 -When Mercurial is checking the states of files in the working
    1.81 -directory, it first checks a file's modification time.  If that has
    1.82 -not changed, the file must not have been modified.  If the file's size
    1.83 -has changed, the file must have been modified.  If the modification
    1.84 -time has changed, but the size has not, only then does Mercurial need
    1.85 -to read the actual contents of the file to see if they've changed.
    1.86 -Storing these few extra pieces of information dramatically reduces the
    1.87 -amount of data that Mercurial needs to read, which yields large
    1.88 -performance improvements compared to other revision control systems.
    1.89 +está compartiendo un repositorio en un sistema multiusuario, no
    1.90 +necesita dar a los usuarios locales permisos de \emph{escritura} a su
    1.91 +repositorio para que ellos puedan clonarlo o jalar cambios; sólo
    1.92 +necesitan permisos de \emph{lectura}. (Esta \emph{no} es una
    1.93 +%TODO signo de admiración de apertura
    1.94 +característica común entre los sistemas de control de revisiones, así
    1.95 +que no la dé por hecha! Muchos de ellos requieren que los lectores
    1.96 +sean capaces de bloquear el repositorio antes de poder leerlo, y esto
    1.97 +requiere acceso de escritura en al menos un directorio, lo que por
    1.98 +supuesto se convierte en una fuente de todo tipo de problemas
    1.99 +administrativos y de seguridad bastante molestos.)
   1.100 +
   1.101 +Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
   1.102 +escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
   1.103 +seguro incluso sobre sistemas de archivos notoriamente hostiles al
   1.104 +bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
   1.105 +esperarán un buen rato para revisar si el repositorio ya ha sido
   1.106 +desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,
   1.107 +el proceso que intenta escribir fallará por tiempo de espera máximo.
   1.108 +Esto significa que sus guiones automáticos diarios no se quedarán
   1.109 +esperando para siempre, apilándose si el sistema se cayó sin que nadie
   1.110 +se diera cuenta, por ejemplo. (Sí, el tiempo de espera máximo es
   1.111 +configurable, de cero a infinito).
   1.112 +
   1.113 +
   1.114 +\subsubsection{Acceso seguro al estado de directorio}
   1.115 +
   1.116 +Al igual que con los datos de revisión, Mercurial no requiere un
   1.117 +bloqueo para leer el fichero de estado de directorio; sí se usa un
   1.118 +bloqueo para escribir a él. Para evitar la posibilidad de leer una
   1.119 +copia parcialmente escrita del fichero de estado de directorio,
   1.120 +Mercurial escribe a un fichero con un nombre único en el mismo
   1.121 +directorio del fichero de estado de directorio, y luego renombra
   1.122 +atómicamente este fichero temporal a \filename{dirstate}\ndt{Estado de
   1.123 +directorio.}. Así se garantiza que el fichero llamado
   1.124 +\filename{dirstate} esté completo, y no parcialmente escrito.
   1.125 +
   1.126 +\subsection{Evitar movimientos de brazo}
   1.127 +
   1.128 +Un aspecto crítico para el desempeño de Mercurial es evitar los
   1.129 +movimientos del brazo de lectura del disco duro, ya que cualquier
   1.130 +movimiento de brazo es mucho más costoso que incluso una operación de
   1.131 +lectura relativamente grande.
   1.132 +
   1.133 +Es por esto que, por ejemplo, el estado de directorio es almacenado
   1.134 +como un solo fichero. Si hubiera un estado de directorio por cada
   1.135 +directorio que Mercurial monitorea, el disco haría un movimiento de
   1.136 +brazo por cada directorio. En cambio, Mercurial lee el estado de
   1.137 +directorio completo en un solo paso.
   1.138 +
   1.139 +Mercurial también usa un esquema de ``copiar al escribir'' cuando
   1.140 +clona un repositorio en un mismo medio de almacenamiento local. En vez
   1.141 +de copiar cada fichero de revlog del repositorio viejo al nuevo, se
   1.142 +crea un ``enlace duro'', que es una manera sucinta de decir
   1.143 +``estos dos nombres apuntan al mismo fichero''. Cuando Mercurial está
   1.144 +a punto de escribir a uno de los ficheros de revlog, revisa si la
   1.145 +cantidad de nombres apuntando al fichero es de más de uno. Si lo es,
   1.146 +más de un repositorio está usando el fichero, así que Mercurial hace
   1.147 +una nueva copia del fichero, privada para este repositorio.
   1.148 +
   1.149 +Algunos desarrolladores de control de revisiones han indicado que la
   1.150 +idea de hacer una copia privada completa de un fichero no es eficiente
   1.151 +desde el punto de vista de almacenamiento. Aunque esto es cierto, el
   1.152 +almacenamiento es barato, y este método brinda el máximo rendimiento
   1.153 +al tiempo que delega la mayor parte del trabajo de manejo de ficheros
   1.154 +al sistema operativo. Un esquema alternativo seguramente reduciría el
   1.155 +desempeño y aumentaría la complejidad del software, cada uno de los
   1.156 +cuales es mucho más importante para la ``sensación'' que se tiene del
   1.157 +software en el trabajo día a día.
   1.158 +
   1.159 +\subsection{Otros contenidos del estado de directorio}
   1.160 +
   1.161 +Debido a que Mercurial no lo fuerza a indicar si usted está
   1.162 +modificando un fichero, se usa el estado de directorio para almacenar
   1.163 +información extra para poder determinar efecientemente si usted ha
   1.164 +modificado un fichero. Por cada fichero en el directorio de trabajo,
   1.165 +se almacena el momento en que Mercurial modificó por última vez el
   1.166 +fichero, y el tamaño del fichero en ese momento.
   1.167 +
   1.168 +cuando usted añade (\hgcmd{add}), remueve (\hgcmd{remove}), renombra
   1.169 +(\hgcmd{rename}) o copia (\hgcmd{copy}) ficheros, Mercurial actualiza
   1.170 +el estado de directorio para saber qué hacer con dichos ficheros
   1.171 +cuando usted haga la consignación.
   1.172 +
   1.173 +Cuando Mercurial está revisando el estado de los ficheros en el
   1.174 +directorio de trabajo, revisa primero la fecha de modificación del
   1.175 +fichero. Si no ha cambiado, el fichero no ha sido modificado. Si el
   1.176 +tamaño del fichero ha cambiado, el fichero ha sido modificado. Sólo en
   1.177 +el caso en que el tiempo de modificación ha cambiado, pero el tamaño
   1.178 +no, es necesario leer el contenido del fichero para revisar si ha
   1.179 +cambiado. Almacenar estos pocos datos reduce dramáticamente la
   1.180 +cantidad de datos que Mercurial debe leer, lo que brinda una mejora en
   1.181 +el rendimiento grande, comparado con otros sistemas de control de
   1.182 +revisiones.
   1.183  
   1.184  %%% Local Variables: 
   1.185  %%% mode: latex