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}