TFS 2010 Branch Across Team Projects-Mejores Prácticas

Tengo problemas para entender cómo configurar TFS de acuerdo con las mejores prácticas proporcionadas por el equipo de Guardabosques de TFS. La cuestión es tal:

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

> $/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 digamos, tres proyectos de equipo para este ejemplo. ($/*es un proyecto de equipo)

Nuestra ramificación de lanzamiento inicial es un poco dolorosa. En lugar de ramificar en /Main to / Releases, o /Main to / Development, han estado ramificando cada proyecto individualmente. (No proyecto de equipo ... proyecto de solución.)

Esto se debe a la incapacidad de tener raíces de ramas anidadas. (Ver Errores de TFS: TF203028 y TF203071 )

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

Lo ideal sería como:

> $/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 / Core) de vuelta a las carpetas normales. De esta manera ninguna carpeta bajo /Main es una raíz de rama. Luego podemos realizar una fusión sin base desde $ / Product1/Main/Source/Core/Source hasta el padre $/Core / Source.

Tiene cualquier persona cualquier experiencia con fundes sin fundamento. Lo que he leído de Microsoft es que son excepciones que no deberían ser comunes. MS afirma que si configura sus proyectos correctamente con TFS, nunca necesidad de realizar una fusión sin fundamento.

¿Cómo es posible esto cuando se ramifican entre 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!

Author: Daniel, 2011-04-19
Source

4 answers

Voy a lanzar una opción en el ring, puede o no puede no ser útil para usted. Si te sirve de consuelo he estado reflexionando sobre esto durante un tiempo y no he sido capaz de llegar a 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 se considera una buena idea construir desde el código fuente siempre que sea posible, pero no soy fan de las ramificaciones entre Proyectos de Equipo. Si tienes un poco código común y necesita ser ramificado entre 2 o 3 otros Proyectos de Equipo, entonces la ramificación es manejable, pero si tiene 20 o 30 (o 100) Proyectos de equipo, entonces administrar las fusiones se convierte en un dolor de cabeza. Puede haber otros problemas si los desarrolladores que trabajan en los Proyectos del Equipo consumidor no tienen los mismos permisos en el "maestro", como no poder ver el historial, etc. Por supuesto, si tienes código que necesita ser compartido entre Proyectos de Equipo en diferentes Colecciones de Proyectos, entonces no puedes rama de todos modos.

Así que con eso en mente, sugeriría que trates el código común de la misma manera que tratarías una biblioteca de terceros y usarías referencias binarias. Una vez que entres en esa mentalidad, hay varias opciones disponibles para ti. (aquí hay algunos, pero probablemente hay más)

  1. Puede hacer que la compilación para su código común copie los binarios a una ubicación de colocación, junto con un módulo de combinación para empaquetar (si usa MSI). A continuación, se crea una referencia binaria a la caída ubicación y obtenga lo que use para empaquetar para importar el módulo merge. En este escenario, debe asegurarse de que la ubicación de entrega sea estable (y preferiblemente solo lea a 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. Esto podría no ser una opción si desea tener más control sobre el despliegue de nuevas versiones.
  3. Usted podría simplemente revisar los binarios en la carpeta $/Product1/branch/lib/common en su rama y referenciarlos usando una ruta relativa

Como he dicho, estoy muy interesado en escuchar cómo otros SOers han resuelto el problema del código compartido usando TFS.

 11
Author: James Reed,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-22 02:21:18

Revisión de la ramificación de TFS 2010:

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

En él, describe este problema en profundidad y aunque no aboga por el uso de fusiones sin fundamento, arroja luz sobre cómo usarlos en escenarios como este.

Los hemos estado usando desde que esta pregunta fue la primera resueltos en abril y aún no han encontrado una situación en la que la fusión sin fundamento presente un problema. Quería publicar una imagen detallando nuestra configuración de ramificación según lo recomendado por el libro y el Equipo de ALM Ranger.

introduzca la descripción de la imagen aquí

 6
Author: Daniel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-22 18:45:18

Para lograr lo que desea, primero debe convertir todas las ramas bajo raíz a carpeta y luego podrá convertir la raíz a carpeta.

Nos habíamos quedado atascados con la fusión bajo una rama diferente y luego fuimos por la fusión sin fundamento. Tomó algún tiempo para averiguar cómo funciona, pero luego tuvimos éxito en hacer merge accross branch y luego crear la relación entre ellos.

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

Una vez que haya realizado la fusión sin fundamento, debe registrar todos los archivos. Sin embargo, encontrará que la relación entre las ramas no se crea.

Para esto haga clic en ServicePack branch(según mi ejemplo) y luego desde el menú archivo haga clic en Source Control -> Branching and Merging -> Reparent. Allí tendrá la opción de re-crianza. Una vez hecho, por lo tanto, siempre que desee fusionar a través de estas ramas, podrá hacer como una fusión normal a través de ramas. introduzca la descripción de la imagen aquí

 2
Author: Sunil Agarwal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-22 11:16:39

Acabo de configurar TFS y me encontré con el mismo problema. El punto es que no hay necesidad de una fusión sin fundamento. Solución alternativa:

  1. Crear rama padre

    $ / Core / Main

  2. Crear rama secundaria

    Produc / Product1
    - >/Main
    - >/Main/Core
    -> /Principal/...

  3. Delete carpeta de rama secundaria

    Produc / Product1/Main / Core

  4. Crear carpeta con el MISMO nombre

    Produc / Product1/Main / Core

  5. Convertir carpeta Product1 a rama

    Produc / Product1 / Main

Ahora usted puede combinar los cambios de $/Core/Main a $/Producto1/Principal/Core y hacia atrás.
La visualización no funcionará para la rama Principal, pero está bien, supongo;)

 1
Author: stbear,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-12-26 17:48:31