changeset 525:e5739e8d708f

finished file "concepts.tex". Upgraded project status file
author Javier Rojas <jerojasro@devnull.li>
date Sun, 23 Nov 2008 13:22:45 -0500
parents 2b4022f9e3f8
children 4a1dc5e8e2ff
files es/Leame.1st es/concepts.tex
diffstat 2 files changed, 84 insertions(+), 72 deletions(-) [+]
line wrap: on
line diff
--- a/es/Leame.1st	Fri Nov 21 00:07:44 2008 -0500
+++ b/es/Leame.1st	Sun Nov 23 13:22:45 2008 -0500
@@ -101,7 +101,7 @@
 || tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
 || undo.tex        || Igor Támara   ||    100%    || 26/10/2008 ||  07/11/2008 ||
 || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
-|| concepts.tex    || Javier Rojas  ||     81%    || 03/11/2008 ||             ||
+|| concepts.tex    || Javier Rojas  ||    100%    || 03/11/2008 ||  23/11/2008 ||
 || intro.tex	   || Igor Támara   ||	  100%	  || 08/11/2008	||  09/11/2008 ||
 || collab.tex      || Igor Támara   ||     39%    || 10/11/2008 ||             ||
 
--- a/es/concepts.tex	Fri Nov 21 00:07:44 2008 -0500
+++ b/es/concepts.tex	Sun Nov 23 13:22:45 2008 -0500
@@ -549,88 +549,100 @@
 está escribiendo al mismo o no.
 
 La naturaleza carente de bloqueos de la lectura significa que si usted
-está compartiendo un repositorio
-The lockless nature of reading means that if you're sharing a
-repository on a multi-user system, you don't need to grant other local
-users permission to \emph{write} to your repository in order for them
-to be able to clone it or pull changes from it; they only need
-\emph{read} permission.  (This is \emph{not} a common feature among
-revision control systems, so don't take it for granted!  Most require
-readers to be able to lock a repository to access it safely, and this
-requires write permission on at least one directory, which of course
-makes for all kinds of nasty and annoying security and administrative
-problems.)
+está compartiendo un repositorio en un sistema multiusuario, no
+necesita dar a los usuarios locales permisos de \emph{escritura} a su
+repositorio para que ellos puedan clonarlo o jalar cambios; sólo
+necesitan permisos de \emph{lectura}. (Esta \emph{no} es una
+%TODO signo de admiración de apertura
+característica común entre los sistemas de control de revisiones, así
+que no la dé por hecha! Muchos de ellos requieren que los lectores
+sean capaces de bloquear el repositorio antes de poder leerlo, y esto
+requiere acceso de escritura en al menos un directorio, lo que por
+supuesto se convierte en una fuente de todo tipo de problemas
+administrativos y de seguridad bastante molestos.)
 
-Mercurial uses locks to ensure that only one process can write to a
-repository at a time (the locking mechanism is safe even over
-filesystems that are notoriously hostile to locking, such as NFS).  If
-a repository is locked, a writer will wait for a while to retry if the
-repository becomes unlocked, but if the repository remains locked for
-too long, the process attempting to write will time out after a while.
-This means that your daily automated scripts won't get stuck forever
-and pile up if a system crashes unnoticed, for example.  (Yes, the
-timeout is configurable, from zero to infinity.)
+Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
+escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
+seguro incluso sobre sistemas de archivos notoriamente hostiles al
+bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
+esperarán un buen rato para revisar si el repositorio ya ha sido
+desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,
+el proceso que intenta escribir fallará por tiempo de espera máximo.
+Esto significa que sus guiones automáticos diarios no se quedarán
+esperando para siempre, apilándose si el sistema se cayó sin que nadie
+se diera cuenta, por ejemplo. (Sí, el tiempo de espera máximo es
+configurable, de cero a infinito).
 
-\subsubsection{Safe dirstate access}
+
+\subsubsection{Acceso seguro al estado de directorio}
 
-As with revision data, Mercurial doesn't take a lock to read the
-dirstate file; it does acquire a lock to write it.  To avoid the
-possibility of reading a partially written copy of the dirstate file,
-Mercurial writes to a file with a unique name in the same directory as
-the dirstate file, then renames the temporary file atomically to
-\filename{dirstate}.  The file named \filename{dirstate} is thus
-guaranteed to be complete, not partially written.
+Al igual que con los datos de revisión, Mercurial no requiere un
+bloqueo para leer el fichero de estado de directorio; sí se usa un
+bloqueo para escribir a él. Para evitar la posibilidad de leer una
+copia parcialmente escrita del fichero de estado de directorio,
+Mercurial escribe a un fichero con un nombre único en el mismo
+directorio del fichero de estado de directorio, y luego renombra
+atómicamente este fichero temporal a \filename{dirstate}\ndt{Estado de
+directorio.}. Así se garantiza que el fichero llamado
+\filename{dirstate} esté completo, y no parcialmente escrito.
 
-\subsection{Avoiding seeks}
+\subsection{Evitar movimientos de brazo}
 
-Critical to Mercurial's performance is the avoidance of seeks of the
-disk head, since any seek is far more expensive than even a
-comparatively large read operation.
+Un aspecto crítico para el desempeño de Mercurial es evitar los
+movimientos del brazo de lectura del disco duro, ya que cualquier
+movimiento de brazo es mucho más costoso que incluso una operación de
+lectura relativamente grande.
 
-This is why, for example, the dirstate is stored in a single file.  If
-there were a dirstate file per directory that Mercurial tracked, the
-disk would seek once per directory.  Instead, Mercurial reads the
-entire single dirstate file in one step.
+Es por esto que, por ejemplo, el estado de directorio es almacenado
+como un solo fichero. Si hubiera un estado de directorio por cada
+directorio que Mercurial monitorea, el disco haría un movimiento de
+brazo por cada directorio. En cambio, Mercurial lee el estado de
+directorio completo en un solo paso.
 
-Mercurial also uses a ``copy on write'' scheme when cloning a
-repository on local storage.  Instead of copying every revlog file
-from the old repository into the new repository, it makes a ``hard
-link'', which is a shorthand way to say ``these two names point to the
-same file''.  When Mercurial is about to write to one of a revlog's
-files, it checks to see if the number of names pointing at the file is
-greater than one.  If it is, more than one repository is using the
-file, so Mercurial makes a new copy of the file that is private to
-this repository.
+Mercurial también usa un esquema de ``copiar al escribir'' cuando
+clona un repositorio en un mismo medio de almacenamiento local. En vez
+de copiar cada fichero de revlog del repositorio viejo al nuevo, se
+crea un ``enlace duro'', que es una manera sucinta de decir
+``estos dos nombres apuntan al mismo fichero''. Cuando Mercurial está
+a punto de escribir a uno de los ficheros de revlog, revisa si la
+cantidad de nombres apuntando al fichero es de más de uno. Si lo es,
+más de un repositorio está usando el fichero, así que Mercurial hace
+una nueva copia del fichero, privada para este repositorio.
 
-A few revision control developers have pointed out that this idea of
-making a complete private copy of a file is not very efficient in its
-use of storage.  While this is true, storage is cheap, and this method
-gives the highest performance while deferring most book-keeping to the
-operating system.  An alternative scheme would most likely reduce
-performance and increase the complexity of the software, each of which
-is much more important to the ``feel'' of day-to-day use.
+Algunos desarrolladores de control de revisiones han indicado que la
+idea de hacer una copia privada completa de un fichero no es eficiente
+desde el punto de vista de almacenamiento. Aunque esto es cierto, el
+almacenamiento es barato, y este método brinda el máximo rendimiento
+al tiempo que delega la mayor parte del trabajo de manejo de ficheros
+al sistema operativo. Un esquema alternativo seguramente reduciría el
+desempeño y aumentaría la complejidad del software, cada uno de los
+cuales es mucho más importante para la ``sensación'' que se tiene del
+software en el trabajo día a día.
 
-\subsection{Other contents of the dirstate}
+\subsection{Otros contenidos del estado de directorio}
 
-Because Mercurial doesn't force you to tell it when you're modifying a
-file, it uses the dirstate to store some extra information so it can
-determine efficiently whether you have modified a file.  For each file
-in the working directory, it stores the time that it last modified the
-file itself, and the size of the file at that time.  
-
-When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
-\hgcmd{copy} files, Mercurial updates the dirstate so that it knows
-what to do with those files when you commit.
+Debido a que Mercurial no lo fuerza a indicar si usted está
+modificando un fichero, se usa el estado de directorio para almacenar
+información extra para poder determinar efecientemente si usted ha
+modificado un fichero. Por cada fichero en el directorio de trabajo,
+se almacena el momento en que Mercurial modificó por última vez el
+fichero, y el tamaño del fichero en ese momento.
 
-When Mercurial is checking the states of files in the working
-directory, it first checks a file's modification time.  If that has
-not changed, the file must not have been modified.  If the file's size
-has changed, the file must have been modified.  If the modification
-time has changed, but the size has not, only then does Mercurial need
-to read the actual contents of the file to see if they've changed.
-Storing these few extra pieces of information dramatically reduces the
-amount of data that Mercurial needs to read, which yields large
-performance improvements compared to other revision control systems.
+cuando usted añade (\hgcmd{add}), remueve (\hgcmd{remove}), renombra
+(\hgcmd{rename}) o copia (\hgcmd{copy}) ficheros, Mercurial actualiza
+el estado de directorio para saber qué hacer con dichos ficheros
+cuando usted haga la consignación.
+
+Cuando Mercurial está revisando el estado de los ficheros en el
+directorio de trabajo, revisa primero la fecha de modificación del
+fichero. Si no ha cambiado, el fichero no ha sido modificado. Si el
+tamaño del fichero ha cambiado, el fichero ha sido modificado. Sólo en
+el caso en que el tiempo de modificación ha cambiado, pero el tamaño
+no, es necesario leer el contenido del fichero para revisar si ha
+cambiado. Almacenar estos pocos datos reduce dramáticamente la
+cantidad de datos que Mercurial debe leer, lo que brinda una mejora en
+el rendimiento grande, comparado con otros sistemas de control de
+revisiones.
 
 %%% Local Variables: 
 %%% mode: latex