2012-06-13 21 views
7

Tengo una solución llamada "Framework" que es un ensamblaje C# para mi lógica comercial y transacciones de datos.TFS Recomendación de ramificación

Tengo 4 aplicaciones que usan Framework, 1 sitio web, 1 aplicación de consola y 3 otros tipos de aplicaciones.

$/TeamProject 
    /Framework 
     /Dev 
     /Main 
     /Release 
    /WebApp 
     /Dev 
     /Main 
     /Release 
    /WCFApp 
     /Dev 
     /Main 
     /Release 

Tengo todos estos en un proyecto de equipo con cada ensamblaje/aplicación en su propia carpeta.

Quiero utilizar la función de bifurcación para cada una de las aplicaciones que comparten el ensamblado de Framework pero no sé cuál es la mejor manera de bifurcar la Aplicación junto con Framework?

¿Alguna sugerencia?

Sé cómo funciona la ramificación y la fusión, pero todos los ejemplos solo demuestran la ramificación de todo lo que está contenido en 1 carpeta.

+0

muestra cómo mis archivos de control de fuente actualmente se ven –

Respuesta

7

A la luz de una imagen que representa el directorio de control de código fuente, voy a hacer el siguiente supuesto:

 
$/TeamProject 
    /Framework 
    /Console 
    /Web 
    /etc. 

Lo que hay que hacer primero es crear una carpeta llamada Main en $/TeamProject (este será su principal - aka trunk - branch) y mover todas sus carpetas de nivel superior en él.

Entonces tenemos:

 
$/TeamProject 
    /Main 
    /Framework 
    /Console 
    /Web 
    /etc. 

Ahora es necesario convertir Main a una rama, se puede hacer esto haciendo clic derecho sobre la carpeta Main y seleccione "Convertir a Branch". TFS ahora le permitirá ramificar $/TeamProject/Main a $/TeamProject/ConsoleV2 (por ejemplo) y trabajar en funciones para V2 de la consola. Puede modificar la aplicación de consola y el marco si es necesario en esta rama. Cuando se complete este trabajo, puede Invertir Integrar (fusionar) los cambios nuevamente en Main.

Recuerde seguir realizando fusiones de integración directa (merge down) de Main a su sucursal de funciones y resolver los conflictos para mantener las bases de código sincronizadas.

Al adoptar este enfoque, puede modificar cualquier parte de cualquiera de sus productos en un único control atómico, por ejemplo, puede cambiar una API en su Marco añadiendo un nuevo parámetro obligatorio a un método, puede cambiarlo en todas sus aplicaciones al mismo tiempo, y cuando se fusiona con RI en Main todo se actualizará.

+0

Conozco esta aplicación, el problema es si quiero utilizar Brach my Console junto con el Framework. Tengo que ramificar todo al lado ... ¿Es este el enfoque habitual? Parece un poco excesivo matar –

+0

De dónde se ramifica en el Repositorio de origen no cambiará el tamaño de la rama que crea. Utilizamos este enfoque para ramificar varias partes diferentes de nuestra aplicación que son independientes de la versión para que podamos actualizar las partes dependientes al mismo tiempo. Simplemente puede ignorar las carpetas en las que no trabaja. – DaveShaw

+0

He agregado un "visual" de cómo mi código fuente está actualmente estructurado en mi proyecto de equipo –

-2

Si desea tener la bifurcación & fusión para proyectos individuales, la única manera de lograrlo en TFS es crear un proyecto separado TFS para cada uno de los proyectos en su solución. Espero que tenga sentido. Una vez que lo haces, puedes derivar el código de cada proyecto a tu directorio de trabajo.

Hace poco tiempo migramos nuestro código de VSS a TFS. En ese momento, tuvimos que decidir poner todo el código en 1 proyecto de TFS o separarlos. Entonces, tenemos un sitio web, una biblioteca de negocios (que es utilizada por el sitio web & otras aplicaciones), una capa de datos. Creamos un proyecto separado de TFS para la biblioteca, el sitio web y los proyectos de la capa de datos. Cada proyecto tendría una sucursal troncal. Todos los que necesitan lo último deberían ramificar su propia copia del tronco y fusionarse allí.

Espero que ayude.

+0

Entonces, ¿cómo estás fusionando cada conjunto en 1 rama? –

+0

Aquí está la cosa. Todos los desarrolladores tendrían que mantener un archivo de solución local. Entonces, si necesito el sitio web, la biblioteca y la biblioteca de acceso a datos, obtengo esas sucursales de TFS en la solución de mi lado y nunca reviso la solución. – Skadoosh

+0

Eche un vistazo a estos: http://stackoverflow.com/questions/400517/tfs-structure-multiple-projects-or-single-project y http://stackoverflow.com/questions/867628/merging-and-branching -shared-code-between-projects-in-tfs – Skadoosh

2

Su pregunta principal tal como la entiendo es "¿Cuál es la mejor estructura de bifurcación para ramificar mis aplicaciones que dependen de Framework?" Si siempre los compila y los versiona/los libera juntos, entonces es más simple y menos costoso ramificarlos todos juntos como DaveShaw describe; sin embargo, si cada uno de ellos es desarrollado por diferentes equipos, tienen diferentes calendarios de lanzamiento, tienen diferentes versiones, etc ... de lo que querrás crear una rama MAIN debajo de cada uno de ellos. En este caso, también debería quedar claro quién es el propietario de los cambios en Framework. Por lo general, es una buena idea controlar el acceso de facturación solamente a aquellos que lo necesitan para proyectos compartidos como Framework.

Si el último caso es cierto, entonces creo que su gráfico actual se maneja muy bien, pero haría un cambio; Mantenga sus Releases en el mismo nivel en la jerarquía que la rama MAIN para que la ruta relativa permanezca igual para hacer referencias; esto simplificará sus asignaciones de espacio de trabajo:

$/TeamProject 
    /Framework 
     /Dev 
     /Main 
     /Release1 
     /Release2 
     /Release3 
     ... 
    /WebApp 
     /Dev 
     /Main 
     /Release 
      /Release1 
      /Release2 
      /Release3 
      ... 
    /WCFApp 
    ...