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