Proyecto y ramas en CVS
Veamos qué ramas debería haber en un proyecto CVS y cómo crearlas. Esto es un ejemplo y cada uno puede organizarlo como quiera, pero aquí se cuenta más o menos la "filosofía" que se debería seguir.
En un proyecto CVS debería al menos haber dos ramas siempre vivas. Una de ellas es la rama de DESARROLLO y la otra la ESTABLE.
En la rama de DESARROLLO es donde trabajan los desarrolladores, van metiendo su código en CVS después de haberlo probado y es donde se tiene lo último de lo último. En general lo que hay en esta rama, puesto que se está haciendo, suele tener muchos "bugs" sin corregir ni detectar. Debería haber un equipo de pruebas con la versión de esta rama sacando "bugs" para corregir.
La rama ESTABLE es dónde se meten las versiones de los fuentes muy probadas y con pocos "bugs". Debe haber una sola persona (o un grupo reducido) responsables de esa rama y que son los únicos que pueden meter en ella. Cuando llega el momento de generar una nueva versión "estable", este responsable hace un "merge" de la rama de desarrollo sin meterlo en CVS todavía, genera unos ejecutables, se prueba a conciencia y se sacan errores, que se deben corregir. Cuando los fuentes de esta prueba estén en condiciones, se meten en CVS en la rama ESTABLE.
Si esa versión en la rama ESTABLE se publica o se entrega a los clientes, se crea una nueva rama a partir de la ESTABLE que será únicamente para corregir "bugs" importantes o parches de seguridad (es decir, sólo modificaciones muy necesarias).
Hay discrepancias si la rama principal de CVS (el HEAD) debe ser la estable o la de desarrollo, aunque generalmente suele ser la de desarrollo.
En caso de cambios importantes o que puedan afectar mucho a otros desarrolladores, pueden hacerse ramas sobre la rama de DESARROLLO, de forma que se hagan en ella esos cambios importantes. Una vez terminados y probados esos cambios, se hace "merge" sobre la rama de DESARROLLO, teniendo ya ciertas garantías de que no va a haber grandes problemas.