1.1 --- a/es/mq-collab.tex	Mon Jan 05 00:18:31 2009 -0500
     1.2 +++ b/es/mq-collab.tex	Mon Jan 05 23:57:11 2009 -0500
     1.3 @@ -57,38 +57,44 @@
     1.4  Hay dos maneras estándar de mantener una porción de software que debe
     1.5  funcionar en muchos entornos diferentes.
     1.6  
     1.7 -The first is to maintain a number of branches, each intended for a
     1.8 -single target.  The trouble with this approach is that you must
     1.9 -maintain iron discipline in the flow of changes between repositories.
    1.10 -A new feature or bug fix must start life in a ``pristine'' repository,
    1.11 -then percolate out to every backport repository.  Backport changes are
    1.12 -more limited in the branches they should propagate to; a backport
    1.13 -change that is applied to a branch where it doesn't belong will
    1.14 -probably stop the driver from compiling.
    1.15 -
    1.16 -The second is to maintain a single source tree filled with conditional
    1.17 -statements that turn chunks of code on or off depending on the
    1.18 -intended target.  Because these ``ifdefs'' are not allowed in the
    1.19 -Linux kernel tree, a manual or automatic process must be followed to
    1.20 -strip them out and yield a clean tree.  A code base maintained in this
    1.21 -fashion rapidly becomes a rat's nest of conditional blocks that are
    1.22 -difficult to understand and maintain.
    1.23 -
    1.24 -Neither of these approaches is well suited to a situation where you
    1.25 -don't ``own'' the canonical copy of a source tree.  In the case of a
    1.26 -Linux driver that is distributed with the standard kernel, Linus's
    1.27 -tree contains the copy of the code that will be treated by the world
    1.28 -as canonical.  The upstream version of ``my'' driver can be modified
    1.29 -by people I don't know, without me even finding out about it until
    1.30 -after the changes show up in Linus's tree.  
    1.31 -
    1.32 -These approaches have the added weakness of making it difficult to
    1.33 -generate well-formed patches to submit upstream.
    1.34 -
    1.35 -In principle, Mercurial Queues seems like a good candidate to manage a
    1.36 -development scenario such as the above.  While this is indeed the
    1.37 -case, MQ contains a few added features that make the job more
    1.38 -pleasant.
    1.39 +La primera es mantener varias ramas, cada una pensada para un único
    1.40 +entorno. El problema de esta aproximación es que usted debe tener una
    1.41 +disciplina férrea con el flujo de cambios entre repositorios. Una
    1.42 +nueva característica o un arreglo de fallo deben empezar su vida en un
    1.43 +repositorio ``prístino'', y luego propagarse a cada repositorio de
    1.44 +backport. Los cambios para backports están más limitados respecto a
    1.45 +las ramas a las que deberían propagarse; un cambio para backport que
    1.46 +es aplicado a una rama en la que no corresponde probablemente hará que
    1.47 +el controlador no compile.
    1.48 +
    1.49 +La segunda es mantener un único árbol de código fuente lleno de
    1.50 +declaraciones que activen o desactiven secciones de código dependiendo
    1.51 +del entorno objetivo. Ya que estos ``ifdefs'' no están permitidos en
    1.52 +el árbol del kernel de Linux, debe seguirse algún proceso manual o
    1.53 +automático para eliminarlos y producir un árbol limpio. Una base de
    1.54 +código mantenida de esta manera se convierte rápidamente en un nido de
    1.55 +ratas de bloques condicionales que son difíciles de entender y
    1.56 +mantener.
    1.57 +
    1.58 +%TODO canónica?
    1.59 +Ninguno de estos enfoques es adecuado para situaciones en las que
    1.60 +usted no es ``dueño'' de la copia canónica de un árbol de fuentes. En
    1.61 +el caso de un controlador de Linux que es distribuido con el kernel
    1.62 +estándar, el árbol de Linux contiene la copia del código que será
    1.63 +considerada por el mundo como la canónica. La versión oficial de
    1.64 +``mi'' controlador puede ser modificada por gente que no conozco, sin
    1.65 +que yo siquiera me entere de ello hasta después de que los cambios
    1.66 +aparecen en el árbol de Linus.
    1.67 +
    1.68 +Estos enfoques tienen la debilidad adicional de dificultar la
    1.69 +%TODO upstream. no no es río arriba
    1.70 +generación de parches bien formados para enviarlos a la versión
    1.71 +oficial.
    1.72 +
    1.73 +En principio, las Colas de Mercurial parecen ser un buen candidato
    1.74 +para administrar un escenario de desarrollo como el de arriba. Aunque
    1.75 +este es de hecho el caso, MQ tiene unas cuantas características
    1.76 +adicionales que hacen el trabajo más agradable.
    1.77  
    1.78  \section{Conditionally applying patches with 
    1.79    guards}