Cómo ramificar una sola Biblioteca de classs para un cambio menor (2.0 a 2.1) sin ramificar toda la solución

Solución

La pregunta está debajo de la solución. Saliendo de lo que Scott Bruns sugirió que la ramificación por versión podría ser nuestro problema, decidí leer detenidamente la documentation de Team Foundation Server 2010, así como los Patrones y Prácticas de Microsoft. Los resources utilizados son los siguientes:

Capítulo 5: Definición de su estrategia de combinación y ramificación http://msdn.microsoft.com/en-us/library/bb668955.aspx

Estrategia de ramificación

He elegido utilizar la siguiente estructura.

TeamCollection TeamProject Development Feature A Feature B Main TeamApplication Code Project1 Project2 Project3 MyClassLibrary Documents Releases 1.0 2.0 2.1 

La comprensión de esto es bastante simple. La base del código principal está en Main y contiene la base del código en su totalidad, pero no en múltiples copys o múltiples versiones. Además, si se necesita desarrollar una característica, un proyecto individual se puede ramificar en la twig Desarrollo, en lugar de ramificar toda la solución. El resultado es que el cambio se fusionará nuevamente en el repository principal. Esto proporciona aislamiento de modo que cuando se desarrolla una característica, no rompa la base del código principal.

Entonces, cómo esto resuelve mi problema de mantener diferentes comstackciones, es que cuando se lanza una nueva compilation, este es el escenario en el que la solución en su totalidad se ramificaría en Versiones. Por lo tanto, esencialmente, las versiones contienen una copy completa del código fuente de cada versión, lo que tiene sentido. Por lo tanto, se pueden proporcionar revisiones, errores y mantenimiento para versiones específicas, y se pueden fusionar de nuevo en el repository principal una vez que las correcciones y los cambios son estables.

Así que, al final, la base de código Principal sería esencialmente la última versión estable del software, mientras que el desarrollo aísla las características y el código no probado, y las versiones aíslan sus comstackciones y permiten el mantenimiento posterior a la publicación.

La otra parte del problema que condujo a la solución fue pensar que necesitábamos ramificarnos para cualquier tipo de cambio que no sea una 'solución'. Entender que solo debería ramificarse cuando sea absolutamente necesario, ahora estaríamos aplicando correcciones, cambios y similares a las bases de códigos existentes y fusionándolos, en lugar de crear nuevas twigs completas.

Espero haber explicado esto bien. Todavía tengo una idea para Team Foundation Server 2010 y estoy aprendiendo esto bien. Se pueden get muchas respuestas leyendo detenidamente los documentos, Patrones y Prácticas de MSDN, y similares. Algunos de ellos son un poco difíciles de entender al principio, pero finalmente te dan count.

Espero que esto ayude a cualquiera con un escenario similar. Todavía estoy incompleto acerca de un buen método de funciones de bifurcación, ya sea que la base de código completa de main deba ser ramificada o solo proyectos individuales. Como si solo se necesitara agregar una nueva sección de WinForm, debería ser capaz de simplemente ramificar el file de formulario, pero sin un proyecto no tienes un diseñador, por lo que las cosas pequeñas como esta parecen ser un problema.

Pregunta

Realicé algunas búsquedas sobre la split de control de versiones aquí en SO en lo que respecta a estructuras de bifurcación y estrategias, pero ninguna de esas preguntas o respuestas se ajusta a mi escenario específico, así que aquí vamos.

Mi estructura de control de origen es la siguiente:

 TeamCollection TeamProject Code 1.0 Project1 Project2 Project3 MyClassLibrary 1.1 Project1 Project2 Project3 MyClassLibrary 2.0 Project1 Project2 Project3 MyClassLibrary ... 

El método habitual que uso para la bifurcación es ramificar todo el directory de la versión. Supongamos que quiero crear una nueva function a partir de la versión 2.0, ramificaré toda la carpeta 2.0 a 2.1.

El problema que he encontrado con este enfoque ahora, es que este proyecto tiene 444 mb de tamaño, por lo que con mi método actual de bifurcación, cada versión tiene 444 mb y utiliza mucho espacio en disco. El otro problema es que no es necesario crear duplicates de todos los files que no necesitan cambios.

En el proyecto, tengo una sola Biblioteca de classs que me gustaría ramificar de 2.0 a 2.1. Necesito hacer un pequeño cambio en la biblioteca, pero me gustaría separar este cambio de la base de código 2.0. El problema que estoy teniendo es entender cómo debo proceder para ramificar esto.

Si bifurco de la siguiente manera:

 TeamCollection TeamProject Code 2.0 Project1 Project2 Project3 MyClassLibrary 2.1 MyClassLibrary 

Intento entender cómo crearía una versión de todo el producto, pero eso includeía la versión 2.1 de la biblioteca de classs si está aislada de los otros proyectos. No necesariamente quiero que la base de código 2.0 se cambie para hacer reference a la Biblioteca de classs 2.1, porque 2.1 no debe ser parte de 2.0.

Mi otro enfoque pensado era hacer:

 TeamCollection TeamProject Code 2.0 Project1 Project2 Project3 MyClassLibrary MyClassLibrary-2.1 (following the default suggestion of TFS Explorer) 

Esto tiene algún sentido ya que la twig 2.1 es un subset de la base de código 2.0 porque es un cambio de característica menor, pero esto también crea una jerarquía de sistema de files extremadamente desorderada para proyectos grandes, y de nuevo, estoy tratando de entender cómo lo haría. comstackr la versión 2.1 de todo el proyecto, sin cambiar las references en la versión 2.0. Nuevamente, 2.1 debe ser una compilation separada de 2.0.

Mi única solución es simplemente ramificar todo el proyecto, pero estoy tratando de encontrar ayuda profesional para esto, ya que el proyecto se está volviendo grande y no es necesario ramificar todo 444 mb.

Me gustaría utilizar la primera opción que sugerí donde tengo 2.1 / MyClassLibrary, pero realmente necesitaría ayuda para entender cómo crearía una compilation del producto completo con solo el proyecto único en el directory 2.1.

La ramificación por versión podría ser su problema básico.

¿Por qué se requiere que trabaje en diferentes versiones de una aplicación en diferentes carpetas? ¿De verdad necesitas trabajar en múltiples versiones del código al mismo time?

En nuestro entorno, simplemente obtendría la versión 2.0 (o 2.1, etc.) en la misma estructura de carpetas (no al mismo time, por supuesto). No necesitaría 444 MB adicionales de espacio en disco.

Por supuesto, sus opciones de entorno / ramificación pueden ser muy diferentes.

Debido a que Team Foundation Server hace un seguimiento de su estado local en el server, puede usarlo para hacer algunos trucos geniales; por ejemplo, usar la bandera publicitada /remap para tf get le permitirá cambiar a una twig diferente y solo download la diferencias

Por ejemplo, supongamos que está trabajando en la versión 2.0 y tiene $/TeamProject/Code/2.0 a C:\Work\Code . Si eliminara la asignación de la carpeta de trabajo para $/TeamProject/Code/2.0 y luego $/TeamProject/Code/2.1 a C:\Work\Code , podría ejecutar tf get /remap y downloadía solo las diferencias entre las twigs.