CVS: primeros pasos
Hay quien dice que el uso de un servidor de versiones cuando el número de desarrolladores tiende a uno es injustificado, es posible que tengan razón pero llevo algunos años con la doble tarea -programar y versionar- y creo adecuado delegar responsabilidades en algo más fiable que yo.
Así que he tomado la decisión de probar CVS. Antes de ir corriendo a por unos algodones para los oidos intentaré explicar el motivo de usar estas siglas y no otras. Lo primero que se me ocurre es que OpenBSD lo trae de serie. ¡Correcto! la máquina que versionará mi código fuente es un pez globo. Entiendo que pueda parecer demasiado cómodo, pero para no haber usado nunca un sistema de control de versiones y poder evaluar la utilidad del mismo es más que suficiente.
A diferencia de casi cualquier otro software servidor, no ha sido doloroso ponerlo en funcionamiento, tres sencillas órdenes. Primero creamos el directorio donde irán nuestros módulos (proyectos), lo acomodamos con permisos generosos e iniciamos el repositorio:
Así que he tomado la decisión de probar CVS. Antes de ir corriendo a por unos algodones para los oidos intentaré explicar el motivo de usar estas siglas y no otras. Lo primero que se me ocurre es que OpenBSD lo trae de serie. ¡Correcto! la máquina que versionará mi código fuente es un pez globo. Entiendo que pueda parecer demasiado cómodo, pero para no haber usado nunca un sistema de control de versiones y poder evaluar la utilidad del mismo es más que suficiente.
A diferencia de casi cualquier otro software servidor, no ha sido doloroso ponerlo en funcionamiento, tres sencillas órdenes. Primero creamos el directorio donde irán nuestros módulos (proyectos), lo acomodamos con permisos generosos e iniciamos el repositorio:
# mkdir /home/cvs # chown -R cvs:cvs /home/cvs # cvs -d /home/cvs initDel lado del cliente el asunto tampoco se complica en exceso siguiendo una cierta lógica. Las variables de sesión son indispensables para un uso correcto así que primero exportamos el directorio de trabajo del servidor y luego obligamos a CVS a conectrase mediante ssh:
# export CVSROOT=:ext:cvs@servidor:/home/cvs/ # export CVS_RSH=/usr/bin/sshAhora tendríamos que hacer el commit inicial del código fuente, base del proyecto sobre el que trabajaremos, para ello y dentro del directorio donde tengamos el código haremos:
# cvs import -m "Commit Inicial" proyecto1 cvs startAutomáticamente se conecta a cvs@servidor y sube a /home/cvs/proyecto1/ la primera revisión de código fuente. Una vez hecho ésto debemos borrar (o cambiar de ubicación) el fuente del lado cliente para bajar la versión ya versionada -valga la redundancia- que acabamos de subir:
# cvs co proyecto1Sencillo pero algo lioso, a partir de aquí ya podemos editar y trabajar en cliente para commitear los cambios sin temor:
# cvs ci proyecto1 Log message unchanged or not specified Checking in cake/app/app_controller.php; /home/cvs/cake/app/app_controller.php,v <-- app_controller.php new revision: 1.2; previous revision: 1.1 done #Referencias:
Comentarios
por cierto, como anotacion, cuando haces el cvs -d /dondesea init, no estas lanzando ningun servicio, estas simplemente creando el repositorio donde almacenaras todas las cosas. Te lo digo por que tal y como lo usas, por SSH, no necesitas servicio, si usases pserver (el metodo de autenticacion genuino de cvs) si tendrias un daemon y toda la pesca.
Wu, por un mundo mejor, un mundo sin captchas!
Anotado y rectificado lo del servicio, entiendo que a través de SSH lo único que hace es comparación de ficheros, logs y poco más.
r0sk, por un mundo mejor, un mundo sin SPAM!
Un saludo