1.1 --- a/es/Leame.1st	Mon Dec 08 20:37:58 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Dec 08 20:42:11 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  ||     26%    || 01/12/2008 ||             ||
     1.9  || mq.tex          || Igor Támara   ||     41%    || 06/12/2008 ||             ||
    1.10  || hgext.tex       || Igor Támara   ||      0%    ||            ||             ||
    1.11  

     2.1 --- a/es/hook.tex	Mon Dec 08 20:37:58 2008 -0500
     2.2 +++ b/es/hook.tex	Mon Dec 08 20:42:11 2008 -0500
     2.3 @@ -126,202 +126,221 @@
     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
   2.258 -runs when you finish a \hgcmd{commit}, and simply prints the hash of
   2.259 -the changeset you just created.  The hook is called \hook{commit}.
   2.260 +Escribir un gancho para Mercurial es fácil. Empecemos con un gancho
   2.261 +que se ejecute cuando usted termine un \hgcmd{commit}, y simplemente
   2.262 +muestre el hash del conjunto de cambios que usted acaba de crear. El
   2.263 +gancho se llamará \hook{commit}.
   2.264  
   2.265  \begin{figure}[ht]
   2.266    \interaction{hook.simple.init}
   2.267 -  \caption{A simple hook that runs when a changeset is committed}
   2.268 +  \caption{Un gancho simple que se ejecuta al hacer la consignación de
   2.269 +  un conjunto de cambios}
   2.270    \label{ex:hook:init}
   2.271  \end{figure}
   2.272  
   2.273 -All hooks follow the pattern in example~\ref{ex:hook:init}.  You add
   2.274 -an entry to the \rcsection{hooks} section of your \hgrc.  On the left
   2.275 -is the name of the event to trigger on; on the right is the action to
   2.276 -take.  As you can see, you can run an arbitrary shell command in a
   2.277 -hook.  Mercurial passes extra information to the hook using
   2.278 -environment variables (look for \envar{HG\_NODE} in the example).
   2.279 -
   2.280 -\subsection{Performing multiple actions per event}
   2.281 -
   2.282 -Quite often, you will want to define more than one hook for a
   2.283 -particular kind of event, as shown in example~\ref{ex:hook:ext}.
   2.284 -Mercurial lets you do this by adding an \emph{extension} to the end of
   2.285 -a hook's name.  You extend a hook's name by giving the name of the
   2.286 -hook, followed by a full stop (the ``\texttt{.}'' character), followed
   2.287 -by some more text of your choosing.  For example, Mercurial will run
   2.288 -both \texttt{commit.foo} and \texttt{commit.bar} when the
   2.289 -\texttt{commit} event occurs.
   2.290 +Todos los ganchos siguen el patrón del ejemplo~\ref{ex:hook:init}.
   2.291 +Usted puede añadir una entrada a la sección \rcsection{hooks} de su
   2.292 +fichero \hgrc.  A la izquierda está el nombre del evento respecto al
   2.293 +cual dispararse; a la derecha está la acción a llevar a cabo. Como
   2.294 +puede ver, es posible ejecutar cualquier orden de la línea de comandos
   2.295 +en un gancho. Mercurial le pasa información extra al gancho usando
   2.296 +variables de entorno (busque \envar{HG\_NODE} en el ejemplo).
   2.297 +
   2.298 +\subsection{Llevar a cabo varias acciones por evento}
   2.299 +
   2.300 +A menudo, usted querrá definir más de un gancho para un tipo de evento
   2.301 +particular, como se muestra en el ejemplo~\ref{ex:hook:ext}. 
   2.302 +Mercurial le permite hacer esto añadiendo una \emph{extensión} al
   2.303 +final del nombre de un gancho. Usted extiende el nombre del gancho
   2.304 +%TODO Yuk, no me gusta ese "parada completa"
   2.305 +poniendo el nombre del gancho, seguido por una parada completa (el
   2.306 +caracter ``\texttt{.}''), seguido de algo más de texto de su elección.
   2.307 +Por ejemplo, Mercurial ejecutará tanto \texttt{commit.foo} como
   2.308 +\texttt{commit.bar} cuando ocurra el evento \texttt{commit}.
   2.309  
   2.310  \begin{figure}[ht]
   2.311    \interaction{hook.simple.ext}
   2.312 -  \caption{Defining a second \hook{commit} hook}
   2.313 +  \caption{Definición de un segundo gancho \hook{commit}}
   2.314    \label{ex:hook:ext}
   2.315  \end{figure}
   2.316  
   2.317 -To give a well-defined order of execution when there are multiple
   2.318 -hooks defined for an event, Mercurial sorts hooks by extension, and
   2.319 -executes the hook commands in this sorted order.  In the above
   2.320 -example, it will execute \texttt{commit.bar} before
   2.321 -\texttt{commit.foo}, and \texttt{commit} before both.
   2.322 -
   2.323 -It is a good idea to use a somewhat descriptive extension when you
   2.324 -define a new hook.  This will help you to remember what the hook was
   2.325 -for.  If the hook fails, you'll get an error message that contains the
   2.326 -hook name and extension, so using a descriptive extension could give
   2.327 -you an immediate hint as to why the hook failed (see
   2.328 -section~\ref{sec:hook:perm} for an example).
   2.329 -
   2.330 -\subsection{Controlling whether an activity can proceed}
   2.331 +Para dar un orden bien definido de ejecución cuando hay múltiples
   2.332 +ganchos definidos para un evento, Mercurial ordena los ganchos de
   2.333 +acuerdo a su extensión, y los ejecuta en dicho orden. En el ejemplo de
   2.334 +arribam \texttt{commit.bar} se ejecutará antes que
   2.335 +\texttt{commit.foo}, y \texttt{commit} se ejecutará antes de ambos.
   2.336 +
   2.337 +Es una buena idea usar una extensión descriptiva cuando usted define
   2.338 +un gancho. Esto le ayudará a recordar para qué se usa el gancho. Si el
   2.339 +gancho falla, usted recibirá un mensaje de error que contiene el
   2.340 +nombre y la extensión del gancho, así que usar una extensión
   2.341 +descriptiva le dará una pista inmediata de porqué el gancho falló (vea
   2.342 +un ejemplo en la sección~\ref{sec:hook:perm}).
   2.343 +
   2.344 +\subsection{Controlar cuándo puede llevarse a cabo una actividad}
   2.345  \label{sec:hook:perm}
   2.346  
   2.347 -In our earlier examples, we used the \hook{commit} hook, which is
   2.348 -run after a commit has completed.  This is one of several Mercurial
   2.349 -hooks that run after an activity finishes.  Such hooks have no way of
   2.350 -influencing the activity itself.
   2.351 -
   2.352 -Mercurial defines a number of events that occur before an activity
   2.353 -starts; or after it starts, but before it finishes.  Hooks that
   2.354 -trigger on these events have the added ability to choose whether the
   2.355 -activity can continue, or will abort.  
   2.356 -
   2.357 -The \hook{pretxncommit} hook runs after a commit has all but
   2.358 -completed.  In other words, the metadata representing the changeset
   2.359 -has been written out to disk, but the transaction has not yet been
   2.360 -allowed to complete.  The \hook{pretxncommit} hook has the ability to
   2.361 -decide whether the transaction can complete, or must be rolled back.
   2.362 -
   2.363 -If the \hook{pretxncommit} hook exits with a status code of zero, the
   2.364 -transaction is allowed to complete; the commit finishes; and the
   2.365 -\hook{commit} hook is run.  If the \hook{pretxncommit} hook exits with
   2.366 -a non-zero status code, the transaction is rolled back; the metadata
   2.367 -representing the changeset is erased; and the \hook{commit} hook is
   2.368 -not run.
   2.369 +En los ejemplos anteriores, usamos el gancho \hook{commit}, que es
   2.370 +ejecutado después de que se ha completado una consignación. Este es
   2.371 +uno de los varios ganchos que Mercurial ejecuta luego de que una
   2.372 +actividad termina. Tales ganchos no tienen forma de influenciar la
   2.373 +actividad como tal.
   2.374 +
   2.375 +Mercurial define un número de eventos que ocurren antes de que una
   2.376 +actividad empiece; o luego de que empiece, pero antes de que termine.
   2.377 +Los ganchos que se disparan con estos eventos tienen la capacidad
   2.378 +adicional de elegir si la actividad puede continuar, o si su ejecución
   2.379 +es abortada.
   2.380 +
   2.381 +El gancho \hook{pretxncommit} se ejecuta justo antes de que una
   2.382 +consignación se ejecute. En otras palabras, los metadatos que
   2.383 +representan el conjunto de cambios han sido escritos al disco, pero no
   2.384 +se ha terminado la transacción. El gancho \hook{pretxncommit} tiene la
   2.385 +capacidad de decidir si una transacción se completa, o debe
   2.386 +deshacerse.
   2.387 +
   2.388 +Si el gancho \hook{pretxncommit} termina con un código de salida de
   2.389 +cero, se permite que la transacción se complete; la consignación
   2.390 +termina; y el gancho \hook{commit} es ejecutado. Si el gancho
   2.391 +\hook{pretxncommit} termina con un código de salida diferente de cero,
   2.392 +la transacción es revertida; los metadatos representando el conjunto
   2.393 +de cambios son borrados; y el gancho \hook{commit} no es ejecutado.
   2.394  
   2.395  \begin{figure}[ht]
   2.396    \interaction{hook.simple.pretxncommit}
   2.397 -  \caption{Using the \hook{pretxncommit} hook to control commits}
   2.398 +  \caption{Uso del gancho \hook{pretxncommit} hook to control commits}
   2.399    \label{ex:hook:pretxncommit}
   2.400  \end{figure}
   2.401