1.1 --- a/es/Leame.1st	Tue Dec 23 17:45:08 2008 -0500
     1.2 +++ b/es/Leame.1st	Tue Dec 23 18:57:35 2008 -0500
     1.3 @@ -344,6 +344,7 @@
     1.4  
     1.5  lazy copy -> copia vaga
     1.6      Horrible traducción literal. ¿Sugerencias?
     1.7 +    copia perezosa
     1.8  
     1.9  location (repository) -> ubicación (del repositorio)
    1.10      Cuidado, no traducir como localización, que es la acción y

     2.1 --- a/es/hook.tex	Tue Dec 23 17:45:08 2008 -0500
     2.2 +++ b/es/hook.tex	Tue Dec 23 18:57:35 2008 -0500
     2.3 @@ -567,7 +567,7 @@
     2.4  reutilizar el mensaje de consignación guardado anteriormente, una vez
     2.5  usted haya corregido el problema.
     2.6  
     2.7 -Como anotación final, note que en la figura~\ref{ex:hook:ws.better} el
     2.8 +Como anotación final, note en la figura~\ref{ex:hook:ws.better} el
     2.9  %TODO on-site => in-situ ?
    2.10  uso de la característica de edición \emph{in-situ} de \command{perl}
    2.11  para eliminar los espacios en blanco finales en un fichero. Esto es
    2.12 @@ -580,83 +580,95 @@
    2.13      perl -pi -e 's,\textbackslash{}s+\$,,' nombre\_fichero
    2.14  \end{codesample2}
    2.15  
    2.16 -\section{Bundled hooks}
    2.17 -
    2.18 -Mercurial ships with several bundled hooks.  You can find them in the
    2.19 -\dirname{hgext} directory of a Mercurial source tree.  If you are
    2.20 -using a Mercurial binary package, the hooks will be located in the
    2.21 -\dirname{hgext} directory of wherever your package installer put
    2.22 +%TODO bundled
    2.23 +\section{Ganchos bundled}
    2.24 +
    2.25 +Mercurial se instala con varios ganchos bundled. Usted puede
    2.26 +encontrarlos en el directorio \dirname{hgext} del árbol de ficheros
    2.27 +fuente de Mercurial. Si usted está usando un paquete binario de
    2.28 +Mercurial, los ganchos estarán ubicados en el directorio
    2.29 +\dirname{hgext} en donde su instalador de paquetes haya puesto a
    2.30  Mercurial.
    2.31  
    2.32 -\subsection{\hgext{acl}---access control for parts of a repository}
    2.33 -
    2.34 -The \hgext{acl} extension lets you control which remote users are
    2.35 -allowed to push changesets to a networked server.  You can protect any
    2.36 -portion of a repository (including the entire repo), so that a
    2.37 -specific remote user can push changes that do not affect the protected
    2.38 -portion.
    2.39 -
    2.40 -This extension implements access control based on the identity of the
    2.41 -user performing a push, \emph{not} on who committed the changesets
    2.42 -they're pushing.  It makes sense to use this hook only if you have a
    2.43 -locked-down server environment that authenticates remote users, and
    2.44 -you want to be sure that only specific users are allowed to push
    2.45 -changes to that server.
    2.46 -
    2.47 -\subsubsection{Configuring the \hook{acl} hook}
    2.48 -
    2.49 -In order to manage incoming changesets, the \hgext{acl} hook must be
    2.50 -used as a \hook{pretxnchangegroup} hook.  This lets it see which files
    2.51 -are modified by each incoming changeset, and roll back a group of
    2.52 -changesets if they modify ``forbidden'' files.  Example:
    2.53 +\subsection{\hgext{acl}---control de acceso a partes de un repositorio}
    2.54 +
    2.55 +La extensión \hgext{acl} le permite controlar a qué usuarios remotos
    2.56 +les está permitido empujar conjuntos de cambios a un servidor en red.
    2.57 +Usted puede proteger cualquier porción de un repositorio (incluyendo
    2.58 +el repositorio completo), de tal manera que un usuario remoto
    2.59 +específico pueda empujar cambios que no afecten la porción protegida.
    2.60 +
    2.61 +Esta extensión implementa control de acceso basado en la identidad del
    2.62 +usuario que empuja los conjuntos de cambios, \emph{no} en la identidad
    2.63 +de quien hizo la consignación de los mismos. Usar este gancho tiene
    2.64 +sentido sólo si se tiene un servidor adecuadamente asegurado que
    2.65 +autentique a los usuarios remotos, y si usted desea segurarse de que
    2.66 +sólo se le permita a ciertos usuarios empujar cambios a dicho
    2.67 +servidor.
    2.68 +
    2.69 +\subsubsection{Configurar el gancho \hook{acl}}
    2.70 +
    2.71 +Para administrar los conjuntos de cambios entrantes, se debe usar el
    2.72 +gancho \hgext{acl} como un gancho de tipo \hook{pretxnchangegroup}.
    2.73 +Esto le permite ver qué ficheros son modificados por cada conjunto de
    2.74 +%TODO rollback => "deshacer el efecto"
    2.75 +cambios entrante, y deshacer el efecto de un grupo de conjuntos de
    2.76 +cambios si alguno de ellos modifica algún fichero ``prohibido''.
    2.77 +Ejemplo:
    2.78  \begin{codesample2}
    2.79    [hooks]
    2.80    pretxnchangegroup.acl = python:hgext.acl.hook
    2.81  \end{codesample2}
    2.82  
    2.83 -The \hgext{acl} extension is configured using three sections.  
    2.84 -
    2.85 -The \rcsection{acl} section has only one entry, \rcitem{acl}{sources},
    2.86 -which lists the sources of incoming changesets that the hook should
    2.87 -pay attention to.  You don't normally need to configure this section.
    2.88 -\begin{itemize}
    2.89 -\item[\rcitem{acl}{serve}] Control incoming changesets that are arriving
    2.90 -  from a remote repository over http or ssh.  This is the default
    2.91 -  value of \rcitem{acl}{sources}, and usually the only setting you'll
    2.92 -  need for this configuration item.
    2.93 -\item[\rcitem{acl}{pull}] Control incoming changesets that are
    2.94 -  arriving via a pull from a local repository.
    2.95 -\item[\rcitem{acl}{push}] Control incoming changesets that are
    2.96 -  arriving via a push from a local repository.
    2.97 -\item[\rcitem{acl}{bundle}] Control incoming changesets that are
    2.98 -  arriving from another repository via a bundle.
    2.99 -\end{itemize}
   2.100 -
   2.101 -The \rcsection{acl.allow} section controls the users that are allowed to
   2.102 -add changesets to the repository.  If this section is not present, all
   2.103 -users that are not explicitly denied are allowed.  If this section is
   2.104 -present, all users that are not explicitly allowed are denied (so an
   2.105 -empty section means that all users are denied).
   2.106 -
   2.107 -The \rcsection{acl.deny} section determines which users are denied
   2.108 -from adding changesets to the repository.  If this section is not
   2.109 -present or is empty, no users are denied.
   2.110 -
   2.111 -The syntaxes for the \rcsection{acl.allow} and \rcsection{acl.deny}
   2.112 -sections are identical.  On the left of each entry is a glob pattern
   2.113 -that matches files or directories, relative to the root of the
   2.114 -repository; on the right, a user name.
   2.115 -
   2.116 -In the following example, the user \texttt{docwriter} can only push
   2.117 -changes to the \dirname{docs} subtree of the repository, while
   2.118 -\texttt{intern} can push changes to any file or directory except
   2.119 -\dirname{source/sensitive}.
   2.120 +La extensión \hgext{acl} es configurada mediante tres secciones.
   2.121 +
   2.122 +La sección \rcsection{acl} sólo tiene una entrada,
   2.123 +\rcitem{acl}{sources}\footnote{Fuentes.}, que lista las fuentes de los
   2.124 +conjuntos de cambios entrantes a las que el gancho debe prestar
   2.125 +atención. Usualmente usted no necesita configurar esta sección.
   2.126 +\begin{itemize}
   2.127 +  \item[\rcitem{acl}{serve}] Controlar conjuntos de
   2.128 +    cambios entrantes que están llegando desde un repositorio a
   2.129 +    través de http o ssh. Este es el valor por defecto de
   2.130 +  \rcitem{acl}{sources}, y usualmente es el único valor de
   2.131 +  configuración que necesitará para este ítem.
   2.132 +\item[\rcitem{acl}{pull}] Controlar conjuntos de cambios entrantes que
   2.133 +  lleguen vía un pull (jalado) desde un repositorio local.
   2.134 +\item[\rcitem{acl}{push}] Controlar conjuntos de cambios entrantes que
   2.135 +  lleguen vía un push (empuje) desde un repositorio local.
   2.136 +\item[\rcitem{acl}{bundle}] Controlar conjuntos de cambios entrantes
   2.137 +    %TODO bundle
   2.138 +  que lleguen desde otro repositorio a través de un bundle.
   2.139 +\end{itemize}
   2.140 +
   2.141 +La sección \rcsection{acl.allow} controla los usuarios a los que les
   2.142 +está permitido añadir conjuntos de cambios al repositorio. Si esta
   2.143 +sección no está presente, se le permite acceso a todos los usuarios
   2.144 +excepto  a los que se les haya negado explícitamente el acceso. Si
   2.145 +esta sección no está presente, se niega el acceso a todos los usuarios
   2.146 +excepto a todos a los que se les haya permitido de manera explícita
   2.147 +(así que una sección vacía implica que se niega el acceso a todos los
   2.148 +usuarios).
   2.149 +
   2.150 +La sección \rcsection{acl.deny} determina a qué usuarios no se les
   2.151 +permite añadir conjuntos de cambios al repositorio. Si esta sección no
   2.152 +está presente o está vacía, no se niega el acceso a ningún usuario.
   2.153 +
   2.154 +La sintaxis para los ficheros \rcsection{acl.allow} y
   2.155 +\rcsection{acl.deny} es idéntica. A la izquierda de cada entrada se
   2.156 +encuentra un patrón glob que asocia ficheros o directorios, respecto a
   2.157 +la raíz del repositorio; a la derecha, un nombre usuario.
   2.158 +
   2.159 +En el siguiente ejemplo, el usuario \texttt{escritordoc} sólo puede
   2.160 +empujar cambios al directorio \dirname{docs} del repositorio, mientras
   2.161 +que \texttt{practicante} puede enviar cambios a cualquier fichero o
   2.162 +directorio excepto \dirname{fuentes/sensitivo}.
   2.163  \begin{codesample2}
   2.164    [acl.allow]
   2.165 -  docs/** = docwriter
   2.166 +  docs/** = escritordoc
   2.167  
   2.168    [acl.deny]
   2.169 -  source/sensitive/** = intern
   2.170 +  fuentes/sensitivo/** = practicante
   2.171  \end{codesample2}
   2.172  
   2.173  \subsubsection{Testing and troubleshooting}