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