¿Cómo usaría un DVCS (mercurial en mi caso) para desarrollar versiones diferentes de .NET Framework?

Estoy escribiendo una especie de nuevo panel de administración para nuestro cms (que se ejecuta en formularios web asp.net). Algunos de nuestros serveres más antiguos solo pueden manejar .NET 2.0 por varias razones, por lo que tendré que volver a escribir mi código, que usa expresiones lambda, etc. para eso.

Me pregunto cómo usaría un dvcs como mercurial para desarrollar esas dos versiones al mismo time.

Mi base de código actual y el repository mercurial están dirigidos a .NET 3.5. Soy relativamente nuevo en mercurial y supongo que tendré que ramificar la base de código.

¿Alguna mejor práctica o tutorial?

Sí, puedes usar Mercurial para esto. Así es como funcionaría.

Digamos que su clon actual se llama new-dot-net ya que es compatible con la nueva versión de .Net. Haces un clon y lo llamas old-dot-net o algo así. Los dos clones ahora son idénticos y ambos tienen como objective .Net 3.5.

Ahora realice cuidadosamente pequeños cambios en old-dot-net para que sea compatible con .Net 2.0. Cuando realice los cambios, los dos clones comenzarán a divergir:

 new-dot-net: ... [a] --- [b]

 old-dot-net: ... [a] --- [b] --- [c] --- [d]

Aquí creó [c] y [d] sets de cambios para agregar la compatibilidad .Net 2.0. Observe cómo el clon old-dot-net contiene más sets de cambios que new-dot-net ya que tiene los cambios de compatibilidad hacia atrás que no desea ver en new-dot-net . A medida que continúe trabajando, es importante pensar en esto: net-dot-net contendrá un subset de los sets de cambios en old-dot-net . Los cambios fluyen de new-dot-net a old-dot-net , pero nunca en la dirección opuesta.

Digamos que haces un nuevo cambio en new-dot-net . Haces el cambio en new-dot-net y la situación ahora se ve así:

 new-dot-net: ... [a] --- [b] --- [x]

 old-dot-net: ... [a] --- [b] --- [c] --- [d]

Ahora también quieres realizar un back-port del cambio a la old-dot-net , cambiar a old-dot-net y sacar de net-dot-net :

 % cd old-dot-net % hg pull ../new-dot-net 

Esto creará una nueva cabecera en old-dot-net :

                              [X]
                             /
 old-dot-net: ... [a] --- [b] --- [c] --- [d]

ya que el [x] set de cambios tiene [b] ya que es el set de cambios principal. Ahora tiene varias cabezas y tiene que fusionarse para networkingucir el número de cabezas. Al fusionarse, crea un nuevo set de cambios que es su forma de decir "así es como deberían combinarse [x] y [d] ". Si el set de cambios [x] solo toca el código que tampoco se toca en [c] y [d] , la fusión debería funcionar. De lo contrario, se te presentará una herramienta de combinación y tendrás que resolver el conflicto. Usted comete la fusión como set de cambios [e] :

                              [X] --------------.
                             / \
 old-dot-net: ... [a] --- [b] --- [c] --- [d] --- [e]

Y listo: ahora ha incorporado el cambio [x] en su código compatible con .Net 2.0.

Repites esto cada vez que ha habido un cambio en new-dot-net . Digamos que se agregan más características:

 new-dot-net: ... [a] --- [b] --- [x] --- [y] --- [z]

Después de tirarlos a old-dot-net obtienes

                              [x] --------------.---- [y] --- [z]
                             / \
 old-dot-net: ... [a] --- [b] --- [c] --- [d] --- [e]

Y ahora fusiona [e] y [z] :

                              [x] --------------.---- [y] --- [z]
                             / \ \
 old-dot-net: ... [a] --- [b] --- [c] --- [d] --- [e] ----------- [f]

Las partes importantes para recordar son estas:

  • hacer nuevas funciones en new-dot-net .
  • tirar de los cambios a old-dot-net
  • nunca empuje desde old-dot-net a new-dot-net .

En caso de que en algún momento descubras que no se necesita un cambio en new-dot-net en old-dot-net , entonces aún necesitas incorporarlo y fusionarlo. Pero luego harás una fusión ficticia . Si las cabezas son [w] y [g] , y quieres mantener [g] , entonces haz

 % HGMERGE=true hg merge -y % hg revert --all --rev g % hg commit -m 'Dummy merge with y.' 

El truco es hacer la fusión sin preocuparse por los resultados, luego revertir todos los cambios y comprometer la copy de trabajo sin cambios como la fusión. De esa forma le dices al mundo que "la combinación de [w] y [g] es [g] ", es decir, desechas los cambios en [w] . Los nuevos cambios realizados en new-dot-net después de [w] se pueden combinar como normal.