1.1 --- a/es/mq.tex	Sat Dec 06 01:01:39 2008 -0500
     1.2 +++ b/es/mq.tex	Sun Dec 07 17:47:38 2008 -0500
     1.3 @@ -4,217 +4,234 @@
     1.4  \section{El problema de la administración de parches}
     1.5  \label{sec:mq:patch-mgmt}
     1.6  
     1.7 -Here is a common scenario: you need to install a software package from
     1.8 -source, but you find a bug that you must fix in the source before you
     1.9 -can start using the package.  You make your changes, forget about the
    1.10 -package for a while, and a few months later you need to upgrade to a
    1.11 -newer version of the package.  If the newer version of the package
    1.12 -still has the bug, you must extract your fix from the older source
    1.13 -tree and apply it against the newer version.  This is a tedious task,
    1.14 -and it's easy to make mistakes.
    1.15 -
    1.16 -This is a simple case of the ``patch management'' problem.  You have
    1.17 -an ``upstream'' source tree that you can't change; you need to make
    1.18 -some local changes on top of the upstream tree; and you'd like to be
    1.19 -able to keep those changes separate, so that you can apply them to
    1.20 -newer versions of the upstream source.
    1.21 -
    1.22 -The patch management problem arises in many situations.  Probably the
    1.23 -most visible is that a user of an open source software project will
    1.24 -contribute a bug fix or new feature to the project's maintainers in the
    1.25 -form of a patch.
    1.26 -
    1.27 -Distributors of operating systems that include open source software
    1.28 -often need to make changes to the packages they distribute so that
    1.29 -they will build properly in their environments.
    1.30 -
    1.31 -When you have few changes to maintain, it is easy to manage a single
    1.32 -patch using the standard \command{diff} and \command{patch} programs
    1.33 -(see section~\ref{sec:mq:patch} for a discussion of these tools).
    1.34 -Once the number of changes grows, it starts to make sense to maintain
    1.35 -patches as discrete ``chunks of work,'' so that for example a single
    1.36 -patch will contain only one bug fix (the patch might modify several
    1.37 -files, but it's doing ``only one thing''), and you may have a number
    1.38 -of such patches for different bugs you need fixed and local changes
    1.39 -you require.  In this situation, if you submit a bug fix patch to the
    1.40 -upstream maintainers of a package and they include your fix in a
    1.41 -subsequent release, you can simply drop that single patch when you're
    1.42 -updating to the newer release.
    1.43 -
    1.44 -Maintaining a single patch against an upstream tree is a little
    1.45 -tedious and error-prone, but not difficult.  However, the complexity
    1.46 -of the problem grows rapidly as the number of patches you have to
    1.47 -maintain increases.  With more than a tiny number of patches in hand,
    1.48 -understanding which ones you have applied and maintaining them moves
    1.49 -from messy to overwhelming.
    1.50 -
    1.51 -Fortunately, Mercurial includes a powerful extension, Mercurial Queues
    1.52 -(or simply ``MQ''), that massively simplifies the patch management
    1.53 -problem.
    1.54 -
    1.55 -\section{The prehistory of Mercurial Queues}
    1.56 +Un escenario frecuente: usted necesita instalar un paquete de software
    1.57 +desde las fuentes, pero encuentra un fallo que debe arreglar antes de
    1.58 +poder comenzar a usarlo.  Hace sus cambios, y se olvida del paquete
    1.59 +por un tiempo, unos meses después necesita actualizar a una nueva
    1.60 +versión del paquete.  Si la nueva versión del paquete todavía tiene el
    1.61 +fallo, debe extraer su arreglo del árbol de fuentes anteriores y
    1.62 +aplicarlo a la nueva versión.  Una tarea tediosa en la cual es fácil
    1.63 +equivocarse.
    1.64 +
    1.65 +Este es un caso simple del problema del ``manejo de parches''.  Usted
    1.66 +tiene un árbol de fuentes del ``mantenedor principal'' que no puede
    1.67 +cambiar: necesita hacer algunos cambios locales sobre el árbol
    1.68 +principal; y desearía poder mantener tales cambios separados, de forma
    1.69 +tal que pueda aplicarlos a versiones más nuevas del árbol principal.
    1.70 +
    1.71 +El problema de administración de parches surge en muchas situaciones.
    1.72 +Probablemente la más visible es cuando un usuario de un proyecto de
    1.73 +software de fuentes abiertas contribuye con un arreglo de un fallo o
    1.74 +una nueva característica a los mantenedores del proyecto en la forma
    1.75 +de un parche.
    1.76 +
    1.77 +Aquellos que distribuyen sistemas operativos que incluyen programas
    1.78 +abiertos usualmente requieren hacer cambios en los paquetes que
    1.79 +distribuyen de tal forma que se armen apropiadamente en sus ambientes.
    1.80 +
    1.81 +Cuando hay pocos cambios por mantener, es muy sencillo administrar un
    1.82 +solo parche con los programas estándar \command{diff} y
    1.83 +\command{patch}( ver la sección~\ref{sec:mq:patch} para ver cómo
    1.84 +emplear tales herramientas). Cuando la cantidad de cambios comienza a
    1.85 +crecer, tiene sentido mantener parches como ``porciones de trabajo''
    1.86 +individual, de forma que cada cambio contiene solamente un arreglo de
    1.87 +un fallo(el parche puede modificar varios archivos, pero está
    1.88 +``haciendo una sola cosa''), y puede tener cierta cantidad de tales
    1.89 +parches para diferentes fallos y cambios locales.  En esta situación,
    1.90 +si envía un parche que arregla un fallo a los mantenedores principales
    1.91 +de un paquete y ellos incluyen su arreglo en una publicación
    1.92 +posterior, puede deshacerse de tal parche cuando se actualice a la
    1.93 +nueva versión.
    1.94 +
    1.95 +Mantener un solo parche frente a un árbol principal es algo tedioso y
    1.96 +es fácil equivocarse, pero no es difícil.  Aunque, la complejidad del
    1.97 +problema crece rápidamente a medida que la cantidad de parches que
    1.98 +tiene que mantener crece.  Con más que una pequeña cantidad de
    1.99 +cambios, entender cuáles ha aplicado se convierte de algo desordenado
   1.100 +a algo avasallante.
   1.101 +
   1.102 +Afortunadamente Mercurial provee una extensión poderos: Colas de
   1.103 +Mercurial( o simplemente ``MQ''), que simplifica en gran medida el
   1.104 +problema de administración de parches.
   1.105 +
   1.106 +\section{La prehistoria de las Colas de Mercurial}
   1.107  \label{sec:mq:history}
   1.108  
   1.109 -During the late 1990s, several Linux kernel developers started to
   1.110 -maintain ``patch series'' that modified the behaviour of the Linux
   1.111 -kernel.  Some of these series were focused on stability, some on
   1.112 -feature coverage, and others were more speculative.
   1.113 -
   1.114 -The sizes of these patch series grew rapidly.  In 2002, Andrew Morton
   1.115 -published some shell scripts he had been using to automate the task of
   1.116 -managing his patch queues.  Andrew was successfully using these
   1.117 -scripts to manage hundreds (sometimes thousands) of patches on top of
   1.118 -the Linux kernel.
   1.119 -
   1.120 -\subsection{A patchwork quilt}
   1.121 +A finales de los 90s, muchos desarrolladores del núcleo de Linux
   1.122 +comenzaron a mantener ``series de parches'' que modificaron el
   1.123 +comportamiento del núcleo de Linux.  Algunos se enfocaban en
   1.124 +estabilidad, otros en aumentar las características, y otros un poco
   1.125 +más especulativos.
   1.126 +
   1.127 +Los tamaños de las series de parches crecieron rápidamente.  En el
   1.128 +2002, Andrew Morton publicó algunos guiones de línea de órdenes que
   1.129 +estuvo usando para automatizar la tarea de administrar su cola de
   1.130 +parches.  Andrew usó exitósamente tales guiones para administrar
   1.131 +centenas( aveces millares) de parches en el núcleo de Linux.
   1.132 +
   1.133 +\subsection{Trabajar parches con quilt}
   1.134  \label{sec:mq:quilt}
   1.135  
   1.136 -In early 2003, Andreas Gruenbacher and Martin Quinson borrowed the
   1.137 -approach of Andrew's scripts and published a tool called ``patchwork
   1.138 -quilt''~\cite{web:quilt}, or simply ``quilt''
   1.139 -(see~\cite{gruenbacher:2005} for a paper describing it).  Because
   1.140 -quilt substantially automated patch management, it rapidly gained a
   1.141 -large following among open source software developers.
   1.142 -
   1.143 -Quilt manages a \emph{stack of patches} on top of a directory tree.
   1.144 -To begin, you tell quilt to manage a directory tree, and tell it which
   1.145 -files you want to manage; it stores away the names and contents of
   1.146 -those files.  To fix a bug, you create a new patch (using a single
   1.147 -command), edit the files you need to fix, then ``refresh'' the patch.
   1.148 -
   1.149 -The refresh step causes quilt to scan the directory tree; it updates
   1.150 -the patch with all of the changes you have made.  You can create
   1.151 -another patch on top of the first, which will track the changes
   1.152 -required to modify the tree from ``tree with one patch applied'' to
   1.153 -``tree with two patches applied''.
   1.154 -
   1.155 -You can \emph{change} which patches are applied to the tree.  If you
   1.156 -``pop'' a patch, the changes made by that patch will vanish from the
   1.157 -directory tree.  Quilt remembers which patches you have popped,
   1.158 -though, so you can ``push'' a popped patch again, and the directory
   1.159 -tree will be restored to contain the modifications in the patch.  Most
   1.160 -importantly, you can run the ``refresh'' command at any time, and the
   1.161 -topmost applied patch will be updated.  This means that you can, at
   1.162 -any time, change both which patches are applied and what
   1.163 -modifications those patches make.
   1.164 -
   1.165 -Quilt knows nothing about revision control tools, so it works equally
   1.166 -well on top of an unpacked tarball or a Subversion working copy.
   1.167 -
   1.168 -\subsection{From patchwork quilt to Mercurial Queues}
   1.169 +A comienzos del 2003, Andreas Gruenbacher y Martin Quinson tomaron la
   1.170 +aproximación de los guiones de Andrew y publicaron una herramienta
   1.171 +llamada
   1.172 +``patchwork quilt''~\cite{web:quilt}, o simplemente ``quilt''
   1.173 +(ver~\cite{gruenbacher:2005} el paper que lo describe).  Dado que
   1.174 +quilt automatizaba sustancialmente la administración de parches, fue
   1.175 +adoptado en gran medida por desarrolladores de programas abiertos.
   1.176 +
   1.177 +Quilt maneja una \emph{pila de parches} sobre un árbol de directorios.
   1.178 +Para comenzar, usted le indica a quilt que administre un árbol de
   1.179 +directorios, le indica qué archivos manejar; Este almacena los nombres
   1.180 +y los contenidos de estos archivos.  Para arreglar un fallo, usted
   1.181 +crea un nuevo parche(con una sola orden), edita los archivos que está
   1.182 +arreglando y ``refresca'' el parche.
   1.183 +
   1.184 +El paso de refresco hace que quilt revise el árbol de directorios;
   1.185 +actualiza el parche con todos los cambios que usted haya hecho.  Puede
   1.186 +crear otro parche sobre el primero, que hará seguimiento de los
   1.187 +cambios requeridos para modificar el árbol desde ``el árbol con un
   1.188 +parch aplicado'' a un ``árbol con dos parches aplicados''.
   1.189 +
   1.190 +Usted puede \emph{elegir} qué cambios desea aplicar al árbol.  Si
   1.191 +``pop''\ndt{saca} un parche, los cambios hechos por tal parchve
   1.192 +desapareceŕan del árbol de directorios.  Quilt recuerda qué parches ha
   1.193 +sacado, para que pueda ``introducirlos''\ndt{push} posteriormente, así el
   1.194 +árbol de directorios se restaurará con las modificaciones que vienen
   1.195 +del parche.  Lo más importante es que puede ejecutar la orden
   1.196 +``refresh'' en cualquier momento, y el último parche será
   1.197 +actualizado.  Esto significa que puede, en cualquier momento, cambiar
   1.198 +qué parches serán aplicados y qué modificaciones hacen ellos.
   1.199 +
   1.200 +Quilt no tiene nada que ver con herramientas de control de versiones,
   1.201 +y puede trabajar bien sobre un conjunto de fuentes que viene de un
   1.202 +archivo comprimido y empaquetado o una copia de trabajo de Subversion.
   1.203 +
   1.204 +\subsection{Pasar de trabajo con parches con Quilt hacia Colas de Mercurial}
   1.205  \label{sec:mq:quilt-mq}
   1.206  
   1.207 -In mid-2005, Chris Mason took the features of quilt and wrote an
   1.208 -extension that he called Mercurial Queues, which added quilt-like
   1.209 -behaviour to Mercurial.
   1.210 -
   1.211 -The key difference between quilt and MQ is that quilt knows nothing
   1.212 -about revision control systems, while MQ is \emph{integrated} into
   1.213 -Mercurial.  Each patch that you push is represented as a Mercurial
   1.214 -changeset.  Pop a patch, and the changeset goes away.
   1.215 -
   1.216 -Because quilt does not care about revision control tools, it is still
   1.217 -a tremendously useful piece of software to know about for situations
   1.218 -where you cannot use Mercurial and MQ.
   1.219 -
   1.220 -\section{The huge advantage of MQ}
   1.221 -
   1.222 -I cannot overstate the value that MQ offers through the unification of
   1.223 -patches and revision control.
   1.224 -
   1.225 -A major reason that patches have persisted in the free software and
   1.226 -open source world---in spite of the availability of increasingly
   1.227 -capable revision control tools over the years---is the \emph{agility}
   1.228 -they offer.  
   1.229 -
   1.230 -Traditional revision control tools make a permanent, irreversible
   1.231 -record of everything that you do.  While this has great value, it's
   1.232 -also somewhat stifling.  If you want to perform a wild-eyed
   1.233 -experiment, you have to be careful in how you go about it, or you risk
   1.234 -leaving unneeded---or worse, misleading or destabilising---traces of
   1.235 -your missteps and errors in the permanent revision record.
   1.236 -
   1.237 -By contrast, MQ's marriage of distributed revision control with
   1.238 -patches makes it much easier to isolate your work.  Your patches live
   1.239 -on top of normal revision history, and you can make them disappear or
   1.240 -reappear at will.  If you don't like a patch, you can drop it.  If a
   1.241 -patch isn't quite as you want it to be, simply fix it---as many times
   1.242 -as you need to, until you have refined it into the form you desire.
   1.243 -
   1.244 -As an example, the integration of patches with revision control makes
   1.245 -understanding patches and debugging their effects---and their
   1.246 -interplay with the code they're based on---\emph{enormously} easier.
   1.247 -Since every applied patch has an associated changeset, you can use
   1.248 -\hgcmdargs{log}{\emph{filename}} to see which changesets and patches
   1.249 -affected a file.  You can use the \hgext{bisect} command to
   1.250 -binary-search through all changesets and applied patches to see where
   1.251 -a bug got introduced or fixed.  You can use the \hgcmd{annotate}
   1.252 -command to see which changeset or patch modified a particular line of
   1.253 -a source file.  And so on.
   1.254 -
   1.255 -\section{Understanding patches}
   1.256 +A mediados de 2005, Chris Mason tomó las características de quilt y
   1.257 +escribió una extensión que llamó Colas de Mercurial\ndt{Mercurial
   1.258 +Queues}, que proporcionó un comportamiento a Mercurial al estilo
   1.259 +quilt.
   1.260 +
   1.261 +La diferencia clave entre quilt y MQ es que quilt no sabe nada acerca
   1.262 +del sistema de control de revisiones, mientras que MQ está
   1.263 +\emph{integrado} con Mercurial.  Cada parche que usted introduce se
   1.264 +representa como un conjunto de cambios en Mercurial.  Si sustrae un
   1.265 +parche, el conjunto de cambios desaparece.\ndt{introduce originalmente es
   1.266 +push y pop es sustraer en este contexto, usaremos el original en inglés
   1.267 +cuando encontremos que facilita la comprensión}
   1.268 +
   1.269 +Dado que quilt no se preocupa por las herramientas de control de
   1.270 +revisiones, continúa siendo una porción de software tremendamente útil
   1.271 +para aquellas situaciones en las cuales no puede usar Mercurial y MQ.
   1.272 +
   1.273 +\section{La gran ventaja de MQ}
   1.274 +
   1.275 +No puedo sobreestimar el valor que MQ ofrece en la unificación de
   1.276 +parches y el control de revisiones.
   1.277 +
   1.278 +La principal razón por la cual los parches han persistido en el mundo
   1.279 +del software libre y de fuentes abiertas--a pesar de la creciente
   1.280 +disponibilidad de herramientas poderosas de control de revisiones-- es
   1.281 +la \emph{agilidad} que ofrecen.
   1.282 +
   1.283 +Las herramientas tradicionales de control de revisiones llevan un
   1.284 +registro permanente e irreversible de todo lo que usted hace.  A pesar
   1.285 +de que esto tiene gran valor, también es bastante sutil.  Si requiere
   1.286 +realizar un experimento ((((wild-eyed)))), debe ser cuidadoso en cómo
   1.287 +lo hace, o puede dejar trazas innecesarias--o peor aún,
   1.288 +desconcertantes o desestabilizantes--- de los pasos y errores en el
   1.289 +registro de revisiones de forma permanente.
   1.290 +
   1.291 +En contraste, con la cohesión de MQ con el control de revisiones
   1.292 +distribuidos y los parches, resulta más sencillo aislar su trabajo.
   1.293 +Sus parches viven encima de la historia de revisiones normales, y
   1.294 +puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
   1.295 +no le gusta un parche, puede desecharlo.  Si un parche no satisface
   1.296 +todo lo que usted desea, puede arreglarlo---tantas veces como lo
   1.297 +requiera, hasta que lo haya refinado lo suficiente hacia sus
   1.298 +expectativas.
   1.299 +
   1.300 +Por ejemplo, la integración de parches con el control de revisiones
   1.301 +hace que el entender los parches y revisar sus efectos---y sus
   1.302 +interacciones con el código en el cuál están enlazados--- sea
   1.303 +\emph{mucho} más sencillo.  Dado que todo parche que se aplique tiene
   1.304 +un conjunto de cambios asociado, puede usar
   1.305 +\hgcmdargs{log}{\emph{filename}} para ver qué conjuntos de cambios y
   1.306 +parches afectaron un fichero.  Puede usar la orden \hgext{bisect} para
   1.307 +hacer una búsqueda binaria sobre todos los conjuntos de cambios y
   1.308 +parches aplicados para ver dónde se introdujo un fallo o dónde fue
   1.309 +arreglado.  Puede usar la orden \hgcmd{annotate} para ver qué
   1.310 +conjuntos de cambios o parches modificaron una línea particular de un
   1.311 +archivo fuente. Y mucho más.
   1.312 +
   1.313 +\section{Entender los parches}
   1.314  \label{sec:mq:patch}
   1.315  
   1.316 -Because MQ doesn't hide its patch-oriented nature, it is helpful to
   1.317 -understand what patches are, and a little about the tools that work
   1.318 -with them.
   1.319 -
   1.320 -The traditional Unix \command{diff} command compares two files, and
   1.321 -prints a list of differences between them. The \command{patch} command
   1.322 -understands these differences as \emph{modifications} to make to a
   1.323 -file.  Take a look at figure~\ref{ex:mq:diff} for a simple example of
   1.324 -these commands in action.
   1.325 +Dado que MQ no esconde su naturaleza parche-céntrica, es muy útil para
   1.326 +entender de qué se tratan los parches, y un poco acerca de las
   1.327 +herramientas que trabajan con ellos.
   1.328 +
   1.329 +La orden de Unix tradicional \command{diff} compara dos ficheros, e
   1.330 +imprime una lista de diferencias de sus líneas.  La orden
   1.331 +\command{patch} entiende esas diferencias como \emph{modificaciones}
   1.332 +para construir un fichero.  Vea en la figura~\ref{ex:mq:diff} un
   1.333 +ejemplo sencillo de tales órdenes en acción.
   1.334  
   1.335  \begin{figure}[ht]
   1.336    \interaction{mq.dodiff.diff}
   1.337 -  \caption{Simple uses of the \command{diff} and \command{patch} commands}
   1.338 +  \caption{Uso sencillo de las órdenes \command{diff} y \command{patch}}
   1.339    \label{ex:mq:diff}
   1.340  \end{figure}
   1.341  
   1.342 -The type of file that \command{diff} generates (and \command{patch}
   1.343 -takes as input) is called a ``patch'' or a ``diff''; there is no
   1.344 -difference between a patch and a diff.  (We'll use the term ``patch'',
   1.345 -since it's more commonly used.)
   1.346 -
   1.347 -A patch file can start with arbitrary text; the \command{patch}
   1.348 -command ignores this text, but MQ uses it as the commit message when
   1.349 -creating changesets.  To find the beginning of the patch content,
   1.350 -\command{patch} searches for the first line that starts with the
   1.351 -string ``\texttt{diff~-}''.
   1.352 -
   1.353 -MQ works with \emph{unified} diffs (\command{patch} can accept several
   1.354 -other diff formats, but MQ doesn't).  A unified diff contains two
   1.355 -kinds of header.  The \emph{file header} describes the file being
   1.356 -modified; it contains the name of the file to modify.  When
   1.357 -\command{patch} sees a new file header, it looks for a file with that
   1.358 -name to start modifying.
   1.359 -
   1.360 -After the file header comes a series of \emph{hunks}.  Each hunk
   1.361 -starts with a header; this identifies the range of line numbers within
   1.362 -the file that the hunk should modify.  Following the header, a hunk
   1.363 -starts and ends with a few (usually three) lines of text from the
   1.364 -unmodified file; these are called the \emph{context} for the hunk.  If
   1.365 -there's only a small amount of context between successive hunks,
   1.366 -\command{diff} doesn't print a new hunk header; it just runs the hunks
   1.367 -together, with a few lines of context between modifications.
   1.368 -
   1.369 -Each line of context begins with a space character.  Within the hunk,
   1.370 -a line that begins with ``\texttt{-}'' means ``remove this line,''
   1.371 -while a line that begins with ``\texttt{+}'' means ``insert this
   1.372 -line.''  For example, a line that is modified is represented by one
   1.373 -deletion and one insertion.
   1.374 -
   1.375 -We will return to some of the more subtle aspects of patches later (in
   1.376 -section~\ref{sec:mq:adv-patch}), but you should have enough information
   1.377 -now to use MQ.
   1.378 -
   1.379 -\section{Getting started with Mercurial Queues}
   1.380 +El tipo de fichero que \command{diff} genera (y que \command{patch}
   1.381 +toma como entrada) se llama un ``parche'' o un ``diff''; no hay
   1.382 +diferencia entre un parche y un diff.  (Usaremos el término ``parche'',
   1.383 +dado que es el que más comunmente se usa.)
   1.384 +
   1.385 +Un parche puede comenzar con un texto arbitrario; la orden \command{patch}
   1.386 +ignora este texto, pero MQ lo usa como el mensaje de consignación
   1.387 +cuando se crean conjuntos de cambios.  Para encontrar el inicio del
   1.388 +contenido de un parche, la orden \command{patch} busca la primera
   1.389 +línea que comience con la cadena ``\texttt{diff~-}''.
   1.390 +
   1.391 +MQ trabaja con diffs \emph{unificados} (\command{patch} acepta varios
   1.392 +formatos de diff adicionales, pero MQ no).  Un diff unificado contiene
   1.393 +dos clases de encabezados.  El \emph{encabezado de fichero} describe
   1.394 +el fichero que se está modificando; contiene el nombre del fichero a
   1.395 +modificar.  Cuando \command{patch} ve un nuevo encabezado de fichero,
   1.396 +busca un fichero con ese nombre para modificarlo.
   1.397 +
   1.398 +Después del encabezaado vienen varios \emph{trozos}.  Cada trozo
   1.399 +comienza con un encabezado; que identifica el rango de líneas del
   1.400 +fichero que el trozo debe modificar.  Después del encabezado, un trozo
   1.401 +comienza y termina con unas pocas líneas(usualmente tres) de texto del
   1.402 +fichero que no han sido modificadas; las cuales llamamos el
   1.403 +\emph{contexto} del trozo.  Si solamente hay una pequeña cantidad de
   1.404 +contexto entre trozos sucesivos, \command{diff} no imprime un nuevo
   1.405 +encabezado para el trozo, continua integrando los trozos, con unas
   1.406 +líneas de contexto entre las modificaciones.
   1.407 +
   1.408 +Cada línea de contexto comienza con un caracter de espacio.  En el
   1.409 +trozo, si una línea comienza con ``\texttt{-}'' significa ``elimine
   1.410 +esta línea'', si la línea comienza con un ``\texttt{+}'' significa
   1.411 +``inserte esta línea''.  Por ejemplo, una línea que se modifica se
   1.412 +representa con una línea eliminada y una línea insertada.
   1.413 +
   1.414 +Retomaremos aspectos más sutiles acerca de parches posteriormente(en
   1.415 +la sección~\ref{sec:mq:adv-patch}), pero en el momento usted ya
   1.416 +debería tener suficiente información para usar MQ.
   1.417 +
   1.418 +\section{Comenzar a usar Colas de Mercurial}
   1.419  \label{sec:mq:start}
   1.420  
   1.421 -Because MQ is implemented as an extension, you must explicitly enable
   1.422 -before you can use it.  (You don't need to download anything; MQ ships
   1.423 -with the standard Mercurial distribution.)  To enable MQ, edit your
   1.424 -\tildefile{.hgrc} file, and add the lines in figure~\ref{ex:mq:config}.
   1.425 +Dado que MQ está implementado como una extensión, debe habilitarla
   1.426 +explícitamente antes de comenzar a usarla.  (No necesita descargar
   1.427 +nada; MQ viene con la distribución estándar de Mercurial.)  Para
   1.428 +habilitar MQ, edite su fichero \tildefile{.hgrc}, y añada las líneas
   1.429 +de la figura~\ref{ex:mq:config}.
   1.430  
   1.431  \begin{figure}[ht]
   1.432    \begin{codesample4}
   1.433 @@ -222,172 +239,182 @@
   1.434      hgext.mq =
   1.435    \end{codesample4}
   1.436    \label{ex:mq:config}
   1.437 -  \caption{Contents to add to \tildefile{.hgrc} to enable the MQ extension}
   1.438 -\end{figure}
   1.439 -
   1.440 -Once the extension is enabled, it will make a number of new commands
   1.441 -available.  To verify that the extension is working, you can use
   1.442 -\hgcmd{help} to see if the \hgxcmd{mq}{qinit} command is now available; see
   1.443 -the example in figure~\ref{ex:mq:enabled}.
   1.444 +  \caption{Líneas a añadir en \tildefile{.hgrc} para habilitar la extensión MQ}
   1.445 +\end{figure}
   1.446 +
   1.447 +Cuando la extensión esté habilitada, aparecerán varios comandos.  Para
   1.448 +verificar que la extensión está trabajando, puede usar \hgcmd{help}
   1.449 +para ver si la orden \hgxcmd{mq}{qinit} está disponible; vea un
   1.450 +ejemplo en la figura~\ref{ex:mq:enabled}.
   1.451  
   1.452  \begin{figure}[ht]
   1.453    \interaction{mq.qinit-help.help}
   1.454 -  \caption{How to verify that MQ is enabled}
   1.455 +  \caption{Cómo verificar que MQ está habilitado}
   1.456    \label{ex:mq:enabled}
   1.457  \end{figure}
   1.458  
   1.459 -You can use MQ with \emph{any} Mercurial repository, and its commands
   1.460 -only operate within that repository.  To get started, simply prepare
   1.461 -the repository using the \hgxcmd{mq}{qinit} command (see
   1.462 -figure~\ref{ex:mq:qinit}).  This command creates an empty directory
   1.463 -called \sdirname{.hg/patches}, where MQ will keep its metadata.  As
   1.464 -with many Mercurial commands, the \hgxcmd{mq}{qinit} command prints nothing
   1.465 -if it succeeds.
   1.466 +Puede usar MQ en \emph{cualquier} repositorio de Mercurial, y sus
   1.467 +comandos solamente operarán con tal repositorio.  Para comenzar, basta
   1.468 +con preparar el repositorio con la orden \hgxcmd{mq}{qinit}(ver la
   1.469 +figura~\ref{ex:mq:qinit}).  Esta orden crea un directorio vacío
   1.470 +llamado \sdirname{.hg/patches}, donde MQ mantendrá sus metadatos. Como
   1.471 +otras ordenes de Mercurial, la orden \hgxcmd{mq}{qinit} no imprime
   1.472 +nada cuando es exitosa.
   1.473  
   1.474  \begin{figure}[ht]
   1.475    \interaction{mq.tutorial.qinit}
   1.476 -  \caption{Preparing a repository for use with MQ}
   1.477 +  \caption{Preparar un repositorio para usar MQ}
   1.478    \label{ex:mq:qinit}
   1.479  \end{figure}
   1.480  
   1.481  \begin{figure}[ht]
   1.482    \interaction{mq.tutorial.qnew}
   1.483 -  \caption{Creating a new patch}
   1.484 +  \caption{Crear un nuevo parche}
   1.485    \label{ex:mq:qnew}
   1.486  \end{figure}
   1.487  
   1.488 -\subsection{Creating a new patch}
   1.489 -
   1.490 -To begin work on a new patch, use the \hgxcmd{mq}{qnew} command.  This
   1.491 -command takes one argument, the name of the patch to create.  MQ will
   1.492 -use this as the name of an actual file in the \sdirname{.hg/patches}
   1.493 -directory, as you can see in figure~\ref{ex:mq:qnew}.
   1.494 -
   1.495 -Also newly present in the \sdirname{.hg/patches} directory are two
   1.496 -other files, \sfilename{series} and \sfilename{status}.  The
   1.497 -\sfilename{series} file lists all of the patches that MQ knows about
   1.498 -for this repository, with one patch per line.  Mercurial uses the
   1.499 -\sfilename{status} file for internal book-keeping; it tracks all of the
   1.500 -patches that MQ has \emph{applied} in this repository.
   1.501 +\subsection{Crear un nuevo parche}
   1.502 +
   1.503 +Para comenzar a trabajar en un nuevo parche use la orden
   1.504 +\hgxcmd{mq}{qnew}. Esta orden recibe un argumento, el nombre del
   1.505 +parche a crear.  MQ lo usará como el nombre del fichero en el
   1.506 +directorio \sdirname{.hg/patches}, como puede apreciarlo en la
   1.507 +figura~\ref{ex:mq:qnew}.
   1.508 +
   1.509 +También hay otros dos nuevos ficheros en el directorio
   1.510 +\sdirname{.hg/patches}:  \sfilename{series} y \sfilename{status}.  El
   1.511 +fichero \sfilename{series} lista todos los parches de los cuales MQ
   1.512 +tiene noticia para este repositorio, con un parche por línea.
   1.513 +Mercurial usa el fichero \sfilename{status} para mantener registros
   1.514 +interns; da seguimiento a todos los parches que MQ ha \emph{aplicado}
   1.515 +en el repositorio.
   1.516  
   1.517  \begin{note}
   1.518 -  You may sometimes want to edit the \sfilename{series} file by hand;
   1.519 -  for example, to change the sequence in which some patches are
   1.520 -  applied.  However, manually editing the \sfilename{status} file is
   1.521 -  almost always a bad idea, as it's easy to corrupt MQ's idea of what
   1.522 -  is happening.
   1.523 +  En ciertas ocasiones usted querrá editar el fichero
   1.524 +  \sfilename{series} a mano; por ejemplo, cambiar el orden en que se
   1.525 +  aplican ciertos parches.  A pesar de esto, es una mala idea editar
   1.526 +  manualmente  el fichero \sfilename{status}, dado que es fácil
   1.527 +  desorientar a MQ acerca de lo que está pasando.
   1.528  \end{note}
   1.529  
   1.530 -Once you have created your new patch, you can edit files in the
   1.531 -working directory as you usually would.  All of the normal Mercurial
   1.532 -commands, such as \hgcmd{diff} and \hgcmd{annotate}, work exactly as
   1.533 -they did before.
   1.534 -
   1.535 -\subsection{Refreshing a patch}
   1.536 -
   1.537 -When you reach a point where you want to save your work, use the
   1.538 -\hgxcmd{mq}{qrefresh} command (figure~\ref{ex:mq:qnew}) to update the patch
   1.539 -you are working on.  This command folds the changes you have made in
   1.540 -the working directory into your patch, and updates its corresponding
   1.541 -changeset to contain those changes.
   1.542 +Una vez que haya creado un nuevo parche, puede editar los ficheros en
   1.543 +el directorio de trabajo, como lo haría usualmente.  Toda las órdenes
   1.544 +que de a Mercurial, tales como \hgcmd{diff} y \hgcmd{annotate},
   1.545 +trabajarán de la misma forma como lo han hecho antes.
   1.546 +
   1.547 +\subsection{Refrescar un parche}
   1.548 +
   1.549 +Cuando usted llega a un punto en el cual desea guardar su trabajo, use
   1.550 +la orden \hgxcmd{mq}{qrefresh}(figura~\ref{ex:mq:qnew}) para
   1.551 +actualizar el parche en el cual está trabajando.  Esta orden almacena
   1.552 +los cambios que haya hecho al directorio actual de trabajo en su
   1.553 +parche, y almacena el conjunto de cambios correspondiente que contiene
   1.554 +los cambios.
   1.555  
   1.556  \begin{figure}[ht]
   1.557    \interaction{mq.tutorial.qrefresh}
   1.558 -  \caption{Refreshing a patch}
   1.559 +  \caption{Refrescar un parche}
   1.560    \label{ex:mq:qrefresh}
   1.561  \end{figure}
   1.562  
   1.563 -You can run \hgxcmd{mq}{qrefresh} as often as you like, so it's a good way
   1.564 -to ``checkpoint'' your work.  Refresh your patch at an opportune
   1.565 -time; try an experiment; and if the experiment doesn't work out,
   1.566 -\hgcmd{revert} your modifications back to the last time you refreshed.
   1.567 +Puede ejecutar la orden \hgxcmd{mq}{qrefresh} tan seguido como quiera,
   1.568 +y es una buena forma de ``colocar marcas'' a su trabajo.  Refresque su
   1.569 +parche en momentos oportunos; intente un experimento; si el
   1.570 +experimento no funciona, Use \hgcmd{revert} sobre sus modificaciones
   1.571 +para volver al refresco anterior.
   1.572  
   1.573  \begin{figure}[ht]
   1.574    \interaction{mq.tutorial.qrefresh2}
   1.575 -  \caption{Refresh a patch many times to accumulate changes}
   1.576 +  \caption{Refrescar un parche muchas veces para acumular cambios}
   1.577    \label{ex:mq:qrefresh2}
   1.578  \end{figure}
   1.579  
   1.580 -\subsection{Stacking and tracking patches}
   1.581 -
   1.582 -Once you have finished working on a patch, or need to work on another,
   1.583 -you can use the \hgxcmd{mq}{qnew} command again to create a new patch.
   1.584 -Mercurial will apply this patch on top of your existing patch.  See
   1.585 -figure~\ref{ex:mq:qnew2} for an example.  Notice that the patch
   1.586 -contains the changes in our prior patch as part of its context (you
   1.587 -can see this more clearly in the output of \hgcmd{annotate}).
   1.588 +\subsection{Aplicar un parche tras otro y dar seguimiento}
   1.589 +
   1.590 +Cuando haya terminado de trabajar en un parche, o necesite trabajar en
   1.591 +otro, puede usar la orden \hgxcmd{mq}{qnew} para crear un nuevo
   1.592 +parche.  Mercurial aplicará este parche sobre su parche anterior.
   1.593 +Para un ejemplo, ver la figura~\ref{ex:mq:qnew2}.  Note que el parche
   1.594 +contiene los cambios en nuestro parche anterior como parte de su
   1.595 +contexto( lo verá más claramente en la salida de \hgcmd{annotate}).
   1.596  
   1.597  \begin{figure}[ht]
   1.598    \interaction{mq.tutorial.qnew2}
   1.599 -  \caption{Stacking a second patch on top of the first}
   1.600 +  \caption{Aplicar un parche después del primero}
   1.601    \label{ex:mq:qnew2}
   1.602  \end{figure}
   1.603  
   1.604 -So far, with the exception of \hgxcmd{mq}{qnew} and \hgxcmd{mq}{qrefresh}, we've
   1.605 -been careful to only use regular Mercurial commands.  However, MQ
   1.606 -provides many commands that are easier to use when you are thinking
   1.607 -about patches, as illustrated in figure~\ref{ex:mq:qseries}:
   1.608 +Hasta ahora, con excepción de \hgxcmd{mq}{qnew} y
   1.609 +\hgxcmd{mq}{qrefresh}, hemos sido cuidadosos para aplicar únicamente
   1.610 +órdenes usuaales de Mercurial.  De todas maneras, MQ ofrece muchos
   1.611 +comandos que son más sencillos de usar cuando esté pensando acerca de
   1.612 +parches, como se puede ver en la figura~\ref{ex:mq:qseries}:
   1.613  
   1.614  \begin{itemize}
   1.615 -\item The \hgxcmd{mq}{qseries} command lists every patch that MQ knows
   1.616 -  about in this repository, from oldest to newest (most recently
   1.617 -  \emph{created}).
   1.618 -\item The \hgxcmd{mq}{qapplied} command lists every patch that MQ has
   1.619 -  \emph{applied} in this repository, again from oldest to newest (most
   1.620 -  recently applied).
   1.621 +\item La orden \hgxcmd{mq}{qseries} lista cada parche del cual MQ
   1.622 +  tiene noticia en este repositorio, desde el más antiguo hasta el más
   1.623 +  nuevo(El último \emph{creado}).
   1.624 +\item La orden \hgxcmd{mq}{qapplied} lista cada parche que MQ haya
   1.625 +  \emph{aplicado} en este repositorio, de nuevo, desde el más antiguo
   1.626 +  hasta el más nuevo (El aplicado más recientemente).
   1.627  \end{itemize}
   1.628  
   1.629  \begin{figure}[ht]
   1.630    \interaction{mq.tutorial.qseries}
   1.631 -  \caption{Understanding the patch stack with \hgxcmd{mq}{qseries} and
   1.632 +  \caption{Entender la pila de parches con \hgxcmd{mq}{qseries} y
   1.633      \hgxcmd{mq}{qapplied}}
   1.634    \label{ex:mq:qseries}
   1.635  \end{figure}
   1.636  
   1.637 -\subsection{Manipulating the patch stack}
   1.638 -
   1.639 -The previous discussion implied that there must be a difference
   1.640 -between ``known'' and ``applied'' patches, and there is.  MQ can
   1.641 -manage a patch without it being applied in the repository.
   1.642 -
   1.643 -An \emph{applied} patch has a corresponding changeset in the
   1.644 -repository, and the effects of the patch and changeset are visible in
   1.645 -the working directory.  You can undo the application of a patch using
   1.646 -the \hgxcmd{mq}{qpop} command.  MQ still \emph{knows about}, or manages, a
   1.647 -popped patch, but the patch no longer has a corresponding changeset in
   1.648 -the repository, and the working directory does not contain the changes
   1.649 -made by the patch.  Figure~\ref{fig:mq:stack} illustrates the
   1.650 -difference between applied and tracked patches.
   1.651 +\subsection{Manipular la pila de parches}
   1.652 +
   1.653 +La discusión previa indicó que debe haber una diferencia entre los
   1.654 +parches ``conocidos'' y ``aplicados'', y efectivamente la hay.  MQ
   1.655 +puede manejar un parche sin que este haya sido aplicado al
   1.656 +repositorio.
   1.657 +
   1.658 +Un parche \emph{aplicado} tiene su correspondiente conjunto de cambios
   1.659 +en el repositorio, y los efectos del parche y el conjunto de cambios
   1.660 +son visibles en el directorio de trabajo.  Puede deshacer la
   1.661 +aplicación de un parche con la orden \hgxcmd{mq}{qpop}.  MQ 
   1.662 +\emph{sabe acerca de}, o maneja un parche sustraído, pero el parche ya
   1.663 +no tendrá un conjunto de cambios correspondientes en el repositorio, y
   1.664 +el directorio de trabajo no contendrá los cambios hechos por el
   1.665 +parche.  La figura~\ref{fig:mq:stack} ilustra la diferencia entre
   1.666 +parches aplicados y seguidos.
   1.667  
   1.668  \begin{figure}[ht]
   1.669    \centering
   1.670    \grafix{mq-stack}
   1.671 -  \caption{Applied and unapplied patches in the MQ patch stack}
   1.672 +  \caption{Parches aplicados y no aplicados en la pila de parches de MQ}
   1.673    \label{fig:mq:stack}
   1.674  \end{figure}
   1.675  
   1.676 -You can reapply an unapplied, or popped, patch using the \hgxcmd{mq}{qpush}
   1.677 -command.  This creates a new changeset to correspond to the patch, and
   1.678 -the patch's changes once again become present in the working
   1.679 -directory.  See figure~\ref{ex:mq:qpop} for examples of \hgxcmd{mq}{qpop}
   1.680 -and \hgxcmd{mq}{qpush} in action.  Notice that once we have popped a patch
   1.681 -or two patches, the output of \hgxcmd{mq}{qseries} remains the same, while
   1.682 -that of \hgxcmd{mq}{qapplied} has changed.
   1.683 +Puede reaplicar un parche no aplicado o sustraído con la orden
   1.684 +\hgxcmd{mq}{qpush}.  Esto crea un nuevo conjunto de cambios
   1.685 +correspondiente al parche, y los cambios del parche estarán presentes
   1.686 +de nuevo en el directorio de trabajo.  Vea ejemplos de
   1.687 +\hgxcmd{mq}{qpop} y \hgxcmd{mq}{qpush} en acción en la
   1.688 +figura~\ref{ex:mq:qpop}.  Vea que hemos sustraído uno o dos parches,
   1.689 +la salida de\hgxcmd{mq}{qseries} continúa igual, mientras que
   1.690 +\hgxcmd{mq}{qapplied} ha  cambiado.
   1.691  
   1.692  \begin{figure}[ht]
   1.693    \interaction{mq.tutorial.qpop}
   1.694 -  \caption{Modifying the stack of applied patches}
   1.695 +  \caption{Modificar la pila de parches aplicados}
   1.696    \label{ex:mq:qpop}
   1.697  \end{figure}
   1.698  
   1.699 -\subsection{Pushing and popping many patches}
   1.700 -
   1.701 -While \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} each operate on a single patch at
   1.702 -a time by default, you can push and pop many patches in one go.  The
   1.703 -\hgxopt{mq}{qpush}{-a} option to \hgxcmd{mq}{qpush} causes it to push all
   1.704 -unapplied patches, while the \hgxopt{mq}{qpop}{-a} option to \hgxcmd{mq}{qpop}
   1.705 -causes it to pop all applied patches.  (For some more ways to push and
   1.706 -pop many patches, see section~\ref{sec:mq:perf} below.)
   1.707 +\subsection{Introducir y sustraer muchos parches}
   1.708 +
   1.709 +Mientras que \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} operan sobre un
   1.710 +único parche cada vez, puede introducir y sustraer varios parches de
   1.711 +una vez.  La opción \hgxopt{mq}{qpush}{-a} de \hgxcmd{mq}{qpush}
   1.712 +introduce todos los cambios que no hayan sido aplicados, mientras que
   1.713 +la opción \hgxopt{mq}{qpop}{-a} de \hgxcmd{mq}{qpop} sustrae todos los
   1.714 +cambios aplicados.  (Vea la sección~\ref{sec:mq:perf} más adelante
   1.715 +en la cual se explican otras formas de de introducir y sustraer varios
   1.716 +cambios.)
   1.717  
   1.718  \begin{figure}[ht]
   1.719    \interaction{mq.tutorial.qpush-a}
   1.720 @@ -395,48 +422,53 @@
   1.721    \label{ex:mq:qpush-a}
   1.722  \end{figure}
   1.723  
   1.724 -\subsection{Safety checks, and overriding them}
   1.725 -
   1.726 -Several MQ commands check the working directory before they do
   1.727 -anything, and fail if they find any modifications.  They do this to
   1.728 -ensure that you won't lose any changes that you have made, but not yet
   1.729 -incorporated into a patch.  Figure~\ref{ex:mq:add} illustrates this;
   1.730 -the \hgxcmd{mq}{qnew} command will not create a new patch if there are
   1.731 -outstanding changes, caused in this case by the \hgcmd{add} of
   1.732 -\filename{file3}.
   1.733 +\subsection{Medidas de seguridad y cómo saltarlas}
   1.734 +
   1.735 +Muchas órdenes MQ revisan el directorio de trabajo antes de hacer
   1.736 +cualquier cosa, y fallan si encuentran alguna modificación.  Lo hacen
   1.737 +para garantizar que usted no pierda cambio alguno de los que haya
   1.738 +hecho, pero que no hayan sido incorporados en algún parche.  La
   1.739 +figura~\ref{ex:mq:add} ilusta esto; la orden \hgxcmd{mq}{qnew} no
   1.740 +creará un nuevo parche si hay cambios notorios, causados en este caso
   1.741 +por aplicado la orden \hgcmd{add} a \filename{file3}.
   1.742  
   1.743  \begin{figure}[ht]
   1.744    \interaction{mq.tutorial.add}
   1.745 -  \caption{Forcibly creating a patch}
   1.746 +  \caption{Crear un parche a la fuerza}
   1.747    \label{ex:mq:add}
   1.748  \end{figure}
   1.749  
   1.750 -Commands that check the working directory all take an ``I know what
   1.751 -I'm doing'' option, which is always named \option{-f}.  The exact
   1.752 -meaning of \option{-f} depends on the command.  For example,
   1.753 -\hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}} will incorporate any outstanding
   1.754 -changes into the new patch it creates, but
   1.755 -\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} will revert modifications to any
   1.756 -files affected by the patch that it is popping.  Be sure to read the
   1.757 -documentation for a command's \option{-f} option before you use it!
   1.758 -
   1.759 -\subsection{Working on several patches at once}
   1.760 -
   1.761 -The \hgxcmd{mq}{qrefresh} command always refreshes the \emph{topmost}
   1.762 -applied patch.  This means that you can suspend work on one patch (by
   1.763 -refreshing it), pop or push to make a different patch the top, and
   1.764 -work on \emph{that} patch for a while.
   1.765 -
   1.766 -Here's an example that illustrates how you can use this ability.
   1.767 -Let's say you're developing a new feature as two patches.  The first
   1.768 -is a change to the core of your software, and the second---layered on
   1.769 -top of the first---changes the user interface to use the code you just
   1.770 -added to the core.  If you notice a bug in the core while you're
   1.771 -working on the UI patch, it's easy to fix the core.  Simply
   1.772 -\hgxcmd{mq}{qrefresh} the UI patch to save your in-progress changes, and
   1.773 -\hgxcmd{mq}{qpop} down to the core patch.  Fix the core bug,
   1.774 -\hgxcmd{mq}{qrefresh} the core patch, and \hgxcmd{mq}{qpush} back to the UI
   1.775 -patch to continue where you left off.
   1.776 +Las órdenes que revisan el directorio actual cuentan con una opción
   1.777 +``Se lo que estoy haciendo'', que siempre está nombrada como
   1.778 +\option{-f}.  El significado exacto de \option{-f} depende de la
   1.779 +orden.  Por ejemplo, \hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}}
   1.780 +incorporarán cualquier cambio notorio en el nuevo parche que crea pero
   1.781 +\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} revertirá las modificaciones a
   1.782 +cualquier fichero que haya sido afectado por el parche que está siendo
   1.783 +sustraído. ¡Asegúrese de leer la documentación de la opción \option{-f}
   1.784 +de cada comando antes de usarla!
   1.785 +
   1.786 +\subsection{Trabajar con varios parches a la vez}
   1.787 +
   1.788 +La orden \hgxcmd{mq}{qrefresh} siempre refresca el \emph{último}
   1.789 +parche aplicado.  Esto significa que usted puede suspender su trabajo
   1.790 +en un parche (refrescándolo), sustraerlo o introducirlo para lograr
   1.791 +que otro parche esté de último y trabajar en \emph{ese} parche por un
   1.792 +rato.
   1.793 +
   1.794 +A continuación un ejemplo que ilustra cómo puede usar esta habilidad.
   1.795 +Digamos que está desarrollando una nueva característica en dos
   1.796 +parches.  El primero es un cambio en la parte fundamental de su
   1.797 +programa, y el segundo--sobre el primero---cambia la interfaz de
   1.798 +usuario para usar el código que ha añadido a la parte fundamental.  Si
   1.799 +ve que hay un fallo en la parte fundamental mientras está trabajando
   1.800 +en el parche de UI\ndt{Interfaz de Usuario, User Interface en inglés}, es fácil arreglar la parte fundamental.
   1.801 +Simplemente use \hgxcmd{mq}{qrefresh} sobre el parche de la UI para
   1.802 +guardar los cambios de su trabajo en progreso, y use \hgxcmd{mq}{qpop}
   1.803 +para sacar sustraer el parche de la parte fundamental.  Arregla el
   1.804 +fallo sobre la parte fundamental, aplique \hgxcmd{mq}{qrefresh} sobre
   1.805 +el parche fundamental, y aplique \hgxcmd{mq}{qpush} sobre el parche de
   1.806 +UI para continuar donde había quedado.
   1.807  
   1.808  \section{More about patches}
   1.809  \label{sec:mq:adv-patch}