hgbook
changeset 464:951bf84ca8e2
translated up to the section "testing and troubleshooting"
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Tue Dec 23 18:57:35 2008 -0500 (2008-12-23) |
parents | 0ab26d50eba3 |
children | aa6036a9688e |
files | es/Leame.1st es/hook.tex |
line diff
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}