1.1 --- a/es/Leame.1st	Sat Dec 06 01:01:39 2008 -0500
     1.2 +++ b/es/Leame.1st	Sun Dec 07 17:47:38 2008 -0500
     1.3 @@ -106,7 +106,7 @@
     1.4  || collab.tex      || Igor Támara   ||    100%    || 10/11/2008 ||  06/12/2008 ||
     1.5  || filenames.tex   || Javier Rojas  ||     72%    || 27/11/2008 ||             ||
     1.6  || hook.tex        || Javier Rojas  ||      8%    || 01/12/2008 ||             ||
     1.7 -|| mq.tex          || Igor Támara   ||      0%    || 06/12/2008 ||             ||
     1.8 +|| mq.tex          || Igor Támara   ||     41%    || 06/12/2008 ||             ||
     1.9  || hgext.tex       || Igor Támara   ||      0%    ||            ||             ||
    1.10  
    1.11  == Archivos en proceso de revisión ==
    1.12 @@ -161,16 +161,20 @@
    1.13   Patch: Parche
    1.14   Path: Ruta de archivo
    1.15   Pointer: apuntador
    1.16 + Pop: Sustraer, la contraparte push, será publicar
    1.17   Probe: Sondeo
    1.18   Pull: Jalar
    1.19 - Push: Publicar
    1.20 + Push: Publicar.  En el contexto de parches introducir.
    1.21 + Queue: Cola
    1.22   Release: Versión o liberación de versión
    1.23   Revlog: Bitácora de revisiones
    1.24   Roll back: NO se traduce Ver más abajo
    1.25   Snapshot: instantánea
    1.26 + Stack: pila
    1.27   Sprint: sprint
    1.28   Tip: punta
    1.29   Update: actualización
    1.30 + Upstream: principal, mantenedor principal. De acuerdo al contexto.
    1.31  
    1.32  abort -> cancelar
    1.33  

     2.1 --- a/es/mq.tex	Sat Dec 06 01:01:39 2008 -0500
     2.2 +++ b/es/mq.tex	Sun Dec 07 17:47:38 2008 -0500
     2.3 @@ -4,217 +4,234 @@
     2.4  \section{El problema de la administración de parches}
     2.5  \label{sec:mq:patch-mgmt}
     2.6  
     2.7 -Here is a common scenario: you need to install a software package from
     2.8 -source, but you find a bug that you must fix in the source before you
     2.9 -can start using the package.  You make your changes, forget about the
    2.10 -package for a while, and a few months later you need to upgrade to a
    2.11 -newer version of the package.  If the newer version of the package
    2.12 -still has the bug, you must extract your fix from the older source
    2.13 -tree and apply it against the newer version.  This is a tedious task,
    2.14 -and it's easy to make mistakes.
    2.15 -
    2.16 -This is a simple case of the ``patch management'' problem.  You have
    2.17 -an ``upstream'' source tree that you can't change; you need to make
    2.18 -some local changes on top of the upstream tree; and you'd like to be
    2.19 -able to keep those changes separate, so that you can apply them to
    2.20 -newer versions of the upstream source.
    2.21 -
    2.22 -The patch management problem arises in many situations.  Probably the
    2.23 -most visible is that a user of an open source software project will
    2.24 -contribute a bug fix or new feature to the project's maintainers in the
    2.25 -form of a patch.
    2.26 -
    2.27 -Distributors of operating systems that include open source software
    2.28 -often need to make changes to the packages they distribute so that
    2.29 -they will build properly in their environments.
    2.30 -
    2.31 -When you have few changes to maintain, it is easy to manage a single
    2.32 -patch using the standard \command{diff} and \command{patch} programs
    2.33 -(see section~\ref{sec:mq:patch} for a discussion of these tools).
    2.34 -Once the number of changes grows, it starts to make sense to maintain
    2.35 -patches as discrete ``chunks of work,'' so that for example a single
    2.36 -patch will contain only one bug fix (the patch might modify several
    2.37 -files, but it's doing ``only one thing''), and you may have a number
    2.38 -of such patches for different bugs you need fixed and local changes
    2.39 -you require.  In this situation, if you submit a bug fix patch to the
    2.40 -upstream maintainers of a package and they include your fix in a
    2.41 -subsequent release, you can simply drop that single patch when you're
    2.42 -updating to the newer release.
    2.43 -
    2.44 -Maintaining a single patch against an upstream tree is a little
    2.45 -tedious and error-prone, but not difficult.  However, the complexity
    2.46 -of the problem grows rapidly as the number of patches you have to
    2.47 -maintain increases.  With more than a tiny number of patches in hand,
    2.48 -understanding which ones you have applied and maintaining them moves
    2.49 -from messy to overwhelming.
    2.50 -
    2.51 -Fortunately, Mercurial includes a powerful extension, Mercurial Queues
    2.52 -(or simply ``MQ''), that massively simplifies the patch management
    2.53 -problem.
    2.54 -
    2.55 -\section{The prehistory of Mercurial Queues}
    2.56 +Un escenario frecuente: usted necesita instalar un paquete de software
    2.57 +desde las fuentes, pero encuentra un fallo que debe arreglar antes de
    2.58 +poder comenzar a usarlo.  Hace sus cambios, y se olvida del paquete
    2.59 +por un tiempo, unos meses después necesita actualizar a una nueva
    2.60 +versión del paquete.  Si la nueva versión del paquete todavía tiene el
    2.61 +fallo, debe extraer su arreglo del árbol de fuentes anteriores y
    2.62 +aplicarlo a la nueva versión.  Una tarea tediosa en la cual es fácil
    2.63 +equivocarse.
    2.64 +
    2.65 +Este es un caso simple del problema del ``manejo de parches''.  Usted
    2.66 +tiene un árbol de fuentes del ``mantenedor principal'' que no puede
    2.67 +cambiar: necesita hacer algunos cambios locales sobre el árbol
    2.68 +principal; y desearía poder mantener tales cambios separados, de forma
    2.69 +tal que pueda aplicarlos a versiones más nuevas del árbol principal.
    2.70 +
    2.71 +El problema de administración de parches surge en muchas situaciones.
    2.72 +Probablemente la más visible es cuando un usuario de un proyecto de
    2.73 +software de fuentes abiertas contribuye con un arreglo de un fallo o
    2.74 +una nueva característica a los mantenedores del proyecto en la forma
    2.75 +de un parche.
    2.76 +
    2.77 +Aquellos que distribuyen sistemas operativos que incluyen programas
    2.78 +abiertos usualmente requieren hacer cambios en los paquetes que
    2.79 +distribuyen de tal forma que se armen apropiadamente en sus ambientes.
    2.80 +
    2.81 +Cuando hay pocos cambios por mantener, es muy sencillo administrar un
    2.82 +solo parche con los programas estándar \command{diff} y
    2.83 +\command{patch}( ver la sección~\ref{sec:mq:patch} para ver cómo
    2.84 +emplear tales herramientas). Cuando la cantidad de cambios comienza a
    2.85 +crecer, tiene sentido mantener parches como ``porciones de trabajo''
    2.86 +individual, de forma que cada cambio contiene solamente un arreglo de
    2.87 +un fallo(el parche puede modificar varios archivos, pero está
    2.88 +``haciendo una sola cosa''), y puede tener cierta cantidad de tales
    2.89 +parches para diferentes fallos y cambios locales.  En esta situación,
    2.90 +si envía un parche que arregla un fallo a los mantenedores principales
    2.91 +de un paquete y ellos incluyen su arreglo en una publicación
    2.92 +posterior, puede deshacerse de tal parche cuando se actualice a la
    2.93 +nueva versión.
    2.94 +
    2.95 +Mantener un solo parche frente a un árbol principal es algo tedioso y
    2.96 +es fácil equivocarse, pero no es difícil.  Aunque, la complejidad del
    2.97 +problema crece rápidamente a medida que la cantidad de parches que
    2.98 +tiene que mantener crece.  Con más que una pequeña cantidad de
    2.99 +cambios, entender cuáles ha aplicado se convierte de algo desordenado
   2.100 +a algo avasallante.
   2.101 +
   2.102 +Afortunadamente Mercurial provee una extensión poderos: Colas de
   2.103 +Mercurial( o simplemente ``MQ''), que simplifica en gran medida el
   2.104 +problema de administración de parches.
   2.105 +
   2.106 +\section{La prehistoria de las Colas de Mercurial}
   2.107  \label{sec:mq:history}
   2.108  
   2.109 -During the late 1990s, several Linux kernel developers started to
   2.110 -maintain ``patch series'' that modified the behaviour of the Linux
   2.111 -kernel.  Some of these series were focused on stability, some on
   2.112 -feature coverage, and others were more speculative.
   2.113 -
   2.114 -The sizes of these patch series grew rapidly.  In 2002, Andrew Morton
   2.115 -published some shell scripts he had been using to automate the task of
   2.116 -managing his patch queues.  Andrew was successfully using these
   2.117 -scripts to manage hundreds (sometimes thousands) of patches on top of
   2.118 -the Linux kernel.
   2.119 -
   2.120 -\subsection{A patchwork quilt}
   2.121 +A finales de los 90s, muchos desarrolladores del núcleo de Linux
   2.122 +comenzaron a mantener ``series de parches'' que modificaron el
   2.123 +comportamiento del núcleo de Linux.  Algunos se enfocaban en
   2.124 +estabilidad, otros en aumentar las características, y otros un poco
   2.125 +más especulativos.
   2.126 +
   2.127 +Los tamaños de las series de parches crecieron rápidamente.  En el
   2.128 +2002, Andrew Morton publicó algunos guiones de línea de órdenes que
   2.129 +estuvo usando para automatizar la tarea de administrar su cola de
   2.130 +parches.  Andrew usó exitósamente tales guiones para administrar
   2.131 +centenas( aveces millares) de parches en el núcleo de Linux.
   2.132 +
   2.133 +\subsection{Trabajar parches con quilt}
   2.134  \label{sec:mq:quilt}
   2.135  
   2.136 -In early 2003, Andreas Gruenbacher and Martin Quinson borrowed the
   2.137 -approach of Andrew's scripts and published a tool called ``patchwork
   2.138 -quilt''~\cite{web:quilt}, or simply ``quilt''
   2.139 -(see~\cite{gruenbacher:2005} for a paper describing it).  Because
   2.140 -quilt substantially automated patch management, it rapidly gained a
   2.141 -large following among open source software developers.
   2.142 -
   2.143 -Quilt manages a \emph{stack of patches} on top of a directory tree.
   2.144 -To begin, you tell quilt to manage a directory tree, and tell it which
   2.145 -files you want to manage; it stores away the names and contents of
   2.146 -those files.  To fix a bug, you create a new patch (using a single
   2.147 -command), edit the files you need to fix, then ``refresh'' the patch.
   2.148 -
   2.149 -The refresh step causes quilt to scan the directory tree; it updates
   2.150 -the patch with all of the changes you have made.  You can create
   2.151 -another patch on top of the first, which will track the changes
   2.152 -required to modify the tree from ``tree with one patch applied'' to
   2.153 -``tree with two patches applied''.
   2.154 -
   2.155 -You can \emph{change} which patches are applied to the tree.  If you
   2.156 -``pop'' a patch, the changes made by that patch will vanish from the
   2.157 -directory tree.  Quilt remembers which patches you have popped,
   2.158 -though, so you can ``push'' a popped patch again, and the directory
   2.159 -tree will be restored to contain the modifications in the patch.  Most
   2.160 -importantly, you can run the ``refresh'' command at any time, and the
   2.161 -topmost applied patch will be updated.  This means that you can, at
   2.162 -any time, change both which patches are applied and what
   2.163 -modifications those patches make.
   2.164 -
   2.165 -Quilt knows nothing about revision control tools, so it works equally
   2.166 -well on top of an unpacked tarball or a Subversion working copy.
   2.167 -
   2.168 -\subsection{From patchwork quilt to Mercurial Queues}
   2.169 +A comienzos del 2003, Andreas Gruenbacher y Martin Quinson tomaron la
   2.170 +aproximación de los guiones de Andrew y publicaron una herramienta
   2.171 +llamada
   2.172 +``patchwork quilt''~\cite{web:quilt}, o simplemente ``quilt''
   2.173 +(ver~\cite{gruenbacher:2005} el paper que lo describe).  Dado que
   2.174 +quilt automatizaba sustancialmente la administración de parches, fue
   2.175 +adoptado en gran medida por desarrolladores de programas abiertos.
   2.176 +
   2.177 +Quilt maneja una \emph{pila de parches} sobre un árbol de directorios.
   2.178 +Para comenzar, usted le indica a quilt que administre un árbol de
   2.179 +directorios, le indica qué archivos manejar; Este almacena los nombres
   2.180 +y los contenidos de estos archivos.  Para arreglar un fallo, usted
   2.181 +crea un nuevo parche(con una sola orden), edita los archivos que está
   2.182 +arreglando y ``refresca'' el parche.
   2.183 +
   2.184 +El paso de refresco hace que quilt revise el árbol de directorios;
   2.185 +actualiza el parche con todos los cambios que usted haya hecho.  Puede
   2.186 +crear otro parche sobre el primero, que hará seguimiento de los
   2.187 +cambios requeridos para modificar el árbol desde ``el árbol con un
   2.188 +parch aplicado'' a un ``árbol con dos parches aplicados''.
   2.189 +
   2.190 +Usted puede \emph{elegir} qué cambios desea aplicar al árbol.  Si
   2.191 +``pop''\ndt{saca} un parche, los cambios hechos por tal parchve
   2.192 +desapareceŕan del árbol de directorios.  Quilt recuerda qué parches ha
   2.193 +sacado, para que pueda ``introducirlos''\ndt{push} posteriormente, así el
   2.194 +árbol de directorios se restaurará con las modificaciones que vienen
   2.195 +del parche.  Lo más importante es que puede ejecutar la orden
   2.196 +``refresh'' en cualquier momento, y el último parche será
   2.197 +actualizado.  Esto significa que puede, en cualquier momento, cambiar
   2.198 +qué parches serán aplicados y qué modificaciones hacen ellos.
   2.199 +
   2.200 +Quilt no tiene nada que ver con herramientas de control de versiones,
   2.201 +y puede trabajar bien sobre un conjunto de fuentes que viene de un
   2.202 +archivo comprimido y empaquetado o una copia de trabajo de Subversion.
   2.203 +
   2.204 +\subsection{Pasar de trabajo con parches con Quilt hacia Colas de Mercurial}
   2.205  \label{sec:mq:quilt-mq}
   2.206  
   2.207 -In mid-2005, Chris Mason took the features of quilt and wrote an
   2.208 -extension that he called Mercurial Queues, which added quilt-like
   2.209 -behaviour to Mercurial.
   2.210 -
   2.211 -The key difference between quilt and MQ is that quilt knows nothing
   2.212 -about revision control systems, while MQ is \emph{integrated} into
   2.213 -Mercurial.  Each patch that you push is represented as a Mercurial
   2.214 -changeset.  Pop a patch, and the changeset goes away.
   2.215 -
   2.216 -Because quilt does not care about revision control tools, it is still
   2.217 -a tremendously useful piece of software to know about for situations
   2.218 -where you cannot use Mercurial and MQ.
   2.219 -
   2.220 -\section{The huge advantage of MQ}
   2.221 -
   2.222 -I cannot overstate the value that MQ offers through the unification of
   2.223 -patches and revision control.
   2.224 -
   2.225 -A major reason that patches have persisted in the free software and
   2.226 -open source world---in spite of the availability of increasingly
   2.227 -capable revision control tools over the years---is the \emph{agility}
   2.228 -they offer.  
   2.229 -
   2.230 -Traditional revision control tools make a permanent, irreversible
   2.231 -record of everything that you do.  While this has great value, it's
   2.232 -also somewhat stifling.  If you want to perform a wild-eyed
   2.233 -experiment, you have to be careful in how you go about it, or you risk
   2.234 -leaving unneeded---or worse, misleading or destabilising---traces of
   2.235 -your missteps and errors in the permanent revision record.
   2.236 -
   2.237 -By contrast, MQ's marriage of distributed revision control with
   2.238 -patches makes it much easier to isolate your work.  Your patches live
   2.239 -on top of normal revision history, and you can make them disappear or
   2.240 -reappear at will.  If you don't like a patch, you can drop it.  If a
   2.241 -patch isn't quite as you want it to be, simply fix it---as many times
   2.242 -as you need to, until you have refined it into the form you desire.
   2.243 -
   2.244 -As an example, the integration of patches with revision control makes
   2.245 -understanding patches and debugging their effects---and their
   2.246 -interplay with the code they're based on---\emph{enormously} easier.
   2.247 -Since every applied patch has an associated changeset, you can use
   2.248 -\hgcmdargs{log}{\emph{filename}} to see which changesets and patches
   2.249 -affected a file.  You can use the \hgext{bisect} command to
   2.250 -binary-search through all changesets and applied patches to see where
   2.251 -a bug got introduced or fixed.  You can use the \hgcmd{annotate}
   2.252 -command to see which changeset or patch modified a particular line of
   2.253 -a source file.  And so on.
   2.254 -
   2.255 -\section{Understanding patches}
   2.256 +A mediados de 2005, Chris Mason tomó las características de quilt y
   2.257 +escribió una extensión que llamó Colas de Mercurial\ndt{Mercurial
   2.258 +Queues}, que proporcionó un comportamiento a Mercurial al estilo
   2.259 +quilt.
   2.260 +
   2.261 +La diferencia clave entre quilt y MQ es que quilt no sabe nada acerca
   2.262 +del sistema de control de revisiones, mientras que MQ está
   2.263 +\emph{integrado} con Mercurial.  Cada parche que usted introduce se
   2.264 +representa como un conjunto de cambios en Mercurial.  Si sustrae un
   2.265 +parche, el conjunto de cambios desaparece.\ndt{introduce originalmente es
   2.266 +push y pop es sustraer en este contexto, usaremos el original en inglés
   2.267 +cuando encontremos que facilita la comprensión}
   2.268 +
   2.269 +Dado que quilt no se preocupa por las herramientas de control de
   2.270 +revisiones, continúa siendo una porción de software tremendamente útil
   2.271 +para aquellas situaciones en las cuales no puede usar Mercurial y MQ.
   2.272 +
   2.273 +\section{La gran ventaja de MQ}
   2.274 +
   2.275 +No puedo sobreestimar el valor que MQ ofrece en la unificación de
   2.276 +parches y el control de revisiones.
   2.277 +
   2.278 +La principal razón por la cual los parches han persistido en el mundo
   2.279 +del software libre y de fuentes abiertas--a pesar de la creciente
   2.280 +disponibilidad de herramientas poderosas de control de revisiones-- es
   2.281 +la \emph{agilidad} que ofrecen.
   2.282 +
   2.283 +Las herramientas tradicionales de control de revisiones llevan un
   2.284 +registro permanente e irreversible de todo lo que usted hace.  A pesar
   2.285 +de que esto tiene gran valor, también es bastante sutil.  Si requiere
   2.286 +realizar un experimento ((((wild-eyed)))), debe ser cuidadoso en cómo
   2.287 +lo hace, o puede dejar trazas innecesarias--o peor aún,
   2.288 +desconcertantes o desestabilizantes--- de los pasos y errores en el
   2.289 +registro de revisiones de forma permanente.
   2.290 +
   2.291 +En contraste, con la cohesión de MQ con el control de revisiones
   2.292 +distribuidos y los parches, resulta más sencillo aislar su trabajo.
   2.293 +Sus parches viven encima de la historia de revisiones normales, y
   2.294 +puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
   2.295 +no le gusta un parche, puede desecharlo.  Si un parche no satisface
   2.296 +todo lo que usted desea, puede arreglarlo---tantas veces como lo
   2.297 +requiera, hasta que lo haya refinado lo suficiente hacia sus
   2.298 +expectativas.
   2.299 +
   2.300 +Por ejemplo, la integración de parches con el control de revisiones
   2.301 +hace que el entender los parches y revisar sus efectos---y sus
   2.302 +interacciones con el código en el cuál están enlazados--- sea
   2.303 +\emph{mucho} más sencillo.  Dado que todo parche que se aplique tiene
   2.304 +un conjunto de cambios asociado, puede usar
   2.305 +\hgcmdargs{log}{\emph{filename}} para ver qué conjuntos de cambios y
   2.306 +parches afectaron un fichero.  Puede usar la orden \hgext{bisect} para
   2.307 +hacer una búsqueda binaria sobre todos los conjuntos de cambios y
   2.308 +parches aplicados para ver dónde se introdujo un fallo o dónde fue
   2.309 +arreglado.  Puede usar la orden \hgcmd{annotate} para ver qué
   2.310 +conjuntos de cambios o parches modificaron una línea particular de un
   2.311 +archivo fuente. Y mucho más.
   2.312 +
   2.313 +\section{Entender los parches}
   2.314  \label{sec:mq:patch}
   2.315  
   2.316 -Because MQ doesn't hide its patch-oriented nature, it is helpful to
   2.317 -understand what patches are, and a little about the tools that work
   2.318 -with them.
   2.319 -
   2.320 -The traditional Unix \command{diff} command compares two files, and
   2.321 -prints a list of differences between them. The \command{patch} command
   2.322 -understands these differences as \emph{modifications} to make to a
   2.323 -file.  Take a look at figure~\ref{ex:mq:diff} for a simple example of
   2.324 -these commands in action.
   2.325 +Dado que MQ no esconde su naturaleza parche-céntrica, es muy útil para
   2.326 +entender de qué se tratan los parches, y un poco acerca de las
   2.327 +herramientas que trabajan con ellos.
   2.328 +
   2.329 +La orden de Unix tradicional \command{diff} compara dos ficheros, e
   2.330 +imprime una lista de diferencias de sus líneas.  La orden
   2.331 +\command{patch} entiende esas diferencias como \emph{modificaciones}
   2.332 +para construir un fichero.  Vea en la figura~\ref{ex:mq:diff} un
   2.333 +ejemplo sencillo de tales órdenes en acción.
   2.334  
   2.335  \begin{figure}[ht]
   2.336    \interaction{mq.dodiff.diff}
   2.337 -  \caption{Simple uses of the \command{diff} and \command{patch} commands}
   2.338 +  \caption{Uso sencillo de las órdenes \command{diff} y \command{patch}}
   2.339    \label{ex:mq:diff}
   2.340  \end{figure}
   2.341  
   2.342 -The type of file that \command{diff} generates (and \command{patch}
   2.343 -takes as input) is called a ``patch'' or a ``diff''; there is no
   2.344 -difference between a patch and a diff.  (We'll use the term ``patch'',
   2.345 -since it's more commonly used.)
   2.346 -
   2.347 -A patch file can start with arbitrary text; the \command{patch}
   2.348 -command ignores this text, but MQ uses it as the commit message when
   2.349 -creating changesets.  To find the beginning of the patch content,
   2.350 -\command{patch} searches for the first line that starts with the
   2.351 -string ``\texttt{diff~-}''.
   2.352 -
   2.353 -MQ works with \emph{unified} diffs (\command{patch} can accept several
   2.354 -other diff formats, but MQ doesn't).  A unified diff contains two
   2.355 -kinds of header.  The \emph{file header} describes the file being
   2.356 -modified; it contains the name of the file to modify.  When
   2.357 -\command{patch} sees a new file header, it looks for a file with that
   2.358 -name to start modifying.
   2.359 -
   2.360 -After the file header comes a series of \emph{hunks}.  Each hunk
   2.361 -starts with a header; this identifies the range of line numbers within
   2.362 -the file that the hunk should modify.  Following the header, a hunk
   2.363 -starts and ends with a few (usually three) lines of text from the
   2.364 -unmodified file; these are called the \emph{context} for the hunk.  If
   2.365 -there's only a small amount of context between successive hunks,
   2.366 -\command{diff} doesn't print a new hunk header; it just runs the hunks
   2.367 -together, with a few lines of context between modifications.
   2.368 -
   2.369 -Each line of context begins with a space character.  Within the hunk,
   2.370 -a line that begins with ``\texttt{-}'' means ``remove this line,''
   2.371 -while a line that begins with ``\texttt{+}'' means ``insert this
   2.372 -line.''  For example, a line that is modified is represented by one
   2.373 -deletion and one insertion.
   2.374 -
   2.375 -We will return to some of the more subtle aspects of patches later (in
   2.376 -section~\ref{sec:mq:adv-patch}), but you should have enough information
   2.377 -now to use MQ.
   2.378 -
   2.379 -\section{Getting started with Mercurial Queues}
   2.380 +El tipo de fichero que \command{diff} genera (y que \command{patch}
   2.381 +toma como entrada) se llama un ``parche'' o un ``diff''; no hay
   2.382 +diferencia entre un parche y un diff.  (Usaremos el término ``parche'',
   2.383 +dado que es el que más comunmente se usa.)
   2.384 +
   2.385 +Un parche puede comenzar con un texto arbitrario; la orden \command{patch}
   2.386 +ignora este texto, pero MQ lo usa como el mensaje de consignación
   2.387 +cuando se crean conjuntos de cambios.  Para encontrar el inicio del
   2.388 +contenido de un parche, la orden \command{patch} busca la primera
   2.389 +línea que comience con la cadena ``\texttt{diff~-}''.
   2.390 +
   2.391 +MQ trabaja con diffs \emph{unificados} (\command{patch} acepta varios
   2.392 +formatos de diff adicionales, pero MQ no).  Un diff unificado contiene
   2.393 +dos clases de encabezados.  El \emph{encabezado de fichero} describe
   2.394 +el fichero que se está modificando; contiene el nombre del fichero a
   2.395 +modificar.  Cuando \command{patch} ve un nuevo encabezado de fichero,
   2.396 +busca un fichero con ese nombre para modificarlo.
   2.397 +
   2.398 +Después del encabezaado vienen varios \emph{trozos}.  Cada trozo
   2.399 +comienza con un encabezado; que identifica el rango de líneas del
   2.400 +fichero que el trozo debe modificar.  Después del encabezado, un trozo
   2.401 +comienza y termina con unas pocas líneas(usualmente tres) de texto del
   2.402 +fichero que no han sido modificadas; las cuales llamamos el
   2.403 +\emph{contexto} del trozo.  Si solamente hay una pequeña cantidad de
   2.404 +contexto entre trozos sucesivos, \command{diff} no imprime un nuevo
   2.405 +encabezado para el trozo, continua integrando los trozos, con unas
   2.406 +líneas de contexto entre las modificaciones.
   2.407 +
   2.408 +Cada línea de contexto comienza con un caracter de espacio.  En el
   2.409 +trozo, si una línea comienza con ``\texttt{-}'' significa ``elimine
   2.410 +esta línea'', si la línea comienza con un ``\texttt{+}'' significa
   2.411 +``inserte esta línea''.  Por ejemplo, una línea que se modifica se
   2.412 +representa con una línea eliminada y una línea insertada.
   2.413 +
   2.414 +Retomaremos aspectos más sutiles acerca de parches posteriormente(en
   2.415 +la sección~\ref{sec:mq:adv-patch}), pero en el momento usted ya
   2.416 +debería tener suficiente información para usar MQ.
   2.417 +
   2.418 +\section{Comenzar a usar Colas de Mercurial}
   2.419  \label{sec:mq:start}
   2.420  
   2.421 -Because MQ is implemented as an extension, you must explicitly enable
   2.422 -before you can use it.  (You don't need to download anything; MQ ships
   2.423 -with the standard Mercurial distribution.)  To enable MQ, edit your
   2.424 -\tildefile{.hgrc} file, and add the lines in figure~\ref{ex:mq:config}.
   2.425 +Dado que MQ está implementado como una extensión, debe habilitarla
   2.426 +explícitamente antes de comenzar a usarla.  (No necesita descargar
   2.427 +nada; MQ viene con la distribución estándar de Mercurial.)  Para
   2.428 +habilitar MQ, edite su fichero \tildefile{.hgrc}, y añada las líneas
   2.429 +de la figura~\ref{ex:mq:config}.
   2.430  
   2.431  \begin{figure}[ht]
   2.432    \begin{codesample4}
   2.433 @@ -222,172 +239,182 @@
   2.434      hgext.mq =
   2.435    \end{codesample4}
   2.436    \label{ex:mq:config}
   2.437 -  \caption{Contents to add to \tildefile{.hgrc} to enable the MQ extension}
   2.438 -\end{figure}
   2.439 -
   2.440 -Once the extension is enabled, it will make a number of new commands
   2.441 -available.  To verify that the extension is working, you can use
   2.442 -\hgcmd{help} to see if the \hgxcmd{mq}{qinit} command is now available; see
   2.443 -the example in figure~\ref{ex:mq:enabled}.
   2.444 +  \caption{Líneas a añadir en \tildefile{.hgrc} para habilitar la extensión MQ}
   2.445 +\end{figure}
   2.446 +
   2.447 +Cuando la extensión esté habilitada, aparecerán varios comandos.  Para
   2.448 +verificar que la extensión está trabajando, puede usar \hgcmd{help}
   2.449 +para ver si la orden \hgxcmd{mq}{qinit} está disponible; vea un
   2.450 +ejemplo en la figura~\ref{ex:mq:enabled}.
   2.451  
   2.452  \begin{figure}[ht]
   2.453    \interaction{mq.qinit-help.help}
   2.454 -  \caption{How to verify that MQ is enabled}
   2.455 +  \caption{Cómo verificar que MQ está habilitado}
   2.456    \label{ex:mq:enabled}
   2.457  \end{figure}
   2.458  
   2.459 -You can use MQ with \emph{any} Mercurial repository, and its commands
   2.460 -only operate within that repository.  To get started, simply prepare
   2.461 -the repository using the \hgxcmd{mq}{qinit} command (see
   2.462 -figure~\ref{ex:mq:qinit}).  This command creates an empty directory
   2.463 -called \sdirname{.hg/patches}, where MQ will keep its metadata.  As
   2.464 -with many Mercurial commands, the \hgxcmd{mq}{qinit} command prints nothing
   2.465 -if it succeeds.
   2.466 +Puede usar MQ en \emph{cualquier} repositorio de Mercurial, y sus
   2.467 +comandos solamente operarán con tal repositorio.  Para comenzar, basta
   2.468 +con preparar el repositorio con la orden \hgxcmd{mq}{qinit}(ver la
   2.469 +figura~\ref{ex:mq:qinit}).  Esta orden crea un directorio vacío
   2.470 +llamado \sdirname{.hg/patches}, donde MQ mantendrá sus metadatos. Como
   2.471 +otras ordenes de Mercurial, la orden \hgxcmd{mq}{qinit} no imprime
   2.472 +nada cuando es exitosa.
   2.473  
   2.474  \begin{figure}[ht]
   2.475    \interaction{mq.tutorial.qinit}
   2.476 -  \caption{Preparing a repository for use with MQ}
   2.477 +  \caption{Preparar un repositorio para usar MQ}
   2.478    \label{ex:mq:qinit}
   2.479  \end{figure}
   2.480  
   2.481  \begin{figure}[ht]
   2.482    \interaction{mq.tutorial.qnew}
   2.483 -  \caption{Creating a new patch}
   2.484 +  \caption{Crear un nuevo parche}
   2.485    \label{ex:mq:qnew}
   2.486  \end{figure}
   2.487  
   2.488 -\subsection{Creating a new patch}
   2.489 -
   2.490 -To begin work on a new patch, use the \hgxcmd{mq}{qnew} command.  This
   2.491 -command takes one argument, the name of the patch to create.  MQ will
   2.492 -use this as the name of an actual file in the \sdirname{.hg/patches}
   2.493 -directory, as you can see in figure~\ref{ex:mq:qnew}.
   2.494 -
   2.495 -Also newly present in the \sdirname{.hg/patches} directory are two
   2.496 -other files, \sfilename{series} and \sfilename{status}.  The
   2.497 -\sfilename{series} file lists all of the patches that MQ knows about
   2.498 -for this repository, with one patch per line.  Mercurial uses the
   2.499 -\sfilename{status} file for internal book-keeping; it tracks all of the
   2.500 -patches that MQ has \emph{applied} in this repository.
   2.501 +\subsection{Crear un nuevo parche}
   2.502 +
   2.503 +Para comenzar a trabajar en un nuevo parche use la orden
   2.504 +\hgxcmd{mq}{qnew}. Esta orden recibe un argumento, el nombre del
   2.505 +parche a crear.  MQ lo usará como el nombre del fichero en el
   2.506 +directorio \sdirname{.hg/patches}, como puede apreciarlo en la
   2.507 +figura~\ref{ex:mq:qnew}.
   2.508 +
   2.509 +También hay otros dos nuevos ficheros en el directorio
   2.510 +\sdirname{.hg/patches}:  \sfilename{series} y \sfilename{status}.  El
   2.511 +fichero \sfilename{series} lista todos los parches de los cuales MQ
   2.512 +tiene noticia para este repositorio, con un parche por línea.
   2.513 +Mercurial usa el fichero \sfilename{status} para mantener registros
   2.514 +interns; da seguimiento a todos los parches que MQ ha \emph{aplicado}
   2.515 +en el repositorio.
   2.516  
   2.517  \begin{note}
   2.518 -  You may sometimes want to edit the \sfilename{series} file by hand;
   2.519 -  for example, to change the sequence in which some patches are
   2.520 -  applied.  However, manually editing the \sfilename{status} file is
   2.521 -  almost always a bad idea, as it's easy to corrupt MQ's idea of what
   2.522 -  is happening.
   2.523 +  En ciertas ocasiones usted querrá editar el fichero
   2.524 +  \sfilename{series} a mano; por ejemplo, cambiar el orden en que se
   2.525 +  aplican ciertos parches.  A pesar de esto, es una mala idea editar
   2.526 +  manualmente  el fichero \sfilename{status}, dado que es fácil
   2.527 +  desorientar a MQ acerca de lo que está pasando.
   2.528  \end{note}
   2.529  
   2.530 -Once you have created your new patch, you can edit files in the
   2.531 -working directory as you usually would.  All of the normal Mercurial
   2.532 -commands, such as \hgcmd{diff} and \hgcmd{annotate}, work exactly as
   2.533 -they did before.
   2.534 -
   2.535 -\subsection{Refreshing a patch}
   2.536 -
   2.537 -When you reach a point where you want to save your work, use the
   2.538 -\hgxcmd{mq}{qrefresh} command (figure~\ref{ex:mq:qnew}) to update the patch
   2.539 -you are working on.  This command folds the changes you have made in
   2.540 -the working directory into your patch, and updates its corresponding
   2.541 -changeset to contain those changes.
   2.542 +Una vez que haya creado un nuevo parche, puede editar los ficheros en
   2.543 +el directorio de trabajo, como lo haría usualmente.  Toda las órdenes
   2.544 +que de a Mercurial, tales como \hgcmd{diff} y \hgcmd{annotate},
   2.545 +trabajarán de la misma forma como lo han hecho antes.
   2.546 +
   2.547 +\subsection{Refrescar un parche}
   2.548 +
   2.549 +Cuando usted llega a un punto en el cual desea guardar su trabajo, use
   2.550 +la orden \hgxcmd{mq}{qrefresh}(figura~\ref{ex:mq:qnew}) para
   2.551 +actualizar el parche en el cual está trabajando.  Esta orden almacena
   2.552 +los cambios que haya hecho al directorio actual de trabajo en su
   2.553 +parche, y almacena el conjunto de cambios correspondiente que contiene
   2.554 +los cambios.
   2.555  
   2.556  \begin{figure}[ht]
   2.557    \interaction{mq.tutorial.qrefresh}
   2.558 -  \caption{Refreshing a patch}
   2.559 +  \caption{Refrescar un parche}
   2.560    \label{ex:mq:qrefresh}
   2.561  \end{figure}
   2.562  
   2.563 -You can run \hgxcmd{mq}{qrefresh} as often as you like, so it's a good way
   2.564 -to ``checkpoint'' your work.  Refresh your patch at an opportune
   2.565 -time; try an experiment; and if the experiment doesn't work out,
   2.566 -\hgcmd{revert} your modifications back to the last time you refreshed.
   2.567 +Puede ejecutar la orden \hgxcmd{mq}{qrefresh} tan seguido como quiera,
   2.568 +y es una buena forma de ``colocar marcas'' a su trabajo.  Refresque su
   2.569 +parche en momentos oportunos; intente un experimento; si el
   2.570 +experimento no funciona, Use \hgcmd{revert} sobre sus modificaciones
   2.571 +para volver al refresco anterior.
   2.572  
   2.573  \begin{figure}[ht]
   2.574    \interaction{mq.tutorial.qrefresh2}
   2.575 -  \caption{Refresh a patch many times to accumulate changes}
   2.576 +  \caption{Refrescar un parche muchas veces para acumular cambios}
   2.577    \label{ex:mq:qrefresh2}
   2.578  \end{figure}
   2.579  
   2.580 -\subsection{Stacking and tracking patches}
   2.581 -
   2.582 -Once you have finished working on a patch, or need to work on another,
   2.583 -you can use the \hgxcmd{mq}{qnew} command again to create a new patch.
   2.584 -Mercurial will apply this patch on top of your existing patch.  See
   2.585 -figure~\ref{ex:mq:qnew2} for an example.  Notice that the patch
   2.586 -contains the changes in our prior patch as part of its context (you
   2.587 -can see this more clearly in the output of \hgcmd{annotate}).
   2.588 +\subsection{Aplicar un parche tras otro y dar seguimiento}
   2.589 +
   2.590 +Cuando haya terminado de trabajar en un parche, o necesite trabajar en
   2.591 +otro, puede usar la orden \hgxcmd{mq}{qnew} para crear un nuevo
   2.592 +parche.  Mercurial aplicará este parche sobre su parche anterior.
   2.593 +Para un ejemplo, ver la figura~\ref{ex:mq:qnew2}.  Note que el parche
   2.594 +contiene los cambios en nuestro parche anterior como parte de su
   2.595 +contexto( lo verá más claramente en la salida de \hgcmd{annotate}).
   2.596  
   2.597  \begin{figure}[ht]
   2.598    \interaction{mq.tutorial.qnew2}
   2.599 -  \caption{Stacking a second patch on top of the first}
   2.600 +  \caption{Aplicar un parche después del primero}
   2.601    \label{ex:mq:qnew2}
   2.602  \end{figure}
   2.603  
   2.604 -So far, with the exception of \hgxcmd{mq}{qnew} and \hgxcmd{mq}{qrefresh}, we've
   2.605 -been careful to only use regular Mercurial commands.  However, MQ
   2.606 -provides many commands that are easier to use when you are thinking
   2.607 -about patches, as illustrated in figure~\ref{ex:mq:qseries}:
   2.608 +Hasta ahora, con excepción de \hgxcmd{mq}{qnew} y
   2.609 +\hgxcmd{mq}{qrefresh}, hemos sido cuidadosos para aplicar únicamente
   2.610 +órdenes usuaales de Mercurial.  De todas maneras, MQ ofrece muchos
   2.611 +comandos que son más sencillos de usar cuando esté pensando acerca de
   2.612 +parches, como se puede ver en la figura~\ref{ex:mq:qseries}:
   2.613  
   2.614  \begin{itemize}
   2.615 -\item The \hgxcmd{mq}{qseries} command lists every patch that MQ knows
   2.616 -  about in this repository, from oldest to newest (most recently
   2.617 -  \emph{created}).
   2.618 -\item The \hgxcmd{mq}{qapplied} command lists every patch that MQ has
   2.619 -  \emph{applied} in this repository, again from oldest to newest (most
   2.620 -  recently applied).
   2.621 +\item La orden \hgxcmd{mq}{qseries} lista cada parche del cual MQ
   2.622 +  tiene noticia en este repositorio, desde el más antiguo hasta el más
   2.623 +  nuevo(El último \emph{creado}).
   2.624 +\item La orden \hgxcmd{mq}{qapplied} lista cada parche que MQ haya
   2.625 +  \emph{aplicado} en este repositorio, de nuevo, desde el más antiguo
   2.626 +  hasta el más nuevo (El aplicado más recientemente).
   2.627  \end{itemize}
   2.628  
   2.629  \begin{figure}[ht]
   2.630    \interaction{mq.tutorial.qseries}
   2.631 -  \caption{Understanding the patch stack with \hgxcmd{mq}{qseries} and
   2.632 +  \caption{Entender la pila de parches con \hgxcmd{mq}{qseries} y
   2.633      \hgxcmd{mq}{qapplied}}
   2.634    \label{ex:mq:qseries}
   2.635  \end{figure}
   2.636  
   2.637 -\subsection{Manipulating the patch stack}
   2.638 -
   2.639 -The previous discussion implied that there must be a difference
   2.640 -between ``known'' and ``applied'' patches, and there is.  MQ can
   2.641 -manage a patch without it being applied in the repository.
   2.642 -
   2.643 -An \emph{applied} patch has a corresponding changeset in the
   2.644 -repository, and the effects of the patch and changeset are visible in
   2.645 -the working directory.  You can undo the application of a patch using
   2.646 -the \hgxcmd{mq}{qpop} command.  MQ still \emph{knows about}, or manages, a
   2.647 -popped patch, but the patch no longer has a corresponding changeset in
   2.648 -the repository, and the working directory does not contain the changes
   2.649 -made by the patch.  Figure~\ref{fig:mq:stack} illustrates the
   2.650 -difference between applied and tracked patches.
   2.651 +\subsection{Manipular la pila de parches}
   2.652 +
   2.653 +La discusión previa indicó que debe haber una diferencia entre los
   2.654 +parches ``conocidos'' y ``aplicados'', y efectivamente la hay.  MQ
   2.655 +puede manejar un parche sin que este haya sido aplicado al
   2.656 +repositorio.
   2.657 +
   2.658 +Un parche \emph{aplicado} tiene su correspondiente conjunto de cambios
   2.659 +en el repositorio, y los efectos del parche y el conjunto de cambios
   2.660 +son visibles en el directorio de trabajo.  Puede deshacer la
   2.661 +aplicación de un parche con la orden \hgxcmd{mq}{qpop}.  MQ 
   2.662 +\emph{sabe acerca de}, o maneja un parche sustraído, pero el parche ya
   2.663 +no tendrá un conjunto de cambios correspondientes en el repositorio, y
   2.664 +el directorio de trabajo no contendrá los cambios hechos por el
   2.665 +parche.  La figura~\ref{fig:mq:stack} ilustra la diferencia entre
   2.666 +parches aplicados y seguidos.
   2.667  
   2.668  \begin{figure}[ht]
   2.669    \centering
   2.670    \grafix{mq-stack}
   2.671 -  \caption{Applied and unapplied patches in the MQ patch stack}
   2.672 +  \caption{Parches aplicados y no aplicados en la pila de parches de MQ}
   2.673    \label{fig:mq:stack}
   2.674  \end{figure}
   2.675  
   2.676 -You can reapply an unapplied, or popped, patch using the \hgxcmd{mq}{qpush}
   2.677 -command.  This creates a new changeset to correspond to the patch, and
   2.678 -the patch's changes once again become present in the working
   2.679 -directory.  See figure~\ref{ex:mq:qpop} for examples of \hgxcmd{mq}{qpop}
   2.680 -and \hgxcmd{mq}{qpush} in action.  Notice that once we have popped a patch
   2.681 -or two patches, the output of \hgxcmd{mq}{qseries} remains the same, while
   2.682 -that of \hgxcmd{mq}{qapplied} has changed.
   2.683 +Puede reaplicar un parche no aplicado o sustraído con la orden
   2.684 +\hgxcmd{mq}{qpush}.  Esto crea un nuevo conjunto de cambios
   2.685 +correspondiente al parche, y los cambios del parche estarán presentes
   2.686 +de nuevo en el directorio de trabajo.  Vea ejemplos de
   2.687 +\hgxcmd{mq}{qpop} y \hgxcmd{mq}{qpush} en acción en la
   2.688 +figura~\ref{ex:mq:qpop}.  Vea que hemos sustraído uno o dos parches,
   2.689 +la salida de\hgxcmd{mq}{qseries} continúa igual, mientras que
   2.690 +\hgxcmd{mq}{qapplied} ha  cambiado.
   2.691  
   2.692  \begin{figure}[ht]
   2.693    \interaction{mq.tutorial.qpop}
   2.694 -  \caption{Modifying the stack of applied patches}
   2.695 +  \caption{Modificar la pila de parches aplicados}
   2.696    \label{ex:mq:qpop}
   2.697  \end{figure}
   2.698  
   2.699 -\subsection{Pushing and popping many patches}
   2.700 -
   2.701 -While \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} each operate on a single patch at
   2.702 -a time by default, you can push and pop many patches in one go.  The
   2.703 -\hgxopt{mq}{qpush}{-a} option to \hgxcmd{mq}{qpush} causes it to push all
   2.704 -unapplied patches, while the \hgxopt{mq}{qpop}{-a} option to \hgxcmd{mq}{qpop}
   2.705 -causes it to pop all applied patches.  (For some more ways to push and
   2.706 -pop many patches, see section~\ref{sec:mq:perf} below.)
   2.707 +\subsection{Introducir y sustraer muchos parches}
   2.708 +
   2.709 +Mientras que \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} operan sobre un
   2.710 +único parche cada vez, puede introducir y sustraer varios parches de
   2.711 +una vez.  La opción \hgxopt{mq}{qpush}{-a} de \hgxcmd{mq}{qpush}
   2.712 +introduce todos los cambios que no hayan sido aplicados, mientras que
   2.713 +la opción \hgxopt{mq}{qpop}{-a} de \hgxcmd{mq}{qpop} sustrae todos los
   2.714 +cambios aplicados.  (Vea la sección~\ref{sec:mq:perf} más adelante
   2.715 +en la cual se explican otras formas de de introducir y sustraer varios
   2.716 +cambios.)
   2.717  
   2.718  \begin{figure}[ht]
   2.719    \interaction{mq.tutorial.qpush-a}
   2.720 @@ -395,48 +422,53 @@
   2.721    \label{ex:mq:qpush-a}
   2.722  \end{figure}
   2.723  
   2.724 -\subsection{Safety checks, and overriding them}
   2.725 -
   2.726 -Several MQ commands check the working directory before they do
   2.727 -anything, and fail if they find any modifications.  They do this to
   2.728 -ensure that you won't lose any changes that you have made, but not yet
   2.729 -incorporated into a patch.  Figure~\ref{ex:mq:add} illustrates this;
   2.730 -the \hgxcmd{mq}{qnew} command will not create a new patch if there are
   2.731 -outstanding changes, caused in this case by the \hgcmd{add} of
   2.732 -\filename{file3}.
   2.733 +\subsection{Medidas de seguridad y cómo saltarlas}
   2.734 +
   2.735 +Muchas órdenes MQ revisan el directorio de trabajo antes de hacer
   2.736 +cualquier cosa, y fallan si encuentran alguna modificación.  Lo hacen
   2.737 +para garantizar que usted no pierda cambio alguno de los que haya
   2.738 +hecho, pero que no hayan sido incorporados en algún parche.  La
   2.739 +figura~\ref{ex:mq:add} ilusta esto; la orden \hgxcmd{mq}{qnew} no
   2.740 +creará un nuevo parche si hay cambios notorios, causados en este caso
   2.741 +por aplicado la orden \hgcmd{add} a \filename{file3}.
   2.742  
   2.743  \begin{figure}[ht]
   2.744    \interaction{mq.tutorial.add}
   2.745 -  \caption{Forcibly creating a patch}
   2.746 +  \caption{Crear un parche a la fuerza}
   2.747    \label{ex:mq:add}
   2.748  \end{figure}
   2.749  
   2.750 -Commands that check the working directory all take an ``I know what
   2.751 -I'm doing'' option, which is always named \option{-f}.  The exact
   2.752 -meaning of \option{-f} depends on the command.  For example,
   2.753 -\hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}} will incorporate any outstanding
   2.754 -changes into the new patch it creates, but
   2.755 -\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} will revert modifications to any
   2.756 -files affected by the patch that it is popping.  Be sure to read the
   2.757 -documentation for a command's \option{-f} option before you use it!
   2.758 -
   2.759 -\subsection{Working on several patches at once}
   2.760 -
   2.761 -The \hgxcmd{mq}{qrefresh} command always refreshes the \emph{topmost}
   2.762 -applied patch.  This means that you can suspend work on one patch (by
   2.763 -refreshing it), pop or push to make a different patch the top, and
   2.764 -work on \emph{that} patch for a while.
   2.765 -
   2.766 -Here's an example that illustrates how you can use this ability.
   2.767 -Let's say you're developing a new feature as two patches.  The first
   2.768 -is a change to the core of your software, and the second---layered on
   2.769 -top of the first---changes the user interface to use the code you just
   2.770 -added to the core.  If you notice a bug in the core while you're
   2.771 -working on the UI patch, it's easy to fix the core.  Simply
   2.772 -\hgxcmd{mq}{qrefresh} the UI patch to save your in-progress changes, and
   2.773 -\hgxcmd{mq}{qpop} down to the core patch.  Fix the core bug,
   2.774 -\hgxcmd{mq}{qrefresh} the core patch, and \hgxcmd{mq}{qpush} back to the UI
   2.775 -patch to continue where you left off.
   2.776 +Las órdenes que revisan el directorio actual cuentan con una opción
   2.777 +``Se lo que estoy haciendo'', que siempre está nombrada como
   2.778 +\option{-f}.  El significado exacto de \option{-f} depende de la
   2.779 +orden.  Por ejemplo, \hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}}
   2.780 +incorporarán cualquier cambio notorio en el nuevo parche que crea pero
   2.781 +\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} revertirá las modificaciones a
   2.782 +cualquier fichero que haya sido afectado por el parche que está siendo
   2.783 +sustraído. ¡Asegúrese de leer la documentación de la opción \option{-f}
   2.784 +de cada comando antes de usarla!
   2.785 +
   2.786 +\subsection{Trabajar con varios parches a la vez}
   2.787 +
   2.788 +La orden \hgxcmd{mq}{qrefresh} siempre refresca el \emph{último}
   2.789 +parche aplicado.  Esto significa que usted puede suspender su trabajo
   2.790 +en un parche (refrescándolo), sustraerlo o introducirlo para lograr
   2.791 +que otro parche esté de último y trabajar en \emph{ese} parche por un
   2.792 +rato.
   2.793 +
   2.794 +A continuación un ejemplo que ilustra cómo puede usar esta habilidad.
   2.795 +Digamos que está desarrollando una nueva característica en dos
   2.796 +parches.  El primero es un cambio en la parte fundamental de su
   2.797 +programa, y el segundo--sobre el primero---cambia la interfaz de
   2.798 +usuario para usar el código que ha añadido a la parte fundamental.  Si
   2.799 +ve que hay un fallo en la parte fundamental mientras está trabajando
   2.800 +en el parche de UI\ndt{Interfaz de Usuario, User Interface en inglés}, es fácil arreglar la parte fundamental.
   2.801 +Simplemente use \hgxcmd{mq}{qrefresh} sobre el parche de la UI para
   2.802 +guardar los cambios de su trabajo en progreso, y use \hgxcmd{mq}{qpop}
   2.803 +para sacar sustraer el parche de la parte fundamental.  Arregla el
   2.804 +fallo sobre la parte fundamental, aplique \hgxcmd{mq}{qrefresh} sobre
   2.805 +el parche fundamental, y aplique \hgxcmd{mq}{qpush} sobre el parche de
   2.806 +UI para continuar donde había quedado.
   2.807  
   2.808  \section{More about patches}
   2.809  \label{sec:mq:adv-patch}