hgbook
diff es/mq.tex @ 443:2daeda01fe98
Started mq, please do look the translation terms about push and pop on this context
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Sun Dec 07 17:47:38 2008 -0500 (2008-12-07) |
parents | aeda195f54a6 |
children | da4d34e0e250 |
line diff
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}