¿Ramas características en CVS?

Question

La política me obliga a usar CVS en este proyecto determinado, así que aunque no puedo cambiar a otra cosa, como Git, no puedo.

Entonces, mi verdadera pregunta es la siguiente: tenemos una convención de que creamos una nueva sucursal en CVS cada vez que hacemos una versión (también etiquetamos, pero eso no es lo importante). Llamamos a estas ramas de versión, y nos permiten revisar fácilmente una versión específica y hacer cambios de revisión, esto es lo que son nuestras versiones menores.

Pero ahora tengo algunos cambios grandes y arriesgados que están en riesgo y si estuviera trabajando en Git, estaría creando una característica en un abrir y cerrar de ojos. Sin embargo, trabajando en CVS, traté de crear ramas de características en otro proyecto y descubrí que las cosas se complicaron rápidamente. Terminé con muchas sucursales y perdí el rastro de las sucursales que estaban sincronizadas, las que necesitaban fusionarse y las que ya no estaban en uso.

Entonces, acercándonos cada vez más al signo de interrogación, ¿es posible usar las ramas de características en CVS? ¿Son demasiados problemas para valer la pena o acabaré lamentándome por no usarlos? ¿Debo morder la bala y simplemente comenzar a codificar en HEAD pero doblar mi proceso de codificación para introducir los cambios de la manera más discreta posible?

Answer 1

Si eres el único que se está desarrollando en la rama de características, simplemente puedes usar Git como tu " desarrollo de sandbox " y luego, una vez que haya realizado los cambios, combínelos en su repositorio de CVS.

Aún obtiene el beneficio del control de código fuente para su producto de trabajo intermedio.

Answer 2

Hay una excelente discusión de las estrategias de bifurcación llamadas líneas transmitidas que podrían ayudar - describe las ventajas y desventajas de usar ramas de características.

También cubre opciones para el código de línea y las políticas que le gustaría implementar

Answer 3

Una cosa a considerar es en realidad cerrar la rama de características cuando hayas terminado con ella, una vez que la hayas fusionado con el tronco principal. En este contexto, cerrar simplemente significa abandonar la rama, no una eliminación real.

Una vez que se fusiona el trabajo, realmente no hay necesidad de que la rama " exista " ;.

Con el fin de identificar rápidamente qué ramas son ramas de características, sugeriría tener una fuga en la convención de nombres " FEAT_MY_FEATURE " o " FEAT_20080926 " (¿fecha de inicio?). Esto facilitaría ignorar todas esas ramas de características cuando se navega por la estructura del repositorio.

Answer 4

He trabajado en un entorno durante varios años en los que esto era una práctica común y fue realmente doloroso. Asegúrese de que las fusiones formen parte de su plan de proyecto porque consumirán mucho tiempo y son una fuente de demora.

Documentar las sucursales y asignarles responsabilidades específicas ayudó un poco.

Tuvimos que crear una herramienta para ayudarnos a fusionar los cambios de forma incremental (un cambio a la vez, en lugar de fusionar la punta de las ramas) porque CVS no se comporta bien si las dos ramas divergen.

A menudo se sincroniza (al menos una vez a la semana).

Creo que la mejor manera de enfocar esto en retrospectiva sería asegurarnos de que la divergencia sigue siendo mínima y dividir el desarrollo de riesgo en diferentes hitos utilizando Scrum, por ejemplo.

También le recomiendo que lea SCM Patterns . Este libro contiene muchos buenos consejos.