2009-05-28 15 views
8

Estoy escribiendo una especie de nuevo panel de administración para nuestro cms (que se ejecuta en formularios web asp.net). Algunos de nuestros servidores 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.¿Cómo usaría un DVCS (mercurial en mi caso) para desarrollar versiones diferentes de .NET Framework?

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

Mi base de código actual y el repositorio 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 recomendación o tutorial?

Respuesta

13

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 .Net. Haces un clon y lo llamas old-dot-net o algo así. Los dos clones ahora son idénticos y ambos tienen como objetivo .Net 3.5.

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

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

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

Aquí hecho [c] y [d] conjuntos de cambios para añadir el .Net 2.0 compatibilidad. Observe cómo el clon old-dot-net contiene más conjuntos de cambios que new-dot-net ya que tiene la compatibilidad con versiones anteriores cambios que usted no desea ver en new-dot-net. A medida que continúe trabajando , es importante pensar en esto: net-dot-net contendrá un subconjunto de los conjuntos de cambios en old-dot-net. Los cambios van desde new-dot-net hasta old-dot-net, pero nunca en la dirección opuesta.

Digamos que usted hace un nuevo cambio en new-dot-net. Realizar 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 desea hacer una copia de puerto que el cambio old-dot-net así, que cambio a old-dot-net y tire de net-dot-net:

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

Esto creará un new head en old-dot-net:

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

dado que el conjunto de cambios [x] tiene [b] ya que es el conjunto de cambios principal. Ahora tiene tiene multiple heads y tiene que combinar para reducir el número de cabezas . Al fusionar, crea un nuevo conjunto de cambios que es su forma de diciendo "así es como deben combinarse [x] y [d]".Si el conjunto 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 le presentará con una herramienta de combinación y tendrá que resolver el conflicto. De confirmar la fusión como chageset [e]:

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

Y ya está - se han incorporado ahora en el cambio [x] su código compatible con .Net 2.0.

Repita esto cada vez que haya habido un cambio en new-dot-net. Digamos que se añaden más características:

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

Después de tirar de ellos en old-dot-net se obtiene

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

Y ahora se fusionan [e] y [z]:

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

Las partes importantes de recordar son estos:

  • hacer cualquier nuevas características en new-dot-net.
  • tracción cambios en old-dot-net
  • Nunca introduzcaold-dot-net-new-dot-net.

en caso de que en algún momento parece que un cambio en new-dot-net no es necesario en old-dot-net, a continuación, usted todavía tiene que tirar de él y fusionar ella. Pero luego realizará una combinación ficticia . Si las cabezas son [w] y [g], y que desea mantener [g], y luego hacer

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

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

+0

por lo que no utilizaría sucursales para esto? ¿Por qué no? – kitsune

+1

No hace ninguna diferencia: existe una relación 1-1 entre ramas (nombradas) y clones en Mercurial. Por lo tanto, para los cambios de port-backing no hace las cosas más fáciles o más difíciles. Con los clones puede ser más fácil comparar archivos de dos clones (abriéndolos a ambos en su editor) y la separación hace que las explicaciones como las anteriores sean más sencillas, en mi humilde opinión. –

+0

muchas gracias por esto – kitsune

Cuestiones relacionadas