hgbook
diff es/mq.tex @ 447:93e7700c0322
Some more mq paragraphs translated
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Wed Dec 10 22:51:01 2008 -0500 (2008-12-10) |
parents | 40ba5d8583c7 |
children | c17848cfbf75 |
line diff
1.1 --- a/es/mq.tex Mon Dec 08 23:53:54 2008 -0500 1.2 +++ b/es/mq.tex Wed Dec 10 22:51:01 2008 -0500 1.3 @@ -594,105 +594,111 @@ 1.4 \end{itemize} 1.5 \subsection{Cuidado con los difusos} 1.6 1.7 -While applying a hunk at an offset, or with a fuzz factor, will often 1.8 -be completely successful, these inexact techniques naturally leave 1.9 -open the possibility of corrupting the patched file. The most common 1.10 -cases typically involve applying a patch twice, or at an incorrect 1.11 -location in the file. If \command{patch} or \hgxcmd{mq}{qpush} ever 1.12 -mentions an offset or fuzz factor, you should make sure that the 1.13 -modified files are correct afterwards. 1.14 - 1.15 -It's often a good idea to refresh a patch that has applied with an 1.16 -offset or fuzz factor; refreshing the patch generates new context 1.17 -information that will make it apply cleanly. I say ``often,'' not 1.18 -``always,'' because sometimes refreshing a patch will make it fail to 1.19 -apply against a different revision of the underlying files. In some 1.20 -cases, such as when you're maintaining a patch that must sit on top of 1.21 -multiple versions of a source tree, it's acceptable to have a patch 1.22 -apply with some fuzz, provided you've verified the results of the 1.23 -patching process in such cases. 1.24 - 1.25 -\subsection{Handling rejection} 1.26 - 1.27 -If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error 1.28 -message and exit. If it has left \sfilename{.rej} files behind, it is 1.29 -usually best to fix up the rejected hunks before you push more patches 1.30 -or do any further work. 1.31 - 1.32 -If your patch \emph{used to} apply cleanly, and no longer does because 1.33 -you've changed the underlying code that your patches are based on, 1.34 -Mercurial Queues can help; see section~\ref{sec:mq:merge} for details. 1.35 - 1.36 -Unfortunately, there aren't any great techniques for dealing with 1.37 -rejected hunks. Most often, you'll need to view the \sfilename{.rej} 1.38 -file and edit the target file, applying the rejected hunks by hand. 1.39 - 1.40 -If you're feeling adventurous, Neil Brown, a Linux kernel hacker, 1.41 -wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more 1.42 -vigorous than \command{patch} in its attempts to make a patch apply. 1.43 - 1.44 -Another Linux kernel hacker, Chris Mason (the author of Mercurial 1.45 -Queues), wrote a similar tool called 1.46 -\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to 1.47 -automating the application of hunks rejected by \command{patch}. The 1.48 -\command{mpatch} command can help with four common reasons that a hunk 1.49 -may be rejected: 1.50 +Cuando aplique un trozo con un corrimiento, o con un factor difuso, 1.51 +aveces será taotalmente exitoso, tales técnicas inexactas dejan 1.52 +claramente la posibilidad de corromper el archivo parchado. Los casos 1.53 +más típicos involucran aplicar un parche dos veces o en un sitio 1.54 +incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan 1.55 +a mencionar un corrimiento o un factor difuso, debería asegurarse que 1.56 +los ficheros modificados estén correctos después del suceso. 1.57 + 1.58 +Casi siempre es buena idea refrescar un parche que fue aplicado con un 1.59 +corrimiento o un factor difuso; refrescar el parche genera nueva 1.60 +información de contexto que permitirá aplicarlo limpiamente. Digo 1.61 +``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones 1.62 +refrescar un parche lo hará fallar frente a una revisión diferente del 1.63 +fichero. En algunos casos, como por ejemplo, cuando usted está 1.64 +manteniendo un parche que debe estar encima de múltiples revisiones de 1.65 +un árbol de fuentes, es aceptable tener un parche aplicado algo 1.66 +difuso, siempre que haya verificado los resultados del proceso de 1.67 +parchar. 1.68 + 1.69 +\subsection{Manejo de descartes} 1.70 + 1.71 +Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de 1.72 +error y saldrá. Si ha dejado ficheros \sfilename{.rej}, es mejor 1.73 +arreglar los trozos descartados antes de introducir parches 1.74 +adicionales o hacer cualquier otra cosa. 1.75 + 1.76 +Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace 1.77 +porque ha cambiado código subyacente en el cual se basa su parche, las 1.78 +Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}. 1.79 + 1.80 +Desafortunadamente, no hay grandes técnicas para tratar los trozos 1.81 +descartados. Casi siempre deberá consultar el fichero 1.82 +\sfilename{.rej} y editar el fichero objetivo, aplicando los trozos 1.83 +descartados a mano. 1.84 + 1.85 +Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una 1.86 +herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más 1.87 +vigorosa que \command{patch} en su intento de hacer que se aplique un 1.88 +parche. 1.89 + 1.90 +Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de 1.91 +Mercurial), escribió una herramienta similar llamada 1.92 +\command{mpatch}~\cite{web:mpatch}, que sigue una aproximación 1.93 +sencilla para automatizar la aplicación de trozos descartados por 1.94 +\command{patch}. La orden \command{mpatch} puede ayudar con cuatro 1.95 +razones comunes por las cuales un parche ha sido descartado: 1.96 1.97 \begin{itemize} 1.98 -\item The context in the middle of a hunk has changed. 1.99 -\item A hunk is missing some context at the beginning or end. 1.100 -\item A large hunk might apply better---either entirely or in 1.101 - part---if it was broken up into smaller hunks. 1.102 -\item A hunk removes lines with slightly different content than those 1.103 - currently present in the file. 1.104 +\item El contexto en la mitad de un trozo ha cambiado. 1.105 +\item Un trozo ha perdido cierto contexto al principio o al final. 1.106 +\item Un trozo largo podría aplicarse mejor---por completo o una 1.107 + parte---si estaba cortado en trozos más pequeños. 1.108 +\item Un trozo remueve líneas con contenido ligeramente diferente que 1.109 + aquellas que están presentes en el fichero. 1.110 \end{itemize} 1.111 1.112 -If you use \command{wiggle} or \command{mpatch}, you should be doubly 1.113 -careful to check your results when you're done. In fact, 1.114 -\command{mpatch} enforces this method of double-checking the tool's 1.115 -output, by automatically dropping you into a merge program when it has 1.116 -done its job, so that you can verify its work and finish off any 1.117 -remaining merges. 1.118 - 1.119 -\section{Getting the best performance out of MQ} 1.120 +Si usted usa \command{wiggle} o \command{mpatch}, debería ser 1.121 +doblemente cuidadoso al revisar sus resultados cuando haya terminado. 1.122 +De hecho, \command{mpatch} refuerza este método de revisar por partida 1.123 +doble su salida, dejándolo a usted en un programa de fusión cuando la 1.124 +herramienta haya terminado su trabajo, de tal forma que usted pueda 1.125 +verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión 1.126 +faltante. 1.127 + 1.128 +\section{Contar con el máximo rendimiento de MQ} 1.129 \label{sec:mq:perf} 1.130 1.131 -MQ is very efficient at handling a large number of patches. I ran 1.132 -some performance experiments in mid-2006 for a talk that I gave at the 1.133 -2006 EuroPython conference~\cite{web:europython}. I used as my data 1.134 -set the Linux 2.6.17-mm1 patch series, which consists of 1,738 1.135 -patches. I applied these on top of a Linux kernel repository 1.136 -containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux 1.137 -2.6.17. 1.138 - 1.139 -On my old, slow laptop, I was able to 1.140 -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes, 1.141 -and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds. (On a 1.142 -newer laptop, the time to push all patches dropped to two minutes.) I 1.143 -could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779 1.144 -lines of changes to 287 files) in 6.6 seconds. 1.145 - 1.146 -Clearly, MQ is well suited to working in large trees, but there are a 1.147 -few tricks you can use to get the best performance of it. 1.148 - 1.149 -First of all, try to ``batch'' operations together. Every time you 1.150 -run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working 1.151 -directory once to make sure you haven't made some changes and then 1.152 -forgotten to run \hgxcmd{mq}{qrefresh}. On a small tree, the time that 1.153 -this scan takes is unnoticeable. However, on a medium-sized tree 1.154 -(containing tens of thousands of files), it can take a second or more. 1.155 - 1.156 -The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop 1.157 -multiple patches at a time. You can identify the ``destination 1.158 -patch'' that you want to end up at. When you \hgxcmd{mq}{qpush} with a 1.159 -destination specified, it will push patches until that patch is at the 1.160 -top of the applied stack. When you \hgxcmd{mq}{qpop} to a destination, MQ 1.161 -will pop patches until the destination patch is at the top. 1.162 - 1.163 -You can identify a destination patch using either the name of the 1.164 -patch, or by number. If you use numeric addressing, patches are 1.165 -counted from zero; this means that the first patch is zero, the second 1.166 -is one, and so on. 1.167 +MQ es muy eficiente al tratar con una gran cantidad de parches. Corrí 1.168 +unos experimentos de desempeño a mediados del 2006 para una charla que 1.169 +dí en la conferencia EuroPython 2006~\cite{web:europython}. Empleé la 1.170 +serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738 1.171 +parches. Los apliqué sobre un repositorio del núcleo de Linux con 1.172 +todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17. 1.173 + 1.174 +En mi viejo y lento portátil, logré aplicar 1.175 +\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5 1.176 +minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos. 1.177 +(En un portátil más nuevo, el tiempo para introducir todos los 1.178 +parches, se logró en menos de dos minutos.) Apliqué 1.179 +\hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes(que hizo 1.180 +22.779 líneas de cambios en 287 ficheros) en 6,6 segundos. 1.181 + 1.182 +Claramente, MQ funciona adecuadamente en árboles grandes, y además hay 1.183 +unos trucos que pueden emplearse para obtener el máximo desempeño. 1.184 + 1.185 +En primer lugar, trate de hacer ``en lote'' las operaciones. Cada vez 1.186 +que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes 1.187 +revisan el directorio de trabajo para asegurarse de que usted no ha 1.188 +hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}. En un 1.189 +árbol pequeño, el tiempo de esta revisión puede ser mínimo, Pero en 1.190 +un árbol mediano(con decenas de miles de ficheros), puede tomar un 1.191 +segundo o más. 1.192 + 1.193 +Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten 1.194 +introducir o sustraer varios parches en una operación. Puede 1.195 +identificar el ``parche destino'' que desee. Cuando aplique 1.196 +\hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea 1.197 +necesario hasta que el especificado esté en el tope de la pila. 1.198 +Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches 1.199 +hasta que el parche destino esté en el tope. 1.200 + 1.201 +Puede identificar un parche destino con el nombre del parche o con el 1.202 +número. Si se refiere al número, los parches se contarán desde cero; 1.203 +esto significa que el primer parche es cero, el segundo es uno y así 1.204 +sucesivamente. 1.205 1.206 \section{Updating your patches when the underlying code changes} 1.207 \label{sec:mq:merge}