hgbook
changeset 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 |
files | es/Leame.1st es/mq.tex |
line diff
1.1 --- a/es/Leame.1st Mon Dec 08 23:53:54 2008 -0500 1.2 +++ b/es/Leame.1st Wed Dec 10 22:51:01 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 || 26% || 01/12/2008 || || 1.7 -|| mq.tex || Igor Támara || 53% || 06/12/2008 || || 1.8 +|| mq.tex || Igor Támara || 63% || 06/12/2008 || || 1.9 || hgext.tex || Igor Támara || 0% || || || 1.10 1.11 == Archivos en proceso de revisión ==
2.1 --- a/es/mq.tex Mon Dec 08 23:53:54 2008 -0500 2.2 +++ b/es/mq.tex Wed Dec 10 22:51:01 2008 -0500 2.3 @@ -594,105 +594,111 @@ 2.4 \end{itemize} 2.5 \subsection{Cuidado con los difusos} 2.6 2.7 -While applying a hunk at an offset, or with a fuzz factor, will often 2.8 -be completely successful, these inexact techniques naturally leave 2.9 -open the possibility of corrupting the patched file. The most common 2.10 -cases typically involve applying a patch twice, or at an incorrect 2.11 -location in the file. If \command{patch} or \hgxcmd{mq}{qpush} ever 2.12 -mentions an offset or fuzz factor, you should make sure that the 2.13 -modified files are correct afterwards. 2.14 - 2.15 -It's often a good idea to refresh a patch that has applied with an 2.16 -offset or fuzz factor; refreshing the patch generates new context 2.17 -information that will make it apply cleanly. I say ``often,'' not 2.18 -``always,'' because sometimes refreshing a patch will make it fail to 2.19 -apply against a different revision of the underlying files. In some 2.20 -cases, such as when you're maintaining a patch that must sit on top of 2.21 -multiple versions of a source tree, it's acceptable to have a patch 2.22 -apply with some fuzz, provided you've verified the results of the 2.23 -patching process in such cases. 2.24 - 2.25 -\subsection{Handling rejection} 2.26 - 2.27 -If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error 2.28 -message and exit. If it has left \sfilename{.rej} files behind, it is 2.29 -usually best to fix up the rejected hunks before you push more patches 2.30 -or do any further work. 2.31 - 2.32 -If your patch \emph{used to} apply cleanly, and no longer does because 2.33 -you've changed the underlying code that your patches are based on, 2.34 -Mercurial Queues can help; see section~\ref{sec:mq:merge} for details. 2.35 - 2.36 -Unfortunately, there aren't any great techniques for dealing with 2.37 -rejected hunks. Most often, you'll need to view the \sfilename{.rej} 2.38 -file and edit the target file, applying the rejected hunks by hand. 2.39 - 2.40 -If you're feeling adventurous, Neil Brown, a Linux kernel hacker, 2.41 -wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more 2.42 -vigorous than \command{patch} in its attempts to make a patch apply. 2.43 - 2.44 -Another Linux kernel hacker, Chris Mason (the author of Mercurial 2.45 -Queues), wrote a similar tool called 2.46 -\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to 2.47 -automating the application of hunks rejected by \command{patch}. The 2.48 -\command{mpatch} command can help with four common reasons that a hunk 2.49 -may be rejected: 2.50 +Cuando aplique un trozo con un corrimiento, o con un factor difuso, 2.51 +aveces será taotalmente exitoso, tales técnicas inexactas dejan 2.52 +claramente la posibilidad de corromper el archivo parchado. Los casos 2.53 +más típicos involucran aplicar un parche dos veces o en un sitio 2.54 +incorrecto del fichero. Si \command{patch} o \hgxcmd{mq}{qpush} llegan 2.55 +a mencionar un corrimiento o un factor difuso, debería asegurarse que 2.56 +los ficheros modificados estén correctos después del suceso. 2.57 + 2.58 +Casi siempre es buena idea refrescar un parche que fue aplicado con un 2.59 +corrimiento o un factor difuso; refrescar el parche genera nueva 2.60 +información de contexto que permitirá aplicarlo limpiamente. Digo 2.61 +``casi siempre,'' no ``siempre'', puesto que en ciertas ocasiones 2.62 +refrescar un parche lo hará fallar frente a una revisión diferente del 2.63 +fichero. En algunos casos, como por ejemplo, cuando usted está 2.64 +manteniendo un parche que debe estar encima de múltiples revisiones de 2.65 +un árbol de fuentes, es aceptable tener un parche aplicado algo 2.66 +difuso, siempre que haya verificado los resultados del proceso de 2.67 +parchar. 2.68 + 2.69 +\subsection{Manejo de descartes} 2.70 + 2.71 +Si \hgxcmd{mq}{qpush} falla al aplicar un parche, mostrará un texto de 2.72 +error y saldrá. Si ha dejado ficheros \sfilename{.rej}, es mejor 2.73 +arreglar los trozos descartados antes de introducir parches 2.74 +adicionales o hacer cualquier otra cosa. 2.75 + 2.76 +Si su parche \emph{solía} aplicarse limpiamente, y ya no lo hace 2.77 +porque ha cambiado código subyacente en el cual se basa su parche, las 2.78 +Colas de Mercurial pueden ayudar; consulte la sección~\ref{sec:mq:merge}. 2.79 + 2.80 +Desafortunadamente, no hay grandes técnicas para tratar los trozos 2.81 +descartados. Casi siempre deberá consultar el fichero 2.82 +\sfilename{.rej} y editar el fichero objetivo, aplicando los trozos 2.83 +descartados a mano. 2.84 + 2.85 +Si es aventurero, Neil Brown, un hacker del núcleo Linux, escribió una 2.86 +herramienta llamada \command{wiggle}~\cite{web:wiggle}, que es más 2.87 +vigorosa que \command{patch} en su intento de hacer que se aplique un 2.88 +parche. 2.89 + 2.90 +Otro hacker del nucleo Linux, Chris Mason (el autor de las Colas de 2.91 +Mercurial), escribió una herramienta similar llamada 2.92 +\command{mpatch}~\cite{web:mpatch}, que sigue una aproximación 2.93 +sencilla para automatizar la aplicación de trozos descartados por 2.94 +\command{patch}. La orden \command{mpatch} puede ayudar con cuatro 2.95 +razones comunes por las cuales un parche ha sido descartado: 2.96 2.97 \begin{itemize} 2.98 -\item The context in the middle of a hunk has changed. 2.99 -\item A hunk is missing some context at the beginning or end. 2.100 -\item A large hunk might apply better---either entirely or in 2.101 - part---if it was broken up into smaller hunks. 2.102 -\item A hunk removes lines with slightly different content than those 2.103 - currently present in the file. 2.104 +\item El contexto en la mitad de un trozo ha cambiado. 2.105 +\item Un trozo ha perdido cierto contexto al principio o al final. 2.106 +\item Un trozo largo podría aplicarse mejor---por completo o una 2.107 + parte---si estaba cortado en trozos más pequeños. 2.108 +\item Un trozo remueve líneas con contenido ligeramente diferente que 2.109 + aquellas que están presentes en el fichero. 2.110 \end{itemize} 2.111 2.112 -If you use \command{wiggle} or \command{mpatch}, you should be doubly 2.113 -careful to check your results when you're done. In fact, 2.114 -\command{mpatch} enforces this method of double-checking the tool's 2.115 -output, by automatically dropping you into a merge program when it has 2.116 -done its job, so that you can verify its work and finish off any 2.117 -remaining merges. 2.118 - 2.119 -\section{Getting the best performance out of MQ} 2.120 +Si usted usa \command{wiggle} o \command{mpatch}, debería ser 2.121 +doblemente cuidadoso al revisar sus resultados cuando haya terminado. 2.122 +De hecho, \command{mpatch} refuerza este método de revisar por partida 2.123 +doble su salida, dejándolo a usted en un programa de fusión cuando la 2.124 +herramienta haya terminado su trabajo, de tal forma que usted pueda 2.125 +verificar lo que ha hecho y pueda terminar de aplicar cualquier fusión 2.126 +faltante. 2.127 + 2.128 +\section{Contar con el máximo rendimiento de MQ} 2.129 \label{sec:mq:perf} 2.130 2.131 -MQ is very efficient at handling a large number of patches. I ran 2.132 -some performance experiments in mid-2006 for a talk that I gave at the 2.133 -2006 EuroPython conference~\cite{web:europython}. I used as my data 2.134 -set the Linux 2.6.17-mm1 patch series, which consists of 1,738 2.135 -patches. I applied these on top of a Linux kernel repository 2.136 -containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux 2.137 -2.6.17. 2.138 - 2.139 -On my old, slow laptop, I was able to 2.140 -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes, 2.141 -and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds. (On a 2.142 -newer laptop, the time to push all patches dropped to two minutes.) I 2.143 -could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779 2.144 -lines of changes to 287 files) in 6.6 seconds. 2.145 - 2.146 -Clearly, MQ is well suited to working in large trees, but there are a 2.147 -few tricks you can use to get the best performance of it. 2.148 - 2.149 -First of all, try to ``batch'' operations together. Every time you 2.150 -run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working 2.151 -directory once to make sure you haven't made some changes and then 2.152 -forgotten to run \hgxcmd{mq}{qrefresh}. On a small tree, the time that 2.153 -this scan takes is unnoticeable. However, on a medium-sized tree 2.154 -(containing tens of thousands of files), it can take a second or more. 2.155 - 2.156 -The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop 2.157 -multiple patches at a time. You can identify the ``destination 2.158 -patch'' that you want to end up at. When you \hgxcmd{mq}{qpush} with a 2.159 -destination specified, it will push patches until that patch is at the 2.160 -top of the applied stack. When you \hgxcmd{mq}{qpop} to a destination, MQ 2.161 -will pop patches until the destination patch is at the top. 2.162 - 2.163 -You can identify a destination patch using either the name of the 2.164 -patch, or by number. If you use numeric addressing, patches are 2.165 -counted from zero; this means that the first patch is zero, the second 2.166 -is one, and so on. 2.167 +MQ es muy eficiente al tratar con una gran cantidad de parches. Corrí 2.168 +unos experimentos de desempeño a mediados del 2006 para una charla que 2.169 +dí en la conferencia EuroPython 2006~\cite{web:europython}. Empleé la 2.170 +serie de parches para el núcleo Linux 2.6.17-mm1, que contaba con 1.738 2.171 +parches. Los apliqué sobre un repositorio del núcleo de Linux con 2.172 +todas las 27.472 revisiones entre 2.6.12-rc2 y 2.6.17. 2.173 + 2.174 +En mi viejo y lento portátil, logré aplicar 2.175 +\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} a los 1.738 parches en 3.5 2.176 +minutos, y \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} en 30 segundos. 2.177 +(En un portátil más nuevo, el tiempo para introducir todos los 2.178 +parches, se logró en menos de dos minutos.) Apliqué 2.179 +\hgxcmd{mq}{qrefresh} sobre uno de los parches más grandes(que hizo 2.180 +22.779 líneas de cambios en 287 ficheros) en 6,6 segundos. 2.181 + 2.182 +Claramente, MQ funciona adecuadamente en árboles grandes, y además hay 2.183 +unos trucos que pueden emplearse para obtener el máximo desempeño. 2.184 + 2.185 +En primer lugar, trate de hacer ``en lote'' las operaciones. Cada vez 2.186 +que ejecute \hgxcmd{mq}{qpush} o \hgxcmd{mq}{qpop}, tales órdenes 2.187 +revisan el directorio de trabajo para asegurarse de que usted no ha 2.188 +hecho cambios y ha olvidado ejecutar \hgxcmd{mq}{qrefresh}. En un 2.189 +árbol pequeño, el tiempo de esta revisión puede ser mínimo, Pero en 2.190 +un árbol mediano(con decenas de miles de ficheros), puede tomar un 2.191 +segundo o más. 2.192 + 2.193 +Las órdenes \hgxcmd{mq}{qpush} y \hgxcmd{mq}{qpop} le permiten 2.194 +introducir o sustraer varios parches en una operación. Puede 2.195 +identificar el ``parche destino'' que desee. Cuando aplique 2.196 +\hgxcmd{mq}{qpush} con un destino, introducirá tantos parches como sea 2.197 +necesario hasta que el especificado esté en el tope de la pila. 2.198 +Cuando emplee \hgxcmd{mq}{qpop} con un destino, MQ sustraerá parches 2.199 +hasta que el parche destino esté en el tope. 2.200 + 2.201 +Puede identificar un parche destino con el nombre del parche o con el 2.202 +número. Si se refiere al número, los parches se contarán desde cero; 2.203 +esto significa que el primer parche es cero, el segundo es uno y así 2.204 +sucesivamente. 2.205 2.206 \section{Updating your patches when the underlying code changes} 2.207 \label{sec:mq:merge}