hgbook
annotate es/mq.tex @ 1114:527b86d55d4a
inotify: update installation information
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
author | Nicolas Dumazet <nicdumz.commits@gmail.com> |
---|---|
date | Sun Dec 13 16:35:56 2009 +0900 (2009-12-13) |
parents | 4af39acbb3cf |
children |
rev | line source |
---|---|
igor@440 | 1 \chapter{Administración de cambios con Colas de Mercurial} |
jerojasro@336 | 2 \label{chap:mq} |
jerojasro@336 | 3 |
igor@440 | 4 \section{El problema de la administración de parches} |
jerojasro@336 | 5 \label{sec:mq:patch-mgmt} |
jerojasro@336 | 6 |
igor@443 | 7 Un escenario frecuente: usted necesita instalar un paquete de software |
igor@443 | 8 desde las fuentes, pero encuentra un fallo que debe arreglar antes de |
igor@443 | 9 poder comenzar a usarlo. Hace sus cambios, y se olvida del paquete |
igor@443 | 10 por un tiempo, unos meses después necesita actualizar a una nueva |
igor@443 | 11 versión del paquete. Si la nueva versión del paquete todavía tiene el |
igor@443 | 12 fallo, debe extraer su arreglo del árbol de fuentes anteriores y |
igor@443 | 13 aplicarlo a la nueva versión. Una tarea tediosa en la cual es fácil |
igor@443 | 14 equivocarse. |
igor@443 | 15 |
igor@443 | 16 Este es un caso simple del problema del ``manejo de parches''. Usted |
igor@443 | 17 tiene un árbol de fuentes del ``mantenedor principal'' que no puede |
igor@443 | 18 cambiar: necesita hacer algunos cambios locales sobre el árbol |
igor@443 | 19 principal; y desearía poder mantener tales cambios separados, de forma |
igor@443 | 20 tal que pueda aplicarlos a versiones más nuevas del árbol principal. |
igor@443 | 21 |
igor@443 | 22 El problema de administración de parches surge en muchas situaciones. |
igor@443 | 23 Probablemente la más visible es cuando un usuario de un proyecto de |
igor@443 | 24 software de fuentes abiertas contribuye con un arreglo de un fallo o |
igor@443 | 25 una nueva característica a los mantenedores del proyecto en la forma |
igor@443 | 26 de un parche. |
igor@443 | 27 |
igor@443 | 28 Aquellos que distribuyen sistemas operativos que incluyen programas |
igor@443 | 29 abiertos usualmente requieren hacer cambios en los paquetes que |
igor@443 | 30 distribuyen de tal forma que se armen apropiadamente en sus ambientes. |
igor@443 | 31 |
igor@443 | 32 Cuando hay pocos cambios por mantener, es muy sencillo administrar un |
igor@443 | 33 solo parche con los programas estándar \command{diff} y |
jerojasro@480 | 34 \command{patch} (ver la sección~\ref{sec:mq:patch} para ver cómo |
igor@443 | 35 emplear tales herramientas). Cuando la cantidad de cambios comienza a |
igor@443 | 36 crecer, tiene sentido mantener parches como ``porciones de trabajo'' |
igor@443 | 37 individual, de forma que cada cambio contiene solamente un arreglo de |
jerojasro@480 | 38 un fallo (el parche puede modificar varios ficheros, pero está |
igor@443 | 39 ``haciendo una sola cosa''), y puede tener cierta cantidad de tales |
igor@443 | 40 parches para diferentes fallos y cambios locales. En esta situación, |
igor@443 | 41 si envía un parche que arregla un fallo a los mantenedores principales |
igor@443 | 42 de un paquete y ellos incluyen su arreglo en una publicación |
igor@443 | 43 posterior, puede deshacerse de tal parche cuando se actualice a la |
igor@443 | 44 nueva versión. |
igor@443 | 45 |
igor@443 | 46 Mantener un solo parche frente a un árbol principal es algo tedioso y |
igor@443 | 47 es fácil equivocarse, pero no es difícil. Aunque, la complejidad del |
igor@443 | 48 problema crece rápidamente a medida que la cantidad de parches que |
igor@443 | 49 tiene que mantener crece. Con más que una pequeña cantidad de |
igor@443 | 50 cambios, entender cuáles ha aplicado se convierte de algo desordenado |
igor@443 | 51 a algo avasallante. |
igor@443 | 52 |
igor@443 | 53 Afortunadamente Mercurial provee una extensión poderos: Colas de |
jerojasro@480 | 54 Mercurial (o simplemente ``MQ''), que simplifica en gran medida el |
igor@443 | 55 problema de administración de parches. |
igor@443 | 56 |
igor@443 | 57 \section{La prehistoria de las Colas de Mercurial} |
jerojasro@336 | 58 \label{sec:mq:history} |
jerojasro@336 | 59 |
igor@443 | 60 A finales de los 90s, muchos desarrolladores del núcleo de Linux |
igor@443 | 61 comenzaron a mantener ``series de parches'' que modificaron el |
igor@443 | 62 comportamiento del núcleo de Linux. Algunos se enfocaban en |
igor@443 | 63 estabilidad, otros en aumentar las características, y otros un poco |
igor@443 | 64 más especulativos. |
igor@443 | 65 |
igor@443 | 66 Los tamaños de las series de parches crecieron rápidamente. En el |
igor@443 | 67 2002, Andrew Morton publicó algunos guiones de línea de órdenes que |
igor@443 | 68 estuvo usando para automatizar la tarea de administrar su cola de |
igor@443 | 69 parches. Andrew usó exitósamente tales guiones para administrar |
jerojasro@480 | 70 centenas (a veces millares) de parches en el núcleo de Linux. |
igor@443 | 71 |
igor@443 | 72 \subsection{Trabajar parches con quilt} |
jerojasro@336 | 73 \label{sec:mq:quilt} |
jerojasro@336 | 74 |
igor@443 | 75 A comienzos del 2003, Andreas Gruenbacher y Martin Quinson tomaron la |
igor@443 | 76 aproximación de los guiones de Andrew y publicaron una herramienta |
igor@443 | 77 llamada |
igor@443 | 78 ``patchwork quilt''~\cite{web:quilt}, o simplemente ``quilt'' |
igor@443 | 79 (ver~\cite{gruenbacher:2005} el paper que lo describe). Dado que |
igor@443 | 80 quilt automatizaba sustancialmente la administración de parches, fue |
igor@443 | 81 adoptado en gran medida por desarrolladores de programas abiertos. |
igor@443 | 82 |
igor@443 | 83 Quilt maneja una \emph{pila de parches} sobre un árbol de directorios. |
igor@443 | 84 Para comenzar, usted le indica a quilt que administre un árbol de |
igor@449 | 85 directorios, le indica qué ficheros manejar; Este almacena los nombres |
igor@449 | 86 y los contenidos de estos ficheros. Para arreglar un fallo, usted |
jerojasro@480 | 87 crea un nuevo parche (con una sola orden), edita los ficheros que está |
igor@443 | 88 arreglando y ``refresca'' el parche. |
igor@443 | 89 |
igor@443 | 90 El paso de refresco hace que quilt revise el árbol de directorios; |
igor@443 | 91 actualiza el parche con todos los cambios que usted haya hecho. Puede |
igor@443 | 92 crear otro parche sobre el primero, que hará seguimiento de los |
igor@443 | 93 cambios requeridos para modificar el árbol desde ``el árbol con un |
igor@443 | 94 parch aplicado'' a un ``árbol con dos parches aplicados''. |
igor@443 | 95 |
igor@443 | 96 Usted puede \emph{elegir} qué cambios desea aplicar al árbol. Si |
igor@443 | 97 ``pop''\ndt{saca} un parche, los cambios hechos por tal parchve |
igor@443 | 98 desapareceŕan del árbol de directorios. Quilt recuerda qué parches ha |
igor@443 | 99 sacado, para que pueda ``introducirlos''\ndt{push} posteriormente, así el |
igor@443 | 100 árbol de directorios se restaurará con las modificaciones que vienen |
igor@443 | 101 del parche. Lo más importante es que puede ejecutar la orden |
igor@443 | 102 ``refresh'' en cualquier momento, y el último parche será |
igor@443 | 103 actualizado. Esto significa que puede, en cualquier momento, cambiar |
igor@443 | 104 qué parches serán aplicados y qué modificaciones hacen ellos. |
igor@443 | 105 |
igor@443 | 106 Quilt no tiene nada que ver con herramientas de control de versiones, |
igor@443 | 107 y puede trabajar bien sobre un conjunto de fuentes que viene de un |
igor@449 | 108 fichero comprimido y empaquetado o una copia de trabajo de Subversion. |
igor@443 | 109 |
igor@443 | 110 \subsection{Pasar de trabajo con parches con Quilt hacia Colas de Mercurial} |
jerojasro@336 | 111 \label{sec:mq:quilt-mq} |
jerojasro@336 | 112 |
igor@443 | 113 A mediados de 2005, Chris Mason tomó las características de quilt y |
igor@443 | 114 escribió una extensión que llamó Colas de Mercurial\ndt{Mercurial |
igor@443 | 115 Queues}, que proporcionó un comportamiento a Mercurial al estilo |
igor@443 | 116 quilt. |
igor@443 | 117 |
igor@443 | 118 La diferencia clave entre quilt y MQ es que quilt no sabe nada acerca |
igor@443 | 119 del sistema de control de revisiones, mientras que MQ está |
igor@443 | 120 \emph{integrado} con Mercurial. Cada parche que usted introduce se |
igor@443 | 121 representa como un conjunto de cambios en Mercurial. Si sustrae un |
igor@443 | 122 parche, el conjunto de cambios desaparece.\ndt{introduce originalmente es |
igor@443 | 123 push y pop es sustraer en este contexto, usaremos el original en inglés |
igor@443 | 124 cuando encontremos que facilita la comprensión} |
igor@443 | 125 |
igor@443 | 126 Dado que quilt no se preocupa por las herramientas de control de |
igor@443 | 127 revisiones, continúa siendo una porción de software tremendamente útil |
igor@443 | 128 para aquellas situaciones en las cuales no puede usar Mercurial y MQ. |
igor@443 | 129 |
igor@443 | 130 \section{La gran ventaja de MQ} |
igor@443 | 131 |
igor@443 | 132 No puedo sobreestimar el valor que MQ ofrece en la unificación de |
igor@443 | 133 parches y el control de revisiones. |
igor@443 | 134 |
igor@443 | 135 La principal razón por la cual los parches han persistido en el mundo |
igor@443 | 136 del software libre y de fuentes abiertas--a pesar de la creciente |
igor@443 | 137 disponibilidad de herramientas poderosas de control de revisiones-- es |
igor@443 | 138 la \emph{agilidad} que ofrecen. |
igor@443 | 139 |
igor@443 | 140 Las herramientas tradicionales de control de revisiones llevan un |
igor@443 | 141 registro permanente e irreversible de todo lo que usted hace. A pesar |
igor@443 | 142 de que esto tiene gran valor, también es bastante sutil. Si requiere |
igor@443 | 143 realizar un experimento ((((wild-eyed)))), debe ser cuidadoso en cómo |
igor@443 | 144 lo hace, o puede dejar trazas innecesarias--o peor aún, |
igor@443 | 145 desconcertantes o desestabilizantes--- de los pasos y errores en el |
igor@443 | 146 registro de revisiones de forma permanente. |
igor@443 | 147 |
igor@443 | 148 En contraste, con la cohesión de MQ con el control de revisiones |
igor@443 | 149 distribuidos y los parches, resulta más sencillo aislar su trabajo. |
jerojasro@517 | 150 Sus parches viven encima del historial de revisiones normales, y |
igor@443 | 151 puede hacer que ellos desaparezcan o reaparezcan cuando lo desee. Si |
igor@443 | 152 no le gusta un parche, puede desecharlo. Si un parche no satisface |
igor@443 | 153 todo lo que usted desea, puede arreglarlo---tantas veces como lo |
igor@443 | 154 requiera, hasta que lo haya refinado lo suficiente hacia sus |
igor@443 | 155 expectativas. |
igor@443 | 156 |
igor@443 | 157 Por ejemplo, la integración de parches con el control de revisiones |
igor@443 | 158 hace que el entender los parches y revisar sus efectos---y sus |
igor@443 | 159 interacciones con el código en el cuál están enlazados--- sea |
igor@443 | 160 \emph{mucho} más sencillo. Dado que todo parche que se aplique tiene |
igor@443 | 161 un conjunto de cambios asociado, puede usar |
igor@443 | 162 \hgcmdargs{log}{\emph{filename}} para ver qué conjuntos de cambios y |
igor@443 | 163 parches afectaron un fichero. Puede usar la orden \hgext{bisect} para |
igor@443 | 164 hacer una búsqueda binaria sobre todos los conjuntos de cambios y |
igor@443 | 165 parches aplicados para ver dónde se introdujo un fallo o dónde fue |
igor@443 | 166 arreglado. Puede usar la orden \hgcmd{annotate} para ver qué |
igor@443 | 167 conjuntos de cambios o parches modificaron una línea particular de un |
igor@449 | 168 fichero fuente. Y mucho más. |
igor@443 | 169 |
igor@443 | 170 \section{Entender los parches} |
jerojasro@336 | 171 \label{sec:mq:patch} |
jerojasro@336 | 172 |
igor@443 | 173 Dado que MQ no esconde su naturaleza parche-céntrica, es muy útil para |
igor@443 | 174 entender de qué se tratan los parches, y un poco acerca de las |
igor@443 | 175 herramientas que trabajan con ellos. |
igor@443 | 176 |
igor@443 | 177 La orden de Unix tradicional \command{diff} compara dos ficheros, e |
igor@443 | 178 imprime una lista de diferencias de sus líneas. La orden |
igor@443 | 179 \command{patch} entiende esas diferencias como \emph{modificaciones} |
igor@443 | 180 para construir un fichero. Vea en la figura~\ref{ex:mq:diff} un |
igor@443 | 181 ejemplo sencillo de tales órdenes en acción. |
jerojasro@336 | 182 |
jerojasro@336 | 183 \begin{figure}[ht] |
jerojasro@336 | 184 \interaction{mq.dodiff.diff} |
igor@443 | 185 \caption{Uso sencillo de las órdenes \command{diff} y \command{patch}} |
jerojasro@336 | 186 \label{ex:mq:diff} |
jerojasro@336 | 187 \end{figure} |
jerojasro@336 | 188 |
igor@443 | 189 El tipo de fichero que \command{diff} genera (y que \command{patch} |
igor@443 | 190 toma como entrada) se llama un ``parche'' o un ``diff''; no hay |
igor@443 | 191 diferencia entre un parche y un diff. (Usaremos el término ``parche'', |
igor@443 | 192 dado que es el que más comunmente se usa.) |
igor@443 | 193 |
igor@443 | 194 Un parche puede comenzar con un texto arbitrario; la orden \command{patch} |
igor@443 | 195 ignora este texto, pero MQ lo usa como el mensaje de consignación |
igor@443 | 196 cuando se crean conjuntos de cambios. Para encontrar el inicio del |
igor@443 | 197 contenido de un parche, la orden \command{patch} busca la primera |
igor@443 | 198 línea que comience con la cadena ``\texttt{diff~-}''. |
igor@443 | 199 |
igor@443 | 200 MQ trabaja con diffs \emph{unificados} (\command{patch} acepta varios |
igor@443 | 201 formatos de diff adicionales, pero MQ no). Un diff unificado contiene |
igor@443 | 202 dos clases de encabezados. El \emph{encabezado de fichero} describe |
igor@443 | 203 el fichero que se está modificando; contiene el nombre del fichero a |
igor@443 | 204 modificar. Cuando \command{patch} ve un nuevo encabezado de fichero, |
igor@443 | 205 busca un fichero con ese nombre para modificarlo. |
igor@443 | 206 |
igor@443 | 207 Después del encabezaado vienen varios \emph{trozos}. Cada trozo |
igor@443 | 208 comienza con un encabezado; que identifica el rango de líneas del |
igor@443 | 209 fichero que el trozo debe modificar. Después del encabezado, un trozo |
jerojasro@480 | 210 comienza y termina con unas pocas líneas (usualmente tres) de texto del |
igor@443 | 211 fichero que no han sido modificadas; las cuales llamamos el |
igor@443 | 212 \emph{contexto} del trozo. Si solamente hay una pequeña cantidad de |
igor@443 | 213 contexto entre trozos sucesivos, \command{diff} no imprime un nuevo |
igor@443 | 214 encabezado para el trozo, continua integrando los trozos, con unas |
igor@443 | 215 líneas de contexto entre las modificaciones. |
igor@443 | 216 |
igor@443 | 217 Cada línea de contexto comienza con un caracter de espacio. En el |
igor@443 | 218 trozo, si una línea comienza con ``\texttt{-}'' significa ``elimine |
igor@443 | 219 esta línea'', si la línea comienza con un ``\texttt{+}'' significa |
igor@443 | 220 ``inserte esta línea''. Por ejemplo, una línea que se modifica se |
igor@443 | 221 representa con una línea eliminada y una línea insertada. |
igor@443 | 222 |
jerojasro@480 | 223 Retomaremos aspectos más sutiles acerca de parches posteriormente (en |
igor@443 | 224 la sección~\ref{sec:mq:adv-patch}), pero en el momento usted ya |
igor@443 | 225 debería tener suficiente información para usar MQ. |
igor@443 | 226 |
igor@443 | 227 \section{Comenzar a usar Colas de Mercurial} |
jerojasro@336 | 228 \label{sec:mq:start} |
jerojasro@336 | 229 |
igor@443 | 230 Dado que MQ está implementado como una extensión, debe habilitarla |
igor@443 | 231 explícitamente antes de comenzar a usarla. (No necesita descargar |
igor@443 | 232 nada; MQ viene con la distribución estándar de Mercurial.) Para |
igor@443 | 233 habilitar MQ, edite su fichero \tildefile{.hgrc}, y añada las líneas |
igor@443 | 234 de la figura~\ref{ex:mq:config}. |
jerojasro@336 | 235 |
jerojasro@336 | 236 \begin{figure}[ht] |
jerojasro@336 | 237 \begin{codesample4} |
jerojasro@336 | 238 [extensions] |
jerojasro@336 | 239 hgext.mq = |
jerojasro@336 | 240 \end{codesample4} |
jerojasro@336 | 241 \label{ex:mq:config} |
igor@443 | 242 \caption{Líneas a añadir en \tildefile{.hgrc} para habilitar la extensión MQ} |
igor@443 | 243 \end{figure} |
igor@443 | 244 |
igor@443 | 245 Cuando la extensión esté habilitada, aparecerán varios comandos. Para |
igor@443 | 246 verificar que la extensión está trabajando, puede usar \hgcmd{help} |
igor@443 | 247 para ver si la orden \hgxcmd{mq}{qinit} está disponible; vea un |
igor@443 | 248 ejemplo en la figura~\ref{ex:mq:enabled}. |
jerojasro@336 | 249 |
jerojasro@336 | 250 \begin{figure}[ht] |
jerojasro@336 | 251 \interaction{mq.qinit-help.help} |
igor@443 | 252 \caption{Cómo verificar que MQ está habilitado} |
jerojasro@336 | 253 \label{ex:mq:enabled} |
jerojasro@336 | 254 \end{figure} |
jerojasro@336 | 255 |
igor@443 | 256 Puede usar MQ en \emph{cualquier} repositorio de Mercurial, y sus |
igor@443 | 257 comandos solamente operarán con tal repositorio. Para comenzar, basta |
jerojasro@480 | 258 con preparar el repositorio con la orden \hgxcmd{mq}{qinit} (ver la |
igor@443 | 259 figura~\ref{ex:mq:qinit}). Esta orden crea un directorio vacío |
igor@443 | 260 llamado \sdirname{.hg/patches}, donde MQ mantendrá sus metadatos. Como |
igor@443 | 261 otras ordenes de Mercurial, la orden \hgxcmd{mq}{qinit} no imprime |
igor@443 | 262 nada cuando es exitosa. |
jerojasro@336 | 263 |
jerojasro@336 | 264 \begin{figure}[ht] |
jerojasro@336 | 265 \interaction{mq.tutorial.qinit} |
igor@443 | 266 \caption{Preparar un repositorio para usar MQ} |
jerojasro@336 | 267 \label{ex:mq:qinit} |
jerojasro@336 | 268 \end{figure} |
jerojasro@336 | 269 |
jerojasro@336 | 270 \begin{figure}[ht] |
jerojasro@336 | 271 \interaction{mq.tutorial.qnew} |
igor@443 | 272 \caption{Crear un nuevo parche} |
jerojasro@336 | 273 \label{ex:mq:qnew} |
jerojasro@336 | 274 \end{figure} |
jerojasro@336 | 275 |
igor@443 | 276 \subsection{Crear un nuevo parche} |
igor@443 | 277 |
igor@443 | 278 Para comenzar a trabajar en un nuevo parche use la orden |
igor@443 | 279 \hgxcmd{mq}{qnew}. Esta orden recibe un argumento, el nombre del |
igor@443 | 280 parche a crear. MQ lo usará como el nombre del fichero en el |
igor@443 | 281 directorio \sdirname{.hg/patches}, como puede apreciarlo en la |
igor@443 | 282 figura~\ref{ex:mq:qnew}. |
igor@443 | 283 |
igor@443 | 284 También hay otros dos nuevos ficheros en el directorio |
igor@443 | 285 \sdirname{.hg/patches}: \sfilename{series} y \sfilename{status}. El |
igor@443 | 286 fichero \sfilename{series} lista todos los parches de los cuales MQ |
igor@443 | 287 tiene noticia para este repositorio, con un parche por línea. |
igor@443 | 288 Mercurial usa el fichero \sfilename{status} para mantener registros |
igor@443 | 289 interns; da seguimiento a todos los parches que MQ ha \emph{aplicado} |
igor@443 | 290 en el repositorio. |
jerojasro@336 | 291 |
jerojasro@336 | 292 \begin{note} |
igor@443 | 293 En ciertas ocasiones usted querrá editar el fichero |
igor@443 | 294 \sfilename{series} a mano; por ejemplo, cambiar el orden en que se |
igor@443 | 295 aplican ciertos parches. A pesar de esto, es una mala idea editar |
igor@443 | 296 manualmente el fichero \sfilename{status}, dado que es fácil |
igor@443 | 297 desorientar a MQ acerca de lo que está pasando. |
jerojasro@336 | 298 \end{note} |
jerojasro@336 | 299 |
igor@443 | 300 Una vez que haya creado un nuevo parche, puede editar los ficheros en |
igor@443 | 301 el directorio de trabajo, como lo haría usualmente. Toda las órdenes |
igor@443 | 302 que de a Mercurial, tales como \hgcmd{diff} y \hgcmd{annotate}, |
igor@443 | 303 trabajarán de la misma forma como lo han hecho antes. |
igor@443 | 304 |
igor@443 | 305 \subsection{Refrescar un parche} |
igor@443 | 306 |
igor@443 | 307 Cuando usted llega a un punto en el cual desea guardar su trabajo, use |
jerojasro@480 | 308 la orden \hgxcmd{mq}{qrefresh} (figura~\ref{ex:mq:qnew}) para |
igor@443 | 309 actualizar el parche en el cual está trabajando. Esta orden almacena |
igor@443 | 310 los cambios que haya hecho al directorio actual de trabajo en su |
igor@443 | 311 parche, y almacena el conjunto de cambios correspondiente que contiene |
igor@443 | 312 los cambios. |
jerojasro@336 | 313 |
jerojasro@336 | 314 \begin{figure}[ht] |
jerojasro@336 | 315 \interaction{mq.tutorial.qrefresh} |
igor@443 | 316 \caption{Refrescar un parche} |
jerojasro@336 | 317 \label{ex:mq:qrefresh} |
jerojasro@336 | 318 \end{figure} |
jerojasro@336 | 319 |
igor@443 | 320 Puede ejecutar la orden \hgxcmd{mq}{qrefresh} tan seguido como quiera, |
igor@443 | 321 y es una buena forma de ``colocar marcas'' a su trabajo. Refresque su |
igor@443 | 322 parche en momentos oportunos; intente un experimento; si el |
igor@443 | 323 experimento no funciona, Use \hgcmd{revert} sobre sus modificaciones |
igor@443 | 324 para volver al refresco anterior. |
jerojasro@336 | 325 |
jerojasro@336 | 326 \begin{figure}[ht] |
jerojasro@336 | 327 \interaction{mq.tutorial.qrefresh2} |
igor@443 | 328 \caption{Refrescar un parche muchas veces para acumular cambios} |
jerojasro@336 | 329 \label{ex:mq:qrefresh2} |
jerojasro@336 | 330 \end{figure} |
jerojasro@336 | 331 |
igor@443 | 332 \subsection{Aplicar un parche tras otro y dar seguimiento} |
igor@443 | 333 |
igor@443 | 334 Cuando haya terminado de trabajar en un parche, o necesite trabajar en |
igor@443 | 335 otro, puede usar la orden \hgxcmd{mq}{qnew} para crear un nuevo |
igor@443 | 336 parche. Mercurial aplicará este parche sobre su parche anterior. |
igor@443 | 337 Para un ejemplo, ver la figura~\ref{ex:mq:qnew2}. Note que el parche |
igor@443 | 338 contiene los cambios en nuestro parche anterior como parte de su |
jerojasro@480 | 339 contexto (lo verá más claramente en la salida de \hgcmd{annotate}). |
jerojasro@336 | 340 |
jerojasro@336 | 341 \begin{figure}[ht] |
jerojasro@336 | 342 \interaction{mq.tutorial.qnew2} |
igor@443 | 343 \caption{Aplicar un parche después del primero} |
jerojasro@336 | 344 \label{ex:mq:qnew2} |
jerojasro@336 | 345 \end{figure} |
jerojasro@336 | 346 |
igor@443 | 347 Hasta ahora, con excepción de \hgxcmd{mq}{qnew} y |
igor@443 | 348 \hgxcmd{mq}{qrefresh}, hemos sido cuidadosos para aplicar únicamente |
igor@443 | 349 órdenes usuaales de Mercurial. De todas maneras, MQ ofrece muchos |
igor@443 | 350 comandos que son más sencillos de usar cuando esté pensando acerca de |
igor@443 | 351 parches, como se puede ver en la figura~\ref{ex:mq:qseries}: |
jerojasro@336 | 352 |
jerojasro@336 | 353 \begin{itemize} |
igor@443 | 354 \item La orden \hgxcmd{mq}{qseries} lista cada parche del cual MQ |
igor@443 | 355 tiene noticia en este repositorio, desde el más antiguo hasta el más |
jerojasro@480 | 356 nuevo (El último \emph{creado}). |
igor@443 | 357 \item La orden \hgxcmd{mq}{qapplied} lista cada parche que MQ haya |
igor@443 | 358 \emph{aplicado} en este repositorio, de nuevo, desde el más antiguo |
igor@443 | 359 hasta el más nuevo (El aplicado más recientemente). |
jerojasro@336 | 360 \end{itemize} |
jerojasro@336 | 361 |
jerojasro@336 | 362 \begin{figure}[ht] |
jerojasro@336 | 363 \interaction{mq.tutorial.qseries} |
igor@443 | 364 \caption{Entender la pila de parches con \hgxcmd{mq}{qseries} y |
jerojasro@336 | 365 \hgxcmd{mq}{qapplied}} |
jerojasro@336 | 366 \label{ex:mq:qseries} |
jerojasro@336 | 367 \end{figure} |
jerojasro@336 | 368 |
igor@443 | 369 \subsection{Manipular la pila de parches} |
igor@443 | 370 |
igor@443 | 371 La discusión previa indicó que debe haber una diferencia entre los |
igor@443 | 372 parches ``conocidos'' y ``aplicados'', y efectivamente la hay. MQ |
igor@443 | 373 puede manejar un parche sin que este haya sido aplicado al |
igor@443 | 374 repositorio. |
igor@443 | 375 |
igor@443 | 376 Un parche \emph{aplicado} tiene su correspondiente conjunto de cambios |
igor@443 | 377 en el repositorio, y los efectos del parche y el conjunto de cambios |
igor@443 | 378 son visibles en el directorio de trabajo. Puede deshacer la |
igor@443 | 379 aplicación de un parche con la orden \hgxcmd{mq}{qpop}. MQ |
igor@443 | 380 \emph{sabe acerca de}, o maneja un parche sustraído, pero el parche ya |
igor@443 | 381 no tendrá un conjunto de cambios correspondientes en el repositorio, y |
igor@443 | 382 el directorio de trabajo no contendrá los cambios hechos por el |
igor@443 | 383 parche. La figura~\ref{fig:mq:stack} ilustra la diferencia entre |
igor@443 | 384 parches aplicados y seguidos. |
jerojasro@336 | 385 |
jerojasro@336 | 386 \begin{figure}[ht] |
jerojasro@336 | 387 \centering |
jerojasro@336 | 388 \grafix{mq-stack} |
igor@443 | 389 \caption{Parches aplicados y no aplicados en la pila de parches de MQ} |
jerojasro@336 | 390 \label{fig:mq:stack} |
jerojasro@336 | 391 \end{figure} |
jerojasro@336 | 392 |
igor@443 | 393 Puede reaplicar un parche no aplicado o sustraído con la orden |
igor@443 | 394 \hgxcmd{mq}{qpush}. Esto crea un nuevo conjunto de cambios |
igor@443 | 395 correspondiente al parche, y los cambios del parche estarán presentes |
igor@443 | 396 de nuevo en el directorio de trabajo. Vea ejemplos de |
igor@443 | 397 \hgxcmd{mq}{qpop} y \hgxcmd{mq}{qpush} en acción en la |
igor@443 | 398 figura~\ref{ex:mq:qpop}. Vea que hemos sustraído uno o dos parches, |
igor@443 | 399 la salida de\hgxcmd{mq}{qseries} continúa igual, mientras que |
igor@443 | 400 \hgxcmd{mq}{qapplied} ha cambiado. |
jerojasro@336 | 401 |
jerojasro@336 | 402 \begin{figure}[ht] |
jerojasro@336 | 403 \interaction{mq.tutorial.qpop} |
igor@443 | 404 \caption{Modificar la pila de parches aplicados} |
jerojasro@336 | 405 \label{ex:mq:qpop} |
jerojasro@336 | 406 \end{figure} |
jerojasro@336 | 407 |
igor@443 | 408 \subsection{Introducir y sustraer muchos parches} |
igor@443 | 409 |
igor@443 | 410 Mientras que \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} operan sobre un |
igor@443 | 411 único parche cada vez, puede introducir y sustraer varios parches de |
igor@443 | 412 una vez. La opción \hgxopt{mq}{qpush}{-a} de \hgxcmd{mq}{qpush} |
igor@443 | 413 introduce todos los cambios que no hayan sido aplicados, mientras que |
igor@443 | 414 la opción \hgxopt{mq}{qpop}{-a} de \hgxcmd{mq}{qpop} sustrae todos los |
igor@443 | 415 cambios aplicados. (Vea la sección~\ref{sec:mq:perf} más adelante |
igor@443 | 416 en la cual se explican otras formas de de introducir y sustraer varios |
igor@443 | 417 cambios.) |
jerojasro@336 | 418 |
jerojasro@336 | 419 \begin{figure}[ht] |
jerojasro@336 | 420 \interaction{mq.tutorial.qpush-a} |
jerojasro@336 | 421 \caption{Pushing all unapplied patches} |
jerojasro@336 | 422 \label{ex:mq:qpush-a} |
jerojasro@336 | 423 \end{figure} |
jerojasro@336 | 424 |
igor@443 | 425 \subsection{Medidas de seguridad y cómo saltarlas} |
igor@443 | 426 |
igor@443 | 427 Muchas órdenes MQ revisan el directorio de trabajo antes de hacer |
igor@443 | 428 cualquier cosa, y fallan si encuentran alguna modificación. Lo hacen |
igor@443 | 429 para garantizar que usted no pierda cambio alguno de los que haya |
igor@443 | 430 hecho, pero que no hayan sido incorporados en algún parche. La |
igor@443 | 431 figura~\ref{ex:mq:add} ilusta esto; la orden \hgxcmd{mq}{qnew} no |
igor@443 | 432 creará un nuevo parche si hay cambios notorios, causados en este caso |
igor@443 | 433 por aplicado la orden \hgcmd{add} a \filename{file3}. |
jerojasro@336 | 434 |
jerojasro@336 | 435 \begin{figure}[ht] |
jerojasro@336 | 436 \interaction{mq.tutorial.add} |
igor@443 | 437 \caption{Crear un parche a la fuerza} |
jerojasro@336 | 438 \label{ex:mq:add} |
jerojasro@336 | 439 \end{figure} |
jerojasro@336 | 440 |
igor@443 | 441 Las órdenes que revisan el directorio actual cuentan con una opción |
igor@443 | 442 ``Se lo que estoy haciendo'', que siempre está nombrada como |
igor@443 | 443 \option{-f}. El significado exacto de \option{-f} depende de la |
igor@443 | 444 orden. Por ejemplo, \hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}} |
igor@443 | 445 incorporarán cualquier cambio notorio en el nuevo parche que crea pero |
igor@443 | 446 \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-f}} revertirá las modificaciones a |
igor@443 | 447 cualquier fichero que haya sido afectado por el parche que está siendo |
igor@443 | 448 sustraído. ¡Asegúrese de leer la documentación de la opción \option{-f} |
igor@443 | 449 de cada comando antes de usarla! |
igor@443 | 450 |
igor@443 | 451 \subsection{Trabajar con varios parches a la vez} |
igor@443 | 452 |
igor@443 | 453 La orden \hgxcmd{mq}{qrefresh} siempre refresca el \emph{último} |
igor@443 | 454 parche aplicado. Esto significa que usted puede suspender su trabajo |
igor@443 | 455 en un parche (refrescándolo), sustraerlo o introducirlo para lograr |
igor@443 | 456 que otro parche esté de último y trabajar en \emph{ese} parche por un |
igor@443 | 457 rato. |
igor@443 | 458 |
igor@443 | 459 A continuación un ejemplo que ilustra cómo puede usar esta habilidad. |
igor@443 | 460 Digamos que está desarrollando una nueva característica en dos |
igor@443 | 461 parches. El primero es un cambio en la parte fundamental de su |
igor@443 | 462 programa, y el segundo--sobre el primero---cambia la interfaz de |
igor@443 | 463 usuario para usar el código que ha añadido a la parte fundamental. Si |
igor@443 | 464 ve que hay un fallo en la parte fundamental mientras está trabajando |
igor@443 | 465 en el parche de UI\ndt{Interfaz de Usuario, User Interface en inglés}, es fácil arreglar la parte fundamental. |
igor@443 | 466 Simplemente use \hgxcmd{mq}{qrefresh} sobre el parche de la UI para |
igor@443 | 467 guardar los cambios de su trabajo en progreso, y use \hgxcmd{mq}{qpop} |
igor@443 | 468 para sacar sustraer el parche de la parte fundamental. Arregla el |
igor@443 | 469 fallo sobre la parte fundamental, aplique \hgxcmd{mq}{qrefresh} sobre |
igor@443 | 470 el parche fundamental, y aplique \hgxcmd{mq}{qpush} sobre el parche de |
igor@443 | 471 UI para continuar donde había quedado. |
jerojasro@336 | 472 |
igor@444 | 473 \section{Más acerca de parches} |
jerojasro@336 | 474 \label{sec:mq:adv-patch} |
jerojasro@336 | 475 |
igor@444 | 476 MQ usa la orden GNU \command{patch} para aplicar los parches, por lo |
igor@444 | 477 tanto es útil conocer ciertos detalles de cómo trabaja |
igor@444 | 478 \command{patch}, y también acerca de los parches. |
igor@444 | 479 |
igor@444 | 480 \subsection{La cantidad de franjas} |
igor@444 | 481 |
igor@449 | 482 Si ve el encabezado de un parche, notará que la ruta al fichero tiene |
igor@444 | 483 un componente adicional al principio, que no está presente en la |
igor@444 | 484 ruta. Esta es una traza de cómo generaba anteriormente los parches la |
jerojasro@480 | 485 gente (algunos aún lo hacen, pero es raro con las herramientas de |
igor@444 | 486 control de revisiones del actuales). |
igor@444 | 487 |
igor@449 | 488 Alicia desempaquetaría un comprimido, editaría sus ficheros, y querría |
igor@444 | 489 crear un parche. Por lo tanto ella renombraría su directorio de |
jerojasro@520 | 490 trabajo, desempacaría el comprimido de nuevo (para lo cual necesitó el |
igor@444 | 491 renombramiento), y usaría las opciones \cmdopt{diff}{-r} y |
igor@444 | 492 \cmdopt{diff}{-N} de \command{diff} para generar recursivamente un |
igor@444 | 493 parche entre el directorio original y el modificado. El resultado |
igor@444 | 494 sería que el nombre del directorio original estaría al principio de |
igor@444 | 495 toda ruta en cada encabezado de fichero, y el nombre del directorio |
igor@444 | 496 modificado estaría al frente de la porción derecha de la ruta del |
igor@449 | 497 fichero. |
jerojasro@336 | 498 |
igor@446 | 499 Como alguien que reciba un parche de Alicia en la red podría obtener |
igor@446 | 500 dos directorios, uno original y el otro modificado con exactamente los |
igor@446 | 501 mismos nombres, la orden \command{patch} tiene la opción |
igor@446 | 502 \cmdopt{patch}{-p} que indica la cantidad de componentes de la ruta |
igor@446 | 503 a eliminar cuando se vaya a aplicar el parche. Este número se |
igor@446 | 504 llama la \emph{cantidad de eliminaciones}. |
igor@446 | 505 |
igor@446 | 506 La opción con ``\texttt{-p1}'' significa ``elimine uno''. Si |
igor@446 | 507 \command{patch} ve un nombre de fichero \filename{foo/bar/baz} en el |
igor@446 | 508 encabezado del fichero, eliminará \filename{foo} y tratará de parchar |
igor@446 | 509 un fichero llamado \filename{bar/baz}. (Hablando estrictamente, la |
igor@446 | 510 cantidad de eliminaciones se refiere a la cantidad de \emph{separadores de |
igor@446 | 511 ruta} (y los componentes que vayan con ellos) a eliminar. Si el |
igor@446 | 512 contador es uno volverá \filename{foo/bar} en \filename{bar}, pero |
igor@446 | 513 \filename{/foo/bar} (note la barra extra) en \filename{foo/bar}.) |
igor@446 | 514 |
igor@446 | 515 La cantidad a eliminar``estándar'' para parches es uno; casi todos los |
igor@446 | 516 parches contienen un componente inicial de la ruta que necesita ser |
igor@446 | 517 eliminado. La orden \hgcmd{diff} de Mercurial genera nombres de ruta |
igor@446 | 518 de esta forma, y la orden \hgcmd{import} y MQ esperan parches que |
igor@446 | 519 tengan a uno como cuenta de eliminaciones. |
igor@446 | 520 |
igor@446 | 521 Si recibe un parche de alguien de quien desea adicionar adicionar a su |
igor@446 | 522 cola de parches, y el parche necesita una cuenta de eliminación que no |
igor@446 | 523 sea uno, no podrá aplicar \hgxcmd{mq}{qimport} en primera medida, |
igor@446 | 524 porque \hgxcmd{mq}{qimport} no tiene todavía una opción \texttt{-p} |
igor@446 | 525 option (ver~\bug{311}). Lo mejor que puede hacer es aplicar |
igor@446 | 526 \hgxcmd{mq}{qnew} por su cuenta, y después usar \cmdargs{patch}{-p\emph{N}} |
igor@446 | 527 para aplicar tal parche, seguido de \hgcmd{addremove} para tener en |
igor@446 | 528 cuenta cualquier fichero adicionado o eliminado por el parche, seguido |
igor@446 | 529 de \hgxcmd{mq}{qrefresh}. Esta complejidad puede ser innecesaria; |
igor@446 | 530 consulte~\bug{311} para más información. |
igor@446 | 531 |
igor@446 | 532 \subsection{Estrategias para aplicar parches} |
igor@446 | 533 |
igor@446 | 534 Cuando \command{patch} aplica un trozo, intenta varias estrategias |
igor@446 | 535 sucesivas que decrecen en precisión para intentar aplicarlo. Esta |
igor@446 | 536 técnica de pruebas y error aveces permite que un parche que fue |
igor@446 | 537 generado contra una versión anterior de un fichero, sea aplicada sobre |
igor@446 | 538 una versión más nueva del mismo. |
igor@446 | 539 |
igor@446 | 540 Primero \command{patch} intenta una correspondencia perfecta donde los |
igor@446 | 541 números de línea, el contexto y el texto a modificar deben coincidir |
igor@446 | 542 perfectamente. Si no lo logra, intenta encontrar una correspondencia |
igor@446 | 543 exacta del contexto, sin tener en cuenta el número de línea. Si es |
igor@446 | 544 exitoso, imprime una línea indicando que el trozo fue aplicado, pero a |
igor@446 | 545 un \emph{corrimiento} del número de línea original. |
igor@446 | 546 |
igor@446 | 547 Si falla la correspondencia por contexto, \command{patch} elimina la |
igor@446 | 548 primera y la última línea del contexto, e intenta una correspondencia |
igor@446 | 549 \emph{reducida} del contexto. Si el trozo con contexto reducido es |
igor@446 | 550 exitoso, imprime un mensaje indicando que aplicó el trozo con un |
igor@446 | 551 \emph{factor difuso} (el número después del factor difuso indica |
igor@446 | 552 cuántas líneas de contexto \command{patch} tuvo que eliminar antes de |
igor@446 | 553 aplicar el parche). |
igor@446 | 554 |
igor@446 | 555 Cuando ninguna de estas técnicas funciona, \command{patch} imprime un |
igor@446 | 556 mensaje indicando que el trozo en cuestión se desechó. Almacena los |
jerojasro@480 | 557 trozos desechados (también llamados ``descartados'') en un fichero con |
igor@446 | 558 el mismo nombre, y la extensión \sfilename{.rej} añadida. También |
igor@446 | 559 almacena una copia igual al fichero original con la extensión |
igor@446 | 560 \sfilename{.orig}; la copia del fichero sin extensión contendrá |
igor@446 | 561 cualquier cambio hecho por los trozos que \emph{sí} se aplicaron sin |
igor@446 | 562 problema. Si usted tiene un parche que modifica \filename{foo} con |
igor@446 | 563 seis trozos, y uno de ellos falla al aplicarse, tendrá : un fichero |
igor@446 | 564 original \filename{foo.orig}, un fichero \filename{foo.rej} que |
igor@446 | 565 contiene el trozo, y \filename{foo}, que contiene los cambios que se |
igor@446 | 566 aplicaron por los cinco trozos exitosos. |
igor@446 | 567 |
igor@446 | 568 \subsection{Algunos detalles de la representación de parches} |
igor@446 | 569 |
igor@446 | 570 Hay ciertas cosas útiles por saber acerca de cómo trabaja |
igor@446 | 571 \command{patch} con los ficheros: |
jerojasro@336 | 572 \begin{itemize} |
igor@446 | 573 \item Debería ser obvio que \command{patch} no puede manipular |
igor@446 | 574 ficheros binarios. |
igor@446 | 575 \item No se preocupa por el bit ejecutable; crea ficheros nuevos en |
igor@446 | 576 modo lectura, pero no ejecutable. |
igor@446 | 577 \item \command{patch} intenta eliminar un fichero como una diferencia |
igor@446 | 578 entre el fichero a eliminar y un fichero vacío. Y por lo tanto su |
igor@446 | 579 idea de ``Borré este fichero'' debería pensarse como ``toda línea de |
igor@446 | 580 este fichero fue eliminada'' en un parche. |
igor@446 | 581 \item Trata la adición de un fichero como un diff entre un fichero |
igor@446 | 582 vacío y el fichero a ser adicionado. Por lo tanto en un parche su |
igor@446 | 583 idea de ``Añadí este fichero'' se vería como ``toda línea de este |
igor@446 | 584 fichero fue añadida''. |
igor@446 | 585 \item Trata el renombramiento de un fichero como la eliminación del |
igor@446 | 586 nombre anterior y la adición del nuevo nombre. Esto significa que |
igor@446 | 587 los ficheros renombrados dejan un rastro grande en los parches. |
igor@446 | 588 (Tenga en cuenta que Mercurial no trata de inferir cuando los |
igor@449 | 589 ficheros han sido renombrados o copiados en un parche en este |
igor@446 | 590 momento.) |
igor@446 | 591 \item \command{patch} no puede representar ficheros vacíos, por lo |
igor@446 | 592 tanto no puede usar un parche para representar la noción ``Añadí |
igor@446 | 593 este fichero vacío al árbol''. |
jerojasro@336 | 594 \end{itemize} |
igor@446 | 595 \subsection{Cuidado con los difusos} |
jerojasro@336 | 596 |
igor@447 | 597 Cuando aplique un trozo con un corrimiento, o con un factor difuso, |
igor@447 | 598 aveces será taotalmente exitoso, tales técnicas inexactas dejan |
igor@449 | 599 claramente la posibilidad de corromper el fichero parchado. Los casos |
igor@447 | 600 más típicos involucran aplicar un parche dos veces o en un sitio |
igor@447 | 601 incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan |
igor@447 | 602 a mencionar un corrimiento o un factor difuso, debería asegurarse que |
igor@447 | 603 los ficheros modificados estén correctos después del suceso. |
igor@447 | 604 |
igor@447 | 605 Casi siempre es buena idea refrescar un parche que fue aplicado con un |
igor@447 | 606 corrimiento o un factor difuso; refrescar el parche genera nueva |
igor@447 | 607 información de contexto que permitirá aplicarlo limpiamente. Digo |
igor@447 | 608 ``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones |
igor@447 | 609 refrescar un parche lo hará fallar frente a una revisión diferente del |
igor@447 | 610 fichero. En algunos casos, como por ejemplo, cuando usted está |
igor@447 | 611 manteniendo un parche que debe estar encima de múltiples revisiones de |
igor@447 | 612 un árbol de fuentes, es aceptable tener un parche aplicado algo |
igor@447 | 613 difuso, siempre que haya verificado los resultados del proceso de |
igor@447 | 614 parchar. |
igor@447 | 615 |
igor@447 | 616 \subsection{Manejo de descartes} |
igor@447 | 617 |
igor@447 | 618 Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de |
igor@447 | 619 error y saldrá. Si ha dejado ficheros \sfilename{.rej}, es mejor |
igor@447 | 620 arreglar los trozos descartados antes de introducir parches |
igor@447 | 621 adicionales o hacer cualquier otra cosa. |
igor@447 | 622 |
igor@447 | 623 Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace |
igor@447 | 624 porque ha cambiado código subyacente en el cual se basa su parche, las |
igor@447 | 625 Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}. |
igor@447 | 626 |
igor@447 | 627 Desafortunadamente, no hay grandes técnicas para tratar los trozos |
igor@447 | 628 descartados. Casi siempre deberá consultar el fichero |
igor@447 | 629 \sfilename{.rej} y editar el fichero objetivo, aplicando los trozos |
igor@447 | 630 descartados a mano. |
igor@447 | 631 |
igor@447 | 632 Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una |
igor@447 | 633 herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más |
igor@447 | 634 vigorosa que \command{patch} en su intento de hacer que se aplique un |
igor@447 | 635 parche. |
igor@447 | 636 |
igor@447 | 637 Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de |
igor@447 | 638 Mercurial), escribió una herramienta similar llamada |
igor@447 | 639 \command{mpatch}~\cite{web:mpatch}, que sigue una aproximación |
igor@447 | 640 sencilla para automatizar la aplicación de trozos descartados por |
igor@447 | 641 \command{patch}. La orden \command{mpatch} puede ayudar con cuatro |
igor@447 | 642 razones comunes por las cuales un parche ha sido descartado: |
jerojasro@336 | 643 |
jerojasro@336 | 644 \begin{itemize} |
igor@447 | 645 \item El contexto en la mitad de un trozo ha cambiado. |
igor@447 | 646 \item Un trozo ha perdido cierto contexto al principio o al final. |
igor@447 | 647 \item Un trozo largo podría aplicarse mejor---por completo o una |
igor@447 | 648 parte---si estaba cortado en trozos más pequeños. |
igor@447 | 649 \item Un trozo remueve líneas con contenido ligeramente diferente que |
igor@447 | 650 aquellas que están presentes en el fichero. |
jerojasro@336 | 651 \end{itemize} |
jerojasro@336 | 652 |
igor@447 | 653 Si usted usa \command{wiggle} o \command{mpatch}, debería ser |
igor@447 | 654 doblemente cuidadoso al revisar sus resultados cuando haya terminado. |
igor@447 | 655 De hecho, \command{mpatch} refuerza este método de revisar por partida |
igor@447 | 656 doble su salida, dejándolo a usted en un programa de fusión cuando la |
igor@447 | 657 herramienta haya terminado su trabajo, de tal forma que usted pueda |
igor@447 | 658 verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión |
igor@447 | 659 faltante. |
igor@447 | 660 |
igor@449 | 661 \section{maximizar el rendimiento de MQ} |
jerojasro@336 | 662 \label{sec:mq:perf} |
jerojasro@336 | 663 |
igor@447 | 664 MQ es muy eficiente al tratar con una gran cantidad de parches. Corrí |
igor@447 | 665 unos experimentos de desempeño a mediados del 2006 para una charla que |
igor@447 | 666 dí en la conferencia EuroPython 2006~\cite{web:europython}. Empleé la |
igor@447 | 667 serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738 |
igor@447 | 668 parches. Los apliqué sobre un repositorio del núcleo de Linux con |
igor@447 | 669 todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17. |
igor@447 | 670 |
igor@448 | 671 En mi portátil antiguo y lento, logré aplicar |
igor@447 | 672 \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5 |
igor@447 | 673 minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos. |
igor@447 | 674 (En un portátil más nuevo, el tiempo para introducir todos los |
igor@447 | 675 parches, se logró en menos de dos minutos.) Apliqué |
jerojasro@480 | 676 \hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes (que hizo |
igor@447 | 677 22.779 líneas de cambios en 287 ficheros) en 6,6 segundos. |
igor@447 | 678 |
igor@447 | 679 Claramente, MQ funciona adecuadamente en árboles grandes, y además hay |
igor@447 | 680 unos trucos que pueden emplearse para obtener el máximo desempeño. |
igor@447 | 681 |
igor@447 | 682 En primer lugar, trate de hacer ``en lote'' las operaciones. Cada vez |
igor@447 | 683 que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes |
igor@447 | 684 revisan el directorio de trabajo para asegurarse de que usted no ha |
igor@447 | 685 hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}. En un |
igor@447 | 686 árbol pequeño, el tiempo de esta revisión puede ser mínimo, Pero en |
jerojasro@480 | 687 un árbol mediano (con decenas de miles de ficheros), puede tomar un |
igor@447 | 688 segundo o más. |
igor@447 | 689 |
igor@447 | 690 Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten |
igor@447 | 691 introducir o sustraer varios parches en una operación. Puede |
igor@447 | 692 identificar el ``parche destino'' que desee. Cuando aplique |
igor@447 | 693 \hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea |
igor@447 | 694 necesario hasta que el especificado esté en el tope de la pila. |
igor@447 | 695 Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches |
igor@447 | 696 hasta que el parche destino esté en el tope. |
igor@447 | 697 |
igor@447 | 698 Puede identificar un parche destino con el nombre del parche o con el |
igor@447 | 699 número. Si se refiere al número, los parches se contarán desde cero; |
igor@447 | 700 esto significa que el primer parche es cero, el segundo es uno y así |
igor@447 | 701 sucesivamente. |
jerojasro@336 | 702 |
igor@448 | 703 \section{Actualiar los parches cuando el código cambia} |
jerojasro@336 | 704 \label{sec:mq:merge} |
jerojasro@336 | 705 |
igor@448 | 706 Es común contar con una pila de parches sobre un repositorio que usted |
igor@448 | 707 no modifica directamente. Si está trabajando en cambios de código de |
igor@448 | 708 otros, o en una característica que tarda bastante en desarrollarse |
igor@448 | 709 comparada con la tasa de cambio del código sobre la cual se está |
igor@448 | 710 trabajando, necesitará sincronizarse con el código, y ajustar |
igor@448 | 711 cualquier trozo en sus parches que ya no estén al día. A esto se le |
igor@448 | 712 llama hacer \emph{rebase} a su serie de parches. |
igor@448 | 713 |
igor@448 | 714 La vía más sencilla de hacerlo es con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} |
igor@448 | 715 sobre sus parches, después hacer \hgcmd{pull} de los cambios en el |
igor@448 | 716 repositorio, y finalmente hacer |
igor@448 | 717 \hgcmdargs{qpush}{\hgxopt{mq}{qpop}{-a}} con sus parches de nuevo. MQ |
igor@448 | 718 dejará de de introducir parches siempre que llegue a un parche que no se pueda |
igor@448 | 719 aplicar debido a un conflicto, permitiéndole a usted arreglarlo, |
igor@448 | 720 aplicar \hgxcmd{mq}{qrefresh} al parche afectado y continuar |
igor@448 | 721 introduciendo hasta que haya arreglado la pila completa. |
igor@448 | 722 |
igor@448 | 723 Esta aproximación es sencilla y funciona bien si no espera cambios en |
igor@448 | 724 el código original que afecte en gran medida los parches que usted |
igor@448 | 725 esté aplicando. Si su pila de parches toca código que es modificado |
igor@448 | 726 frecuentemente o de forma invasiva sobre el código subyacente, |
igor@448 | 727 arreglar trozos manualmente se vuelve desgastante. |
igor@448 | 728 |
igor@448 | 729 Es posible automatizar de forma parcial el proceso de rebase. Si sus |
igor@448 | 730 parches se aplican limpiamente sobre algunas revisiones del |
igor@448 | 731 repositorio subyacente, MQ puede usar esta información para ayudarle a |
igor@448 | 732 a resolver conflictos entre sus parches y una revisión distinta. |
igor@448 | 733 |
igor@448 | 734 El proceso resulta un poco complejo: |
jerojasro@336 | 735 \begin{enumerate} |
igor@448 | 736 \item Para comenzar, haga \hgcmdargs{qpush}{-a} sobre todos los |
igor@448 | 737 parches que usted sepa se aplican limpiamente. |
igor@448 | 738 \item Guarde una copia de seguridad de su directorio de parches con |
igor@448 | 739 \hgcmdargs{qsave}{\hgxopt{mq}{qsave}{-e} \hgxopt{mq}{qsave}{-c}}. |
igor@448 | 740 Esto imprime el nombre del directorio en el cual se han guardado los |
igor@448 | 741 parches. Guardará los parches en un directorio llamado |
igor@448 | 742 \sdirname{.hg/patches.\emph{N}}, donde \texttt{\emph{N}} es un |
igor@448 | 743 entero pequeño. También consigna un ``conjunto de cambios de |
igor@448 | 744 seguridad'' sobre sus parches aplicados; esto es para mantener el |
igor@448 | 745 histórico, y guarda los estados de los ficheros \sfilename{series} |
igor@448 | 746 y \sfilename{status}. |
igor@448 | 747 \item Use \hgcmd{pull} para traer los nuevos cambios en el repositorio |
igor@448 | 748 subyacente. (No ejecute \hgcmdargs{pull}{-u}; vea más adelante por qué.) |
igor@448 | 749 \item Actualice a la nueva revisión punta con |
igor@448 | 750 \hgcmdargs{update}{\hgopt{update}{-C}} para sobreescribir los |
igor@448 | 751 parches que haya introducido. |
igor@448 | 752 \item Fusione todos los parches con \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m} |
igor@448 | 753 \hgxopt{mq}{qpush}{-a}}. La opción \hgxopt{mq}{qpush}{-m} de \hgxcmd{mq}{qpush} |
igor@448 | 754 le indica a MQ que haga una fusión que involucra tres fuentes si el |
igor@448 | 755 parche falla al aplicarse. |
jerojasro@336 | 756 \end{enumerate} |
jerojasro@336 | 757 |
igor@448 | 758 Durante el \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-m}}, cada parche en |
igor@448 | 759 el fichero \sfilename{series} se aplica normalmente. Si un parche se |
igor@448 | 760 aplica difusamente o se niea a aplicarse, MQ consulta la cola que |
igor@448 | 761 usted guardó con \hgxcmd{mq}{qsave}, y aplica una fusión de tres con |
igor@448 | 762 el correspondiente conjunto de cambios. Esta fusión usa la maquinaria |
igor@448 | 763 de Mercurial, por lo tanto puede mostrar una herramienta de fusión GUI |
igor@448 | 764 para ayudarle a resolver los problemas. |
igor@448 | 765 |
igor@448 | 766 Cuando termine de resolver los efectos de un parche, MQ refrescará su |
igor@448 | 767 parche basado en el resultado de la fusión. |
igor@448 | 768 |
igor@448 | 769 Al final de este proceso, su repositorio tendrá una cabeza extra de la |
igor@448 | 770 antigua cola de parches, y una copia de la cola de parches anterio |
igor@448 | 771 estará en \sdirname{.hg/patches.\emph{N}}. Puede eliminar la cabeza |
igor@448 | 772 extra con \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a} \hgxopt{mq}{qpop}{-n} patches.\emph{N}} |
igor@448 | 773 o \hgcmd{strip}. Puede eliminar \sdirname{.hg/patches.\emph{N}} una |
igor@448 | 774 vez que esté seguro de que no lo necesita más como copia de seguridad. |
igor@448 | 775 |
igor@448 | 776 \section{Identificar parches} |
igor@448 | 777 |
igor@448 | 778 Las órdenes de MQ le permiten trabajar refiriéndose al nombre del |
igor@448 | 779 parche o al número. Es obvio hacerlo por el nombre; por ejemplo se |
igor@448 | 780 pasa el nombre \filename{foo.patch} a \hgxcmd{mq}{qpush}, que |
igor@448 | 781 introducirá los parches hasta que \filename{foo.patch} se aplique. |
igor@448 | 782 |
igor@448 | 783 Para hacerlo más corto, puede referirse a un parche con un nombre y un |
igor@448 | 784 corrimiento de número; por ejemplo, \texttt{foo.patch-2} significa |
igor@448 | 785 ``dos parches antes de \texttt{foo.patch}'', mientras que |
igor@448 | 786 \texttt{bar.patch+4} significa ``cuatro parches después de \texttt{bar.patch}''. |
igor@448 | 787 |
igor@448 | 788 Referirse a un parche por su índice no es muy diferente. El primer |
igor@448 | 789 parche que se imprime en la salida de \hgxcmd{mq}{qseries} es el |
jerojasro@480 | 790 parche cero (si, es el primero en los sistemas que comienzan su conteo |
igor@448 | 791 en cero); el segundo parche es uno y así sucesivamente. |
igor@448 | 792 |
igor@448 | 793 MQ facilita el trabajo cuando está usando órdenes normales de |
igor@448 | 794 Mercurial. Cada comando que acepte Identificadores de conjuntos de |
igor@448 | 795 cambios también aceptará el nombre de un parche aplicado. MQ aumenta |
jerojasro@519 | 796 las etiquetas normalmente en el repositorio con un distintivo para cada |
jerojasro@519 | 797 parche aplicado. Adicionalmente, las etiquetas especiales \index{tags!special tag |
igor@448 | 798 names!\texttt{qbase}}\texttt{qbase} y \index{tags!special tag |
igor@448 | 799 names!\texttt{qtip}}\texttt{qtip} identifican los parches |
igor@448 | 800 ``primero'' y último, respectivamente. |
jerojasro@336 | 801 |
igor@449 | 802 Junto con las capacidades de Mercurial para etiquetar, estas adiciones |
igor@449 | 803 hacen que trabajar con parches sea muy sencillo. |
jerojasro@336 | 804 \begin{itemize} |
igor@449 | 805 \item ¿Desea enviar una bomba de parches a una lista de correo con los |
igor@449 | 806 últimos cambios que ha hecho? |
jerojasro@336 | 807 \begin{codesample4} |
jerojasro@336 | 808 hg email qbase:qtip |
jerojasro@336 | 809 \end{codesample4} |
igor@449 | 810 (¿No sabe qué es una ``bomba de parches''? Consulte la |
igor@449 | 811 sección~\ref{sec:hgext:patchbomb}.) |
igor@449 | 812 \item ¿Desea ver todos los parches desde que se aplicó |
igor@449 | 813 \texttt{foo.patch} sobre los ficheros de un subdirectorio en su |
igor@449 | 814 árbol? |
jerojasro@336 | 815 \begin{codesample4} |
jerojasro@336 | 816 hg log -r foo.patch:qtip \emph{subdir} |
jerojasro@336 | 817 \end{codesample4} |
jerojasro@336 | 818 \end{itemize} |
jerojasro@336 | 819 |
igor@449 | 820 Dado que MQ nombra los parches disponibles al resto de Mercurial con |
igor@449 | 821 su maquinaria de etiquetas interna, usted no necesita teclear el |
igor@449 | 822 nombre completo de un parche cuando desea identificarlo por su nombre. |
jerojasro@336 | 823 |
jerojasro@336 | 824 \begin{figure}[ht] |
jerojasro@336 | 825 \interaction{mq.id.output} |
igor@449 | 826 \caption{Uso de las características de etiquetamiento al trabajar |
igor@449 | 827 con MQ} |
jerojasro@336 | 828 \label{ex:mq:id} |
jerojasro@336 | 829 \end{figure} |
jerojasro@336 | 830 |
igor@449 | 831 Otra consecuencia deseable al representar los nombres de parches como |
igor@449 | 832 etiquetas es que cuando ejecute la orden \hgcmd{log}, desplegará el |
igor@449 | 833 nombre del parche como una etiqueta, usualmente con la salida normal. |
igor@449 | 834 Esto facilita distinguir visualmente los parches aplicados de las |
igor@449 | 835 revisiones ``normales''. La figura~\ref{ex:mq:id} muestra algunos |
igor@449 | 836 comandos usuales de Mercurial al trabajar con parches. |
igor@449 | 837 |
igor@449 | 838 \section{Otra información útil} |
igor@449 | 839 |
igor@449 | 840 Hay una cantidad de aspectos que hacen que el uso de MQ no representen |
igor@449 | 841 secciones en sí mismas, pero de los cuales es bueno estar |
igor@449 | 842 enterado. Los presentamos en aquí: |
jerojasro@336 | 843 |
jerojasro@336 | 844 \begin{itemize} |
igor@449 | 845 \item Usualmente cuando hace \hgxcmd{mq}{qpop} a un parche y vuelve a |
igor@449 | 846 hacerle \hgxcmd{mq}{qpush}, el conjunto de cambios que representa el |
igor@449 | 847 parche después de introducir/sustraer tendrá una \emph{identidad |
igor@449 | 848 distinta} que aquella que representaba el conjunto de cambios |
igor@449 | 849 anteriormente. Consulte la secctión~\ref{sec:mqref:cmd:qpush} para |
igor@449 | 850 obtener información del por qué de esto. |
igor@449 | 851 \item No es una buena idea aplicar \hgcmd{merge} de cambios de otra |
igor@449 | 852 rama con un conjunto de cambios de parches, por lo menos si desea |
igor@449 | 853 mantener la ``información de parches'' de ese conjunto de cambios y |
igor@449 | 854 los conjuntos de cambios que se encuentran por debajo en la pila de |
igor@449 | 855 parches. Si intenta hacerlo, parecerá que ha sido exitoso, pero MQ |
igor@449 | 856 se confundirá. |
jerojasro@336 | 857 \end{itemize} |
jerojasro@336 | 858 |
igor@449 | 859 \section{Administrar parches en un repositorio} |
jerojasro@336 | 860 \label{sec:mq:repo} |
jerojasro@336 | 861 |
igor@449 | 862 Dado que el directorio \sdirname{.hg/patches} de MQ reside fuera del |
igor@449 | 863 repositorio de trabajo de Mercurial, el repositorio ``subyacente'' de |
igor@449 | 864 Mercurial no sabe nada acerca de la administración o presencia de |
igor@449 | 865 parches. |
igor@449 | 866 |
igor@449 | 867 Esto presenta la interesante posibilidad de administrar los contenidos |
jerojasro@517 | 868 del directorio de parches como un repositorio de Mercurial por su |
igor@449 | 869 cuenta. Puede ser una forma útil de trabajar. Por ejemplo, puede |
igor@449 | 870 trabajar en un parche por un rato, hacerle \hgxcmd{mq}{qrefresh} y |
igor@449 | 871 después hacer \hgcmd{commit} al estado actual del parche. Esto le |
igor@449 | 872 permite ``devolverse'' a esa versión del parche posteriormente. |
igor@449 | 873 |
igor@449 | 874 Puede también compartir diferentes versiones de la misma pila de |
igor@449 | 875 parches entre varios repositorios subyacentes. Uso esto cuando estoy |
igor@449 | 876 desarrollando una característica del núcleo Linux. Tengo una copia |
igor@449 | 877 original de las fuentes del núcleo para varias arquitecturas, y cloné |
igor@449 | 878 un rpositorio en cada una que contiene los parches en los cuales |
igor@449 | 879 estoy trabajando. Cuando quiero probar un cambio en una arquitectura |
igor@449 | 880 diferente, introduzco mis parches actuales al repositorio de parches |
igor@449 | 881 asociado con el árbol del kernel, sustraigo e introduzco todos mis |
igor@449 | 882 parches, armo y pruebo el núcleo. |
igor@449 | 883 |
igor@449 | 884 Llevar los parches en un repositorio permite que varios |
igor@449 | 885 desarrolladores puedan trabajar en la misma serie de parches sin |
jerojasro@526 | 886 sobreponerse, todo sobre la fuente base subyacente que pueden o no |
igor@449 | 887 controlar. |
igor@449 | 888 |
igor@449 | 889 \subsection{Soporte de MQ para repositorios de parches} |
igor@449 | 890 |
igor@449 | 891 MQ le ayuda a trabajar con el directorio \sdirname{.hg/patches} como |
igor@449 | 892 un repositorio; cuando usted prepara un repositorio para trabajar con |
igor@449 | 893 parches usando \hgxcmd{mq}{qinit}, puede pasarle la opción |
igor@449 | 894 \hgxopt{mq}{qinit}{-c} para que se cree el directorio |
igor@449 | 895 \sdirname{.hg/patches} como un repositorio de Mercurial. |
jerojasro@336 | 896 |
jerojasro@336 | 897 \begin{note} |
igor@449 | 898 Si olvida usar la opción \hgxopt{mq}{qinit}{-c} option, puede ir al |
igor@449 | 899 directorio \sdirname{.hg/patches} en cualquier momento y ejecutar |
igor@449 | 900 \hgcmd{init}. No olvide añadir una entrada en el fichero |
igor@449 | 901 \sfilename{status} del fichero \sfilename{.hgignore}, a pesar de que |
igor@449 | 902 (\hgcmdargs{qinit}{\hgxopt{mq}{qinit}{-c}} hace estodo de forma |
igor@449 | 903 automática para usted); usted \emph{seguro} no quiere administrar el |
jerojasro@522 | 904 fichero \sfilename{status}. |
jerojasro@336 | 905 \end{note} |
jerojasro@336 | 906 |
igor@449 | 907 MQ nota convenientemente que el directorio \dirname{.hg/patches} |
igor@449 | 908 es un repositorio, hará \hgcmd{add} automáticamente a cada parche que |
igor@449 | 909 usted cree e importe. |
igor@449 | 910 |
igor@449 | 911 MQ provee una orden corta, \hgxcmd{mq}{qcommit}, que ejecuta |
igor@449 | 912 \hgcmd{commit} en el directorio \sdirname{.hg/patches}. Lo que ahorra |
igor@449 | 913 tecleo recurrente. |
igor@449 | 914 |
igor@449 | 915 Finalmente, para administrar convenientemente el directorio de |
igor@449 | 916 parches, puede definir el alias \command{mq} en sistemas Unix. Por |
igor@449 | 917 ejemplo, en sistemas Linux con el intérprete \command{bash}, puede |
igor@449 | 918 incluir el siguiente recorte de código\ndt{snippet} en su fichero |
igor@449 | 919 \tildefile{.bashrc}. |
jerojasro@336 | 920 |
jerojasro@336 | 921 \begin{codesample2} |
jerojasro@336 | 922 alias mq=`hg -R \$(hg root)/.hg/patches' |
jerojasro@336 | 923 \end{codesample2} |
jerojasro@336 | 924 |
igor@449 | 925 Puede aplicar las órdenes de la forma \cmdargs{mq}{pull} al |
igor@449 | 926 repositorio principal. |
igor@449 | 927 |
igor@449 | 928 \subsection{Detalles a tener en cuenta} |
igor@449 | 929 |
igor@449 | 930 El soporte de MQ para trabajar con un repositorio de parches es |
igor@449 | 931 limitado en ciertos aspectos: |
igor@449 | 932 |
igor@449 | 933 MQ no puede detectar automáticamente los cambios que haga al |
igor@449 | 934 directorio de parches. Si aplica \hgcmd{pull}, edita manualmente, o |
igor@449 | 935 hace \hgcmd{update} a los parches o el fichero \sfilename{series}, |
igor@449 | 936 tendrá que aplicar \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} y después |
igor@449 | 937 \hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} en el repositorio subyacente |
igor@449 | 938 para que los cambios se reflejen allí. Si olvida hacerlo, puede |
igor@449 | 939 confundir a MQ en cuanto a qué parches se han aplicado. |
igor@449 | 940 |
igor@449 | 941 \section{Otras herramientas para trabajar con parches} |
jerojasro@336 | 942 \label{sec:mq:tools} |
jerojasro@336 | 943 |
igor@449 | 944 Cuando haya trabajado por cierto tiempo con parches, deseará |
igor@449 | 945 herramientas que le ayuden a entender y manipular los parches con los |
igor@449 | 946 que esté tratando. |
igor@449 | 947 |
igor@449 | 948 La orden \command{diffstat}~\cite{web:diffstat} genera un histograma |
igor@449 | 949 de modificaciones hechas a cada fichero en un parche. Provee una |
igor@449 | 950 interesante forma de ``dar un vistazo'' al parche---qué ficheros |
igor@449 | 951 afecta, y cuántos cambios introduce a cada fichero y en total. (Me ha |
igor@449 | 952 parecido interesante usar la opción \cmdopt{diffstat}{-p} de |
igor@449 | 953 \command{diffstat}, puesto que de otra forma intentará hacer cosas |
igor@449 | 954 inteligentes con prefijos de ficheros que terminan confundiéndome.) |
jerojasro@336 | 955 |
jerojasro@336 | 956 \begin{figure}[ht] |
jerojasro@336 | 957 \interaction{mq.tools.tools} |
igor@449 | 958 \caption{Las órdenes \command{diffstat}, \command{filterdiff}, y \command{lsdiff}} |
jerojasro@336 | 959 \label{ex:mq:tools} |
jerojasro@336 | 960 \end{figure} |
jerojasro@336 | 961 |
igor@449 | 962 El paquete \package{patchutils}~\cite{web:patchutils} es |
igor@449 | 963 invaluable. Provee un conjunto de pequeñas utilidades que siguen la |
igor@449 | 964 ``filosofía Unix''; cada una hace una cosa muy bien hecha a un |
igor@449 | 965 parche. La orden \package{patchutils} que más uso es |
igor@449 | 966 \command{filterdiff}, que extrae subconjuntos de un fichero de |
igor@449 | 967 parche. Por ejemplo, dado un parche que modifica centenas de ficheros |
igor@449 | 968 en docenas de directorios, una única invocación de |
igor@449 | 969 \command{filterdiff} puede generear un parche más pequeño que |
igor@449 | 970 solamente toca aquellos ficheros con un patrón. Puede ver otro |
igor@449 | 971 ejemplo en la sección~\ref{mq-collab:tips:interdiff}. |
igor@449 | 972 |
igor@449 | 973 \section{Buenas prácticas de trabajo con parches} |
igor@449 | 974 |
igor@449 | 975 En caso de que esté trabajando en una serie de parches para enviar a |
igor@449 | 976 un proyecto de software libre o de fuentes abiertas, o en una serie |
igor@449 | 977 que desea tratar como un conjunto de cambios regular, cuando haya |
igor@449 | 978 terminado, puede usar técnicas sencillas para mantener su trabajo bien |
igor@449 | 979 organizado. |
igor@449 | 980 |
igor@449 | 981 De nombres descriptivos a sus parches. Un buen nombre para un parche |
igor@449 | 982 podría ser \filename{rework-device-alloc.patch}, porque da de forma |
igor@449 | 983 inmediata una pista del propósito del parche. Los nombres largos no |
igor@449 | 984 deben ser un problema; no los estará tecleando repetidamente, pero |
igor@449 | 985 \emph{estará} ejecutando regularmente órdenes como |
igor@449 | 986 \hgxcmd{mq}{qapplied} y \hgxcmd{mq}{qtop}. Los nombres adecuados son |
igor@449 | 987 especialmente importantes cuando tiene bastantes parches con los |
igor@449 | 988 cuales trabajar, o si está trabajando en diferentes tareas y sus |
igor@449 | 989 parches toman solamente una porción de su atención. |
igor@449 | 990 |
igor@449 | 991 Tenga en cuenta en qué parche está trabajando. Use la orden \hgxcmd{mq}{qtop} |
igor@449 | 992 para dar un vistazo al texto de sus parches frecuentemente---por |
igor@449 | 993 ejemplo, use \hgcmdargs{tip}{\hgopt{tip}{-p}})---para asegurarse en |
igor@449 | 994 dónde está ubicado. En distintas oportunidades me sucedió que apliqué |
igor@449 | 995 \hgxcmd{mq}{qrefresh} a un parche distinto al que deseaba hacerlo, y |
igor@449 | 996 usualmente es complejo migrar los cambios al parche correcto después |
igor@449 | 997 de haberlo hecho mal. |
igor@449 | 998 |
igor@449 | 999 Por este motivo, vale la pena invertir ese poco tiempo para aprender |
igor@449 | 1000 cómo usar otras herramientas que describí en la |
igor@449 | 1001 sección~\ref{sec:mq:tools}, particularmente \command{diffstat} y |
igor@449 | 1002 \command{filterdiff}. La primera le dará una idea de qué cambios está |
igor@449 | 1003 haciendo su parche, mientras que la segunda permite seleccionar trozos |
igor@449 | 1004 de un parche para colocarlos en otro. |
igor@449 | 1005 |
igor@449 | 1006 \section{Recetas de MQ} |
igor@449 | 1007 |
igor@449 | 1008 \subsection{Administrar parches ``triviales''} |
igor@449 | 1009 |
igor@449 | 1010 Puesto que colocar ficheros en un repositorio de Mercurial es tan |
igor@449 | 1011 sencillo, tiene bastante sentido administrar parches de esta forma |
igor@449 | 1012 incluso si desea hacer algunos cambios al paquete de ficheros que |
igor@449 | 1013 descargó. |
igor@449 | 1014 |
igor@449 | 1015 Para comenzar a descargar y desempaqueter un paquete de ficheros, y |
igor@449 | 1016 volverlo en un repositorio de Mercurial: |
jerojasro@336 | 1017 \interaction{mq.tarball.download} |
jerojasro@336 | 1018 |
igor@449 | 1019 Continue creando una pila de parches y haga sus cambios. |
jerojasro@336 | 1020 \interaction{mq.tarball.qinit} |
jerojasro@336 | 1021 |
igor@449 | 1022 Digamos que pasan unas semanas o meses, y el autor del paquete libera |
igor@449 | 1023 una nueva versión. Primero se traen sus cambios al repositorio. |
jerojasro@336 | 1024 \interaction{mq.tarball.newsource} |
igor@449 | 1025 La porción que comienza con \hgcmd{locate} mostrada más arriba, borra |
igor@449 | 1026 todos los ficheros en el directorio de trabajo, así que la opción |
igor@449 | 1027 \hgopt{commit}{--addremove} de \hgcmd{commit} puede indicar qué |
igor@449 | 1028 ficheros se han eliminado en la nueva versión del árbol de fuentes. |
igor@449 | 1029 |
igor@449 | 1030 Finalmente, puede aplicar sus parches encima del nuevo árbol de fuentes |
jerojasro@336 | 1031 \interaction{mq.tarball.repush} |
jerojasro@336 | 1032 |
igor@449 | 1033 \subsection{Combinar parches completos} |
jerojasro@336 | 1034 \label{sec:mq:combine} |
jerojasro@336 | 1035 |
igor@449 | 1036 MQ provee la orden \hgxcmd{mq}{qfold} que le permite combinar parches |
igor@449 | 1037 enteros. Se ``integran''\ndt{fold} los parches que usted nombre, en |
igor@449 | 1038 el orden que especifique, en el último parche aplicado, y concatena |
igor@449 | 1039 sus descripciones al final de su descripción. Deberá sustraer los |
igor@449 | 1040 cambios para poder integrarlos. |
igor@449 | 1041 |
igor@449 | 1042 El orden en el que integre los parches importa. Si el parche |
igor@449 | 1043 últimamente aplicado es \texttt{foo}, e integra \hgxcmd{mq}{qfold} \texttt{bar} y |
igor@449 | 1044 \texttt{quux} en él, terminará con un parche que tiene el mismo efecto |
igor@449 | 1045 que si hubiera aplicado primero \texttt{foo}, y después \texttt{bar}, |
igor@449 | 1046 seguido de \texttt{quux}. |
igor@449 | 1047 |
igor@449 | 1048 \subsection{Fusionar una porción de un parche dentro de otro} |
igor@449 | 1049 |
igor@449 | 1050 Fusionar \emph{partes} de un parche dentro de otro es más complejo que |
igor@449 | 1051 combinar completamente dos parches. |
igor@449 | 1052 |
igor@449 | 1053 Si desea mover cambios de ficheros completos, puede usar las opciones |
igor@449 | 1054 \command{filterdiff}'s \cmdopt{filterdiff}{-i} y |
igor@449 | 1055 \cmdopt{filterdiff}{-x} para elegir las modificaciones remover de un |
igor@449 | 1056 parche, concatenar su salida al final del parche donde desea |
igor@449 | 1057 fusionarlo. Usualmente no necesitará modificar el parche del cuál ha |
igor@449 | 1058 fusionado los cambios. En cambio, MQ reportará que hay unos trozos |
jerojasro@480 | 1059 que se han desechado cuando usted aplique \hgxcmd{mq}{qpush} (de los |
igor@449 | 1060 trozos que haya movido al otro parche), y puede sencillamente aplicar |
igor@449 | 1061 \hgxcmd{mq}{qrefresh} para eliminar los trozos replicados. |
igor@449 | 1062 |
igor@449 | 1063 Si tiene un parche que tiene varios trozos que modifican un fichero, y |
igor@449 | 1064 desea mover solamente unos de ellos, el trabajo es un poco más |
igor@449 | 1065 enredado, pero puede automatizarlo parcialmente. Use |
igor@449 | 1066 \cmdargs{lsdiff}{-nvv} para imprimir algunos metadatos del parche. |
jerojasro@336 | 1067 \interaction{mq.tools.lsdiff} |
jerojasro@336 | 1068 |
igor@449 | 1069 Esta orden imprime tres clases diferentes de números: |
jerojasro@336 | 1070 \begin{itemize} |
igor@449 | 1071 \item (en la primera columna) un \emph{número de fichero} para |
igor@449 | 1072 identificar cada fichero modificado en el parche; |
igor@449 | 1073 \item (En la siguiente línea, indentado) el número de línea dentro de |
igor@449 | 1074 un fichero modificado donde comienza el trozo; y |
igor@449 | 1075 \item (en la misma línea) un \emph{número de trozo} que identifica el |
igor@449 | 1076 trozo. |
jerojasro@336 | 1077 \end{itemize} |
jerojasro@336 | 1078 |
igor@449 | 1079 Tendrá que hacer una inspección visual, y leer el parche para |
igor@449 | 1080 identificar los números de fichero y trozo que desea, pero puede pasar |
igor@449 | 1081 posteriormente a las opciones \cmdopt{filterdiff}{--files} y |
igor@449 | 1082 \cmdopt{filterdiff}{--hunks} de \command{filterdiff}, para seleccionar |
igor@449 | 1083 exactamente el fichero y el trozo que desea extraer. |
igor@449 | 1084 |
igor@449 | 1085 Cuando tenga el trozo, puede concatenarlo al final de su parche |
igor@449 | 1086 objetivo y continuar como en la sección~\ref{sec:mq:combine}. |
igor@449 | 1087 |
igor@449 | 1088 \section{Diferencias entre quilt y MQ} |
igor@449 | 1089 |
igor@449 | 1090 Si le es familiar quilt, MQ provee un conjunto similar de órdenes. Hay |
igor@449 | 1091 algunas diferencias en cómo funcionan. |
igor@449 | 1092 |
igor@449 | 1093 Debe haber notado que la mayoría de comandos de quilt tienen su |
igor@449 | 1094 contraparte en MQ, que simplemente comienzan con ``\texttt{q}''. Las |
igor@449 | 1095 excepciones son las órdenes \texttt{add} y \texttt{remove} de quilt, |
igor@449 | 1096 que realmente son las órdenes \hgcmd{add} y \hgcmd{remove} de |
igor@449 | 1097 Mercurial. No hay un equivalente en MQ para la orden |
igor@449 | 1098 \texttt{edit} de quilt. |
jerojasro@336 | 1099 |
jerojasro@336 | 1100 %%% Local Variables: |
jerojasro@336 | 1101 %%% mode: latex |
jerojasro@336 | 1102 %%% TeX-master: "00book" |
jerojasro@336 | 1103 %%% End: |