Cómo mantener las versiones de origen y la estructura de tree de proyecto en el repository de control de origen

Para un equipo de 4-5 desarrolladores que usan Visual Source Safe (VSS) 2005, ¿cuál es la mejor práctica para mantener las versiones de origen?

Nuestro requisito es mantener e identificar una versión que esté actualmente en producción. De esta forma, en todo momento sabremos qué parte del código se envió durante la implementación.
Hasta ahora esto es lo que tenía en mente.

-trunk – Solución principal y proyecto
-Dev branches – twig creada para desarrollo y mejoras

-Dev (some enhancement) 

-Release – liberar twigs

 -Release 2.1.0 -Release 2.1.1 -Release 3.0 

Todo lo que comienza con un guion (-) arriba es una carpeta en el repository.

Estoy pensando que cada vez que necesitamos mejorar nuestro proyecto, hacemos una twig de desarrollo desde el tronco principal de todo el proyecto. Aquí será donde los desarrolladores trabajarán. Una vez que se completa el desarrollo y se completa el UAT, procedemos a la implementación.

Después de desplegar el proyecto (en este caso una aplicación web) y confirmar que es estable, hacemos una twig Release (versión #) de la twig Dev anterior. Digamos que esto es la versión 3.0, ahora sabemos que en la implementación de julio de 2010 insertamos el código en la carpeta de la versión 3.0.

Luego fusionamos (es fácil en VSS2005) el código de la versión 3.0 con el enlace troncal. De esta forma, el tronco siempre es el último código implementado y la siguiente mejora se ramificará desde el tronco.

HotFix

Algunas cosas que aún no he desencryption es qué sucede cuando existe una twig Dev en la que se está trabajando y hay una solución urgente que se necesita implementar de inmediato.
Tal vez, hagamos una twig separada de la última carpeta de Release, llámela Hot-fix 3.0. Haga que los desarrolladores realicen la corrección, combínelo con el código de la Versión 3.0 después de implementar el hot-fix y luego vuelva a fusionarse con trunk.

Limpiar

Después del lanzamiento, realmente no es necesario tener las twigs dev. ¿Deberían ser eliminados?

Como estamos ramificando, leí que en VSS al eliminar una twig no se libera el espacio en la database a less que se elimine el original.

¿Cómo deberíamos eliminar, o deberíamos eliminar las twigs de desarrollo?

Estos son mis pensamientos, cómo manejas tus versiones y cuáles son tus recomendaciones para mis requerimientos.

Podríamos mudarnos a TFS en el futuro, por lo que todo lo que implemente ahora en VSS debería considerar este movimiento en el futuro.

  • trunk -> solo debe contener código estable
  • label -> agregar tags al código de línea externa para identificar versiones (por ejemplo, versiones 2.1.0, 2.1.1, 3.0, etc.)
  • twig -> crear una twig para cada problema
  • actualizar -> actualizar las twigs a menudo para mantener el código lo más cerca posible del tronco (porque mientras tanto se corrigieron otras correcciones)
  • fusionar -> unir twigs al enlace troncal si la solución es estable (incluya el número del problema para que los cambios del código estén relacionados con el número del problema)

Lo mas importante de todo:

  • use un sistema de control de fuente que lo soporte para hacer todo esto -> VSS no lo hará;)

También tome nota de este interesante artículo: http://betterexplained.com/articles/a-visual-guide-to-version-control/