hgbook
changeset 441:4e0684e824e1
translated up to the tutorial on using hooks
author | jerojasro@abu.no-ip.org |
---|---|
date | Mon Dec 08 11:16:54 2008 -0500 (2008-12-08) |
parents | aeda195f54a6 |
children | 606295a87ff2 |
files | es/Leame.1st es/hook.tex |
line diff
1.1 --- a/es/Leame.1st Sat Dec 06 01:01:39 2008 -0500 1.2 +++ b/es/Leame.1st Mon Dec 08 11:16:54 2008 -0500 1.3 @@ -105,7 +105,7 @@ 1.4 || intro.tex || Igor Támara || 100% || 08/11/2008 || 09/11/2008 || 1.5 || collab.tex || Igor Támara || 100% || 10/11/2008 || 06/12/2008 || 1.6 || filenames.tex || Javier Rojas || 72% || 27/11/2008 || || 1.7 -|| hook.tex || Javier Rojas || 8% || 01/12/2008 || || 1.8 +|| hook.tex || Javier Rojas || 17% || 01/12/2008 || || 1.9 || mq.tex || Igor Támara || 0% || 06/12/2008 || || 1.10 || hgext.tex || Igor Támara || 0% || || || 1.11
2.1 --- a/es/hook.tex Sat Dec 06 01:01:39 2008 -0500 2.2 +++ b/es/hook.tex Mon Dec 08 11:16:54 2008 -0500 2.3 @@ -126,124 +126,136 @@ 2.4 global para definir los ganchos que verán todos los usuarios. Sin 2.5 embargo, este enfoque tiene sus límites; vea más abajo. 2.6 2.7 -\subsection{Hooks can be overridden} 2.8 - 2.9 -Mercurial allows you to override a hook definition by redefining the 2.10 -hook. You can disable it by setting its value to the empty string, or 2.11 -change its behaviour as you wish. 2.12 - 2.13 -If you deploy a system-~or site-wide \hgrc\ file that defines some 2.14 -hooks, you should thus understand that your users can disable or 2.15 -override those hooks. 2.16 - 2.17 -\subsection{Ensuring that critical hooks are run} 2.18 - 2.19 -Sometimes you may want to enforce a policy that you do not want others 2.20 -to be able to work around. For example, you may have a requirement 2.21 -that every changeset must pass a rigorous set of tests. Defining this 2.22 -requirement via a hook in a site-wide \hgrc\ won't work for remote 2.23 -users on laptops, and of course local users can subvert it at will by 2.24 -overriding the hook. 2.25 - 2.26 -Instead, you can set up your policies for use of Mercurial so that 2.27 -people are expected to propagate changes through a well-known 2.28 -``canonical'' server that you have locked down and configured 2.29 -appropriately. 2.30 - 2.31 -One way to do this is via a combination of social engineering and 2.32 -technology. Set up a restricted-access account; users can push 2.33 -changes over the network to repositories managed by this account, but 2.34 -they cannot log into the account and run normal shell commands. In 2.35 -this scenario, a user can commit a changeset that contains any old 2.36 -garbage they want. 2.37 - 2.38 -When someone pushes a changeset to the server that everyone pulls 2.39 -from, the server will test the changeset before it accepts it as 2.40 -permanent, and reject it if it fails to pass the test suite. If 2.41 -people only pull changes from this filtering server, it will serve to 2.42 -ensure that all changes that people pull have been automatically 2.43 -vetted. 2.44 - 2.45 -\section{Care with \texttt{pretxn} hooks in a shared-access repository} 2.46 - 2.47 -If you want to use hooks to do some automated work in a repository 2.48 -that a number of people have shared access to, you need to be careful 2.49 -in how you do this. 2.50 - 2.51 -Mercurial only locks a repository when it is writing to the 2.52 -repository, and only the parts of Mercurial that write to the 2.53 -repository pay attention to locks. Write locks are necessary to 2.54 -prevent multiple simultaneous writers from scribbling on each other's 2.55 -work, corrupting the repository. 2.56 - 2.57 -Because Mercurial is careful with the order in which it reads and 2.58 -writes data, it does not need to acquire a lock when it wants to read 2.59 -data from the repository. The parts of Mercurial that read from the 2.60 -repository never pay attention to locks. This lockless reading scheme 2.61 -greatly increases performance and concurrency. 2.62 - 2.63 -With great performance comes a trade-off, though, one which has the 2.64 -potential to cause you trouble unless you're aware of it. To describe 2.65 -this requires a little detail about how Mercurial adds changesets to a 2.66 -repository and reads those changes. 2.67 - 2.68 -When Mercurial \emph{writes} metadata, it writes it straight into the 2.69 -destination file. It writes file data first, then manifest data 2.70 -(which contains pointers to the new file data), then changelog data 2.71 -(which contains pointers to the new manifest data). Before the first 2.72 -write to each file, it stores a record of where the end of the file 2.73 -was in its transaction log. If the transaction must be rolled back, 2.74 -Mercurial simply truncates each file back to the size it was before the 2.75 -transaction began. 2.76 - 2.77 -When Mercurial \emph{reads} metadata, it reads the changelog first, 2.78 -then everything else. Since a reader will only access parts of the 2.79 -manifest or file metadata that it can see in the changelog, it can 2.80 -never see partially written data. 2.81 - 2.82 -Some controlling hooks (\hook{pretxncommit} and 2.83 -\hook{pretxnchangegroup}) run when a transaction is almost complete. 2.84 -All of the metadata has been written, but Mercurial can still roll the 2.85 -transaction back and cause the newly-written data to disappear. 2.86 - 2.87 -If one of these hooks runs for long, it opens a window of time during 2.88 -which a reader can see the metadata for changesets that are not yet 2.89 -permanent, and should not be thought of as ``really there''. The 2.90 -longer the hook runs, the longer that window is open. 2.91 - 2.92 -\subsection{The problem illustrated} 2.93 - 2.94 -In principle, a good use for the \hook{pretxnchangegroup} hook would 2.95 -be to automatically build and test incoming changes before they are 2.96 -accepted into a central repository. This could let you guarantee that 2.97 -nobody can push changes to this repository that ``break the build''. 2.98 -But if a client can pull changes while they're being tested, the 2.99 -usefulness of the test is zero; an unsuspecting someone can pull 2.100 -untested changes, potentially breaking their build. 2.101 - 2.102 -The safest technological answer to this challenge is to set up such a 2.103 -``gatekeeper'' repository as \emph{unidirectional}. Let it take 2.104 -changes pushed in from the outside, but do not allow anyone to pull 2.105 -changes from it (use the \hook{preoutgoing} hook to lock it down). 2.106 -Configure a \hook{changegroup} hook so that if a build or test 2.107 -succeeds, the hook will push the new changes out to another repository 2.108 -that people \emph{can} pull from. 2.109 - 2.110 -In practice, putting a centralised bottleneck like this in place is 2.111 -not often a good idea, and transaction visibility has nothing to do 2.112 -with the problem. As the size of a project---and the time it takes to 2.113 -build and test---grows, you rapidly run into a wall with this ``try 2.114 -before you buy'' approach, where you have more changesets to test than 2.115 -time in which to deal with them. The inevitable result is frustration 2.116 -on the part of all involved. 2.117 - 2.118 -An approach that scales better is to get people to build and test 2.119 -before they push, then run automated builds and tests centrally 2.120 -\emph{after} a push, to be sure all is well. The advantage of this 2.121 -approach is that it does not impose a limit on the rate at which the 2.122 -repository can accept changes. 2.123 - 2.124 -\section{A short tutorial on using hooks} 2.125 +\subsection{Es posible hacer caso omiso de los ganchos} 2.126 + 2.127 +Mercurial le permite hacer caso omiso de la deficinión de un gancho, 2.128 +a través de la redefinición del mismo. Usted puede deshabilitar el 2.129 +gancho fijando su valor como una cadena vacía, o cambiar su 2.130 +comportamiento como desee. 2.131 + 2.132 +Si usted instala un fichero \hgrc\ a nivel de sistema o sitio completo 2.133 +que define algunos ganchos, debe entender que sus usuarios pueden 2.134 +deshabilitar o hacer caso omiso de los mismos. 2.135 + 2.136 +\subsection{Asegurarse de que ganchos críticos sean ejecutados} 2.137 + 2.138 +Algunas veces usted puede querer hacer respetar una política, y no 2.139 +permitir que los demás sean capaces de evitarla. Por ejemplo, usted 2.140 +puede tener como requerimiento que cada conjunto de cambios debe pasar 2.141 +un riguroso conjunto de pruebas. Definir este requerimientos a través 2.142 +de un gancho en un fichero \hgrc\ global no servirá con usuarios 2.143 +remotos en computadoras portátiles, y por supuesto que los usuarios 2.144 +locales pueden evitar esto a voluntad haciendo caso omiso del gancho. 2.145 + 2.146 +En vez de eso, usted puede definir las políticas para usar Mercurial 2.147 +de tal forma que se espere que los usuarios propaguen los cambios a 2.148 +través de un servidor ``canónico'' bien conocido que usted ha 2.149 +asegurado y configurado apropiadamente. 2.150 + 2.151 +Una manera de hacer esto es a través de una combinación de ingeniería 2.152 +socual y tecnología. Cree una cuenta de acceso restringido; los 2.153 +usuarios pueden empujar cambios a través de la red a los repositorios 2.154 +administrados por esta cuenta, pero no podrán ingresar a dicha cuenta 2.155 +para ejecutar órdenes en el intérprete de comandos. En este escenario, 2.156 +un usuario puede enviar un conjunto de cambios que contenga la 2.157 +porquería que él desee. 2.158 + 2.159 +Cuando alguien empuja un conjunto de cambios al servidor del que todos 2.160 +jalan, el servidor probará el conjunto de cambios antes de aceptarlo 2.161 +como permanente, y lo rechazará si no logra pasar el conjunto de 2.162 +pruebas. Si la gente sólo jala cambios desde este servidor de filtro, 2.163 +servirá para asegurarse de que todos los cambios que la gente jala han 2.164 +sido examinados automáticamente 2.165 + 2.166 +\section{Precauciones con ganchos \texttt{pretxn} en un repositorio de 2.167 +acceso compartido} 2.168 + 2.169 +Si usted desea usar ganchos para llevar a cabo automáticamente algún 2.170 +trabajo en un repositorio al que varias personas tienen acceso 2.171 +compartido, debe tener cuidado con la forma de hacerlo. 2.172 + 2.173 +Mercurial sólo bloquea un repositorio cuando está escribiendo al 2.174 +mismo, y sólo las partes de Mercurial que escriben al repositorio le 2.175 +prestan atención a los bloqueos. Los bloqueos de escritura son 2.176 +necesarios para evitar que múltiples escritores simultáneos 2.177 +interfieran entre sí, corrompiendo el repositorio. 2.178 + 2.179 +Ya que Mercurial tiene cuidado con el orden en que lee y escribe 2.180 +datos, no necesita adquirir un bloqueo cuando desea leer datos del 2.181 +repositorio. Las partes de Mercurial que leen del repositorio nunca le 2.182 +prestan atención a los bloqueos. Este esquema de lectura libre de 2.183 +bloqueos incremententa en gran medida el desempeño y la concurrencia. 2.184 + 2.185 +Sin embargo, para tener un gran desempeño es necesario hacer 2.186 +sacrificios, uno de los cuales tiene el potencial de causarle 2.187 +problemas a menos de que usted esté consciente de él. Describirlo 2.188 +requiere algo de detalle respecto a cómo Mercurial añade conjuntos de 2.189 +cambios al repositorio y cómo lee esos cambios de vuelta. 2.190 + 2.191 +Cuando Mercurial \emph{escribe} metadatos, los escribe directamente en 2.192 +el fichero de destino. Primero escribe los datos del fichero, luego 2.193 +los datos del manifiesto (que contienen punteros a los nuevos datos 2.194 +del fichero), luego datos de la bitácora de cambios (que contienen 2.195 +punteros a los nuevos datos del manifiesto). Antes de la primera 2.196 +escritura a cada fichero, se guarda un registro de dónde estaba el 2.197 +final de fichero en su registro de transacciones. Si la transacción 2.198 +debe ser deshecha, Mercurial simplemente trunca cada fichero de vuelta 2.199 +al tamaño que tenía antes de que empezara la transacción. 2.200 + 2.201 +Cuando Mercurial \emph{lee} metadatos, lee la bitácora de cambios 2.202 +primero, y luego todo lo demás. Como un lector sólo accederá a las 2.203 +partes del manifiesto o de los metadatos de fichero que él puede ver 2.204 +en la bitácora de cambios, nunca puede ver datos parcialmente 2.205 +escritos. 2.206 + 2.207 +Algunos ganchos de control (\hook{pretxncommit} y 2.208 +\hook{pretxnchangegroup}) se ejecutan cuando una transacción está casi 2.209 +completa. Todos los metadatos han sido escritos, pero Mercurial aún 2.210 +puede deshacer la transacción y hacer que los datos recién escritos 2.211 +desaparezcan. 2.212 + 2.213 +Si alguno de estos ganchos permanece en ejecución por mucho tiempo, 2.214 +abre una ventana de tiempo en la que un lector puede ver los metadatos 2.215 +de conjuntos de cambios que aún no son permanentes y que no debería 2.216 +considerarse que estén ``realmante ahí''. Entre más tiempo tome la 2.217 +ejecución del gancho, más tiempo estará abierta esta ventana. 2.218 + 2.219 +\subsection{Ilustración del problema} 2.220 + 2.221 +En principio, un buen uso del gancho \hook{pretxnchangegroup} sería 2.222 +ensamblar y probar automáticamente todos los cambios entrantes antes 2.223 +de que sean aceptados en un repositorio central. Esto le permitiría a 2.224 +usted garantizar que nadie pueda empujar cambios que ``rompan el 2.225 +ensamblaje''. Pero si un cliente puede jalar cambios mientras están 2.226 +siendo probados, la utilidad de esta prueba es nula; alguien confiado 2.227 +puede jalar cambios sin probar, lo que potencialmente podría romper su 2.228 +proceso de ensamblaje. 2.229 + 2.230 +La respuesta técnica más segura frente a este retos es montar dicho 2.231 +repositorio ``guardián'' como \emph{unidireccional}. Permita que 2.232 +reciba cambios desde el exterior, pero no permita que nadie jale 2.233 +cambios de él (use el gancho \hook{preoutgoing} para bloquear esto). 2.234 +Configure un gancho \hook{changegroup} para que si el ensamblaje o 2.235 +prueba tiene éxito, el gancho empuje los nuevos cambios a otro 2.236 +repositorio del que la gente \emph{pueda} jalar. 2.237 + 2.238 +En la práctica, montar un cuello de botella centralizado como éste a 2.239 +menudo no es una buena idea, y la visibilidad de las transacciones no 2.240 +tiene nada que ver con el problema. A medida que el tamaño de un 2.241 +proyecto---y el tiempo que toma ensamblarlo y probarlo---crece, usted 2.242 +se acerca rápidamente a un límite con este enfoque ``pruebe antes de 2.243 +comprar'', en el que tiene más conjuntos de cambios a probar que 2.244 +tiempo para ocuparse de ellos. El resultado inevitable es frustración 2.245 +para todos los que estén involucrados. 2.246 + 2.247 +Una aproximación que permite manejar mejor el crecimiento es hacer que 2.248 +la gente ensamble y pruebe antes de empujar, y ejecutar el ensamble y 2.249 +pruebas automáticas centralmente \emph{después} de empujar, para 2.250 +asegurarse de que todo esté bien. La ventaja de este enfoque es que no 2.251 +impone un límite a la rata en la que un repositorio puede aceptar 2.252 +cambios. 2.253 + 2.254 +\section{Tutorial corto de uso de ganchos} 2.255 \label{sec:hook:simple} 2.256 2.257 It is easy to write a Mercurial hook. Let's start with a hook that