hgbook
changeset 485:039ed6f5935b
translated a section
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Mon Jan 05 23:55:35 2009 -0500 (2009-01-05) |
parents | 527b274d237c |
children | d1962e8a986f |
files | es/Leame.1st es/mq-collab.tex |
line diff
1.1 --- a/es/Leame.1st Mon Jan 05 23:55:22 2009 -0500 1.2 +++ b/es/Leame.1st Mon Jan 05 23:55:35 2009 -0500 1.3 @@ -109,8 +109,8 @@ 1.4 || mq.tex || Igor Támara || 100% || 06/12/2008 || 13/12/2008 || 1.5 || hgext.tex || Igor Támara || 100% || 13/12/2008 || 16/12/2008 || 1.6 || template.tex || Igor Támara || 100% || 27/12/2008 || 01/01/2009 || 1.7 -|| mq-collab.tex || Javier Rojas || 10% || 04/01/2009 || || 1.8 -|| mq-ref.tex || Javier Rojas || || || || 1.9 +|| mq-collab.tex || Javier Rojas || 20% || 04/01/2009 || || 1.10 +|| mq-ref.tex || || || || || 1.11 || cmdref.tex || Igor Támara || 100% || 01/01/2009 || 01/01/2009 || 1.12 || license.tex || Igor Támara || 100% || 16/12/2008 || 16/12/2008 || 1.13 || srcinstall.tex || Igor Támara || 100% || 01/01/2009 || 01/01/2009 || 1.14 @@ -476,6 +476,7 @@ 1.15 usó el autor (y rogar que él no haya sido inconsistente :P) 1.16 * armar - compilar - construir. Build, compile. Más que todo "build" 1.17 * daemonio - demonio. daemon 1.18 + * kernel - núcleo. 1.19 1.20 = Notas del traductor = 1.21 Por favor use el comando \ndt para insertar notas del traductor. Este
2.1 --- a/es/mq-collab.tex Mon Jan 05 23:55:22 2009 -0500 2.2 +++ b/es/mq-collab.tex Mon Jan 05 23:55:35 2009 -0500 2.3 @@ -57,38 +57,44 @@ 2.4 Hay dos maneras estándar de mantener una porción de software que debe 2.5 funcionar en muchos entornos diferentes. 2.6 2.7 -The first is to maintain a number of branches, each intended for a 2.8 -single target. The trouble with this approach is that you must 2.9 -maintain iron discipline in the flow of changes between repositories. 2.10 -A new feature or bug fix must start life in a ``pristine'' repository, 2.11 -then percolate out to every backport repository. Backport changes are 2.12 -more limited in the branches they should propagate to; a backport 2.13 -change that is applied to a branch where it doesn't belong will 2.14 -probably stop the driver from compiling. 2.15 - 2.16 -The second is to maintain a single source tree filled with conditional 2.17 -statements that turn chunks of code on or off depending on the 2.18 -intended target. Because these ``ifdefs'' are not allowed in the 2.19 -Linux kernel tree, a manual or automatic process must be followed to 2.20 -strip them out and yield a clean tree. A code base maintained in this 2.21 -fashion rapidly becomes a rat's nest of conditional blocks that are 2.22 -difficult to understand and maintain. 2.23 - 2.24 -Neither of these approaches is well suited to a situation where you 2.25 -don't ``own'' the canonical copy of a source tree. In the case of a 2.26 -Linux driver that is distributed with the standard kernel, Linus's 2.27 -tree contains the copy of the code that will be treated by the world 2.28 -as canonical. The upstream version of ``my'' driver can be modified 2.29 -by people I don't know, without me even finding out about it until 2.30 -after the changes show up in Linus's tree. 2.31 - 2.32 -These approaches have the added weakness of making it difficult to 2.33 -generate well-formed patches to submit upstream. 2.34 - 2.35 -In principle, Mercurial Queues seems like a good candidate to manage a 2.36 -development scenario such as the above. While this is indeed the 2.37 -case, MQ contains a few added features that make the job more 2.38 -pleasant. 2.39 +La primera es mantener varias ramas, cada una pensada para un único 2.40 +entorno. El problema de esta aproximación es que usted debe tener una 2.41 +disciplina férrea con el flujo de cambios entre repositorios. Una 2.42 +nueva característica o un arreglo de fallo deben empezar su vida en un 2.43 +repositorio ``prístino'', y luego propagarse a cada repositorio de 2.44 +backport. Los cambios para backports están más limitados respecto a 2.45 +las ramas a las que deberían propagarse; un cambio para backport que 2.46 +es aplicado a una rama en la que no corresponde probablemente hará que 2.47 +el controlador no compile. 2.48 + 2.49 +La segunda es mantener un único árbol de código fuente lleno de 2.50 +declaraciones que activen o desactiven secciones de código dependiendo 2.51 +del entorno objetivo. Ya que estos ``ifdefs'' no están permitidos en 2.52 +el árbol del kernel de Linux, debe seguirse algún proceso manual o 2.53 +automático para eliminarlos y producir un árbol limpio. Una base de 2.54 +código mantenida de esta manera se convierte rápidamente en un nido de 2.55 +ratas de bloques condicionales que son difíciles de entender y 2.56 +mantener. 2.57 + 2.58 +%TODO canónica? 2.59 +Ninguno de estos enfoques es adecuado para situaciones en las que 2.60 +usted no es ``dueño'' de la copia canónica de un árbol de fuentes. En 2.61 +el caso de un controlador de Linux que es distribuido con el kernel 2.62 +estándar, el árbol de Linux contiene la copia del código que será 2.63 +considerada por el mundo como la canónica. La versión oficial de 2.64 +``mi'' controlador puede ser modificada por gente que no conozco, sin 2.65 +que yo siquiera me entere de ello hasta después de que los cambios 2.66 +aparecen en el árbol de Linus. 2.67 + 2.68 +Estos enfoques tienen la debilidad adicional de dificultar la 2.69 +%TODO upstream. no no es río arriba 2.70 +generación de parches bien formados para enviarlos a la versión 2.71 +oficial. 2.72 + 2.73 +En principio, las Colas de Mercurial parecen ser un buen candidato 2.74 +para administrar un escenario de desarrollo como el de arriba. Aunque 2.75 +este es de hecho el caso, MQ tiene unas cuantas características 2.76 +adicionales que hacen el trabajo más agradable. 2.77 2.78 \section{Conditionally applying patches with 2.79 guards}