Sucursal de TFS 2010 en proyectos de equipo: mejores prácticas

Question

Tengo problemas para entender cómo configurar TFS de acuerdo con las mejores prácticas proporcionadas por el equipo de TFS Ranger. El problema es tal:

Mi empresa tiene varios productos que hacen uso de una base común de códigos compartidos.

> $/Core 
> -> /Main/Source (Parent Branch) 
> 
> $/Product1 
> -> /Main/Source 
> -> /Main/Source/Core/Source (Child Branch from $/Core) 
> -> /Main/Source/... 
> 
> $/Product2 
> -> /Main/Source 
> -> /Main/Source/Core/Source (Child Branch from $/Core) 
> -> /Main/Source/... 

Por lo tanto, tenemos una colección de equipo y, por ejemplo, tres proyectos de equipo para este ejemplo. ($/* es un proyecto de equipo)

Nuestra versión inicial de bifurcación es un poco molesto. En lugar de ramificar en/Main a/Releases, o/Main to/Development, hemos estado ramificando cada proyecto individualmente. (Proyecto de equipo ... proyecto de solución.)

Esto se debe a la imposibilidad de tener raíces de ramas anidadas. (Ver errores TFS: TF203028 and TF203071)

De acuerdo con la Guía del guardabosques TFS y nuestro enfoque revisado para las versiones de bifurcación, revisiones, desarrollos, debemos ramificar desde/Main en lugar de/Main/Source/Proj1,/Proj2,/Proj3, etc. . Se ha convertido en una gran molestia.

ideal sería:

> $/Product1 
> -> /Main/ (Branch - Parent) 
> -> /Releases 
> -> /1.x 
>  /1 Service Pack (Child Branch from $/Product1/Main 
>  -> /1.0 
>   -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack) 
>   -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only) 
>   -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only) 
>  -> /1.5 
>   -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack) 
>   -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only) 

Soluciones: 1. podemos convertir cada rama compartida (es decir, $/Core.) De nuevo a carpetas normales. De esta forma, ninguna carpeta en/Main es una raíz de la sucursal. Entonces podemos realizar una fusión sin base de $/Product1/Main/Source/Core/Source de vuelta al padre $/Core/Source.

Alguien tiene alguna experiencia con fusiones sin fundamento. Lo que leí de Microsoft es que son excepciones que no deberían ser un lugar común. MS afirma que si configura sus proyectos correctamente con TFS, nunca necesitaría realizar una combinación sin fundamento.

¿Cómo es esto posible cuando se ramifica en proyectos de equipo?!? Debería ser común en cualquier casa de desarrollo de software tener bibliotecas compartidas entre productos.

Estoy abierto a otras soluciones también.

Gracias!

Answer 1

Voy a arrojar una opción en el anillo, puede o no puede no ser útil para usted. Si te sirve de consuelo, he estado meditando sobre este durante un tiempo y no he podido encontrar una solución completamente satisfactoria. Es una muy buena pregunta y estaría muy interesado en ver cómo otros han resuelto este problema.

Sé que es considerado una buena idea para construir desde la fuente siempre que sea posible, pero yo no soy un fan de ramificación entre proyectos de equipo. Si usted tiene un poco de código común y tiene que ser ramificados entre 2 o 3 otros proyectos de equipo entonces la ramificación es manejable, pero si usted tiene 20 o 30 (o 100) Equipo Proyectos continuación, la gestión de las fusiones se convierte en un dolor de cabeza. Puede haber otros problemas si los desarrolladores que trabajan en los proyectos de equipo que consumen no tienen los mismos permisos en el "maestro", como no ser capaz de ver la historia, etc. Por supuesto, si usted tiene código que tiene que ser compartida entre proyectos de equipo en diferentes colecciones de proyectos, entonces no se puede ramificar de todos modos.

Así que con eso en mente, le sugiero que trate el código común de la misma manera que podría tratar una biblioteca de terceros y usar referencias binarias. Una vez que llegue a ese modo de pensar en un número de opciones están disponibles para usted.(Aquí están algunos pero hay probablemente más)

1. usted podría tener la construcción de su código común copiar los binarios a un lugar de retorno, junto con un módulo de combinación para el embalaje (si se utiliza MSI). A continuación, crea una referencia binaria a la ubicación de colocación y obtiene lo que usa para empaquetar para importar el módulo de combinación. En este escenario, debe asegurarse de que la ubicación de colocación sea estable (y preferiblemente solo para la mayoría de los desarrolladores para evitar manipulaciones)
2. Similar a la opción 1 pero use una herramienta como NuGet para administrar sus referencias, esto automatizará el proceso de hacer referencia a nuevas versiones de los binarios. Puede que esta no sea una opción si desea tener más control sobre el lanzamiento de nuevas versiones.
3. Se podía comprobar en los binarios a $ producto1 rama carpeta///lib/comunes en su rama y hacer referencia a ellos mediante una ruta relativa

Como ya he dicho, estoy muy interesada en conocer la otra Los usuarios de SO resolvieron el problema del código compartido usando TFS.

Answer 2

Para lograr lo que quiere, primero necesita convertir todas las ramas en la raíz a la carpeta y luego podrá convertir la raíz en la carpeta.

Nos habíamos quedado atrapados con la fusión bajo una rama diferente y luego fuimos a fusionar sin fundamento. Nos llevó algún tiempo descubrir cómo funciona, pero luego tuvimos éxito al fusionarnos entre sucursales y luego crear la relación entre ellas.

tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive 

Una vez que haya realizado la fusión sin base, debe registrar todos los archivos. Aún así, encontrarás que la relación entre las ramas no se crea.

Para esto, haga clic en la rama ServicePack (como en mi ejemplo) y luego en el menú Archivo, haga clic en Control de fuente -> Bifurcar y fusionar -> Reparar. Allí tendrá la opción de volver a ser padre. Una vez hecho esto, cada vez que desee fusionarse en estas ramas, podrá hacer una fusión normal entre sucursales.

Answer 3

TFS 2010 La ramificación Revisited:

me gustaría ofrecer un modo de confianza para la función de combinación sin base TFS 2010 como una manera de resolver este problema. Recomiendo encarecidamente recoger el libro de Wrox "Professional Team Foundation Server 2010".

En él, se describe este problema en profundidad y, si bien no recomienda el uso de fusiones infundadas, arroja luz sobre cómo usarlos en escenarios como este.

Los hemos estado usando desde que esta pregunta se resolvió por primera vez en abril y aún nos enfrentamos a una situación en la que la combinación sin fundamento presenta un problema. Quería publicar una imagen que detalle nuestra configuración de bifurcaciones según lo recomendado por el libro y el equipo de ALM Ranger.

Answer 4

he estado Configuración de TFS en este momento y se reunió con el mismo problema. El punto es que no hay necesidad de combinar sin fundamento. Solución:

1. Crear rama principal

   $/Core/Main

2. Crear rama hija

   $/producto1
   ->/Main
   ->/Main/Core
   ->/Main/...

3. eliminar la carpeta rama niño

   $/producto1/Main/Core

4. Crear carpeta con el nombre de MISMO

   $/producto1/Main/Core

5. Convierte carpeta producto1 en rama
   

   $/producto1/principales

Ahora puede combinar los cambios de $/Core/Main a $/Product1/Main/Core y al revés.
La visualización no funcionará para la rama Core, pero está bien, supongo;)