Por lo general los sistemas de control de versiones CVS están pensados para que un grupo de desarrolladores trabaje sobre un mismo proyecto en común al mismo tiempo. Estos sistemas permiten un control exhaustivo de quien ha cambiado qué en cada momento, volver atrás a una versión anterior en caso de problemas, etc, etc.

Toda vez que en mi trabajo no he tenido demasiadas oportunidades de trabajar en equipo, lo cierto es que nunca me han llamado la atención en exceso estos sistemas, no ya porque sea el único desarrollador aqui (Este sistema también es práctico para un sólo desarrollador, por las características de rollback, etc…) sino porque están orientados cuasi exclusivamente a su papel: “Control de Versiones”, es decir, el esquema general es un desarrollador trabajando en local sobre un proyecto y actualizando el CVS simplemente para guardar versiones.

Sin embargo, lo que yo esperaba de CVS era algo más:

• En mi caso (aplicaciones web) quiero desarrollar directamente contra el servidor web donde va a estar alojada la aplicación, ya que quiero que esta aplicación disponga de los mismos requisitos, funcionalidades y limitaciones que va a tener una vez “en vivo”, para evitar sorpresas desagradables. CVS no me permitía esto, ya que almacena su control de versiones en una carpeta no visible desde el exterior (aunque esto es configurable) y encima guarda los ficheros como diffs, no como contenido “real” (PHP en mi caso) que el servidor web pueda procesar.
• Quiero que una vez guardado mi código en local, con una pulsación de tecla, pueda enviar el nuevo contenido al servidor para hacer debug del mismo. Esto lo permite CVS a medias, de nuevo el subir el contenido si, pero verlo “en vivo” no, ya que requiere hacer un “checkout” o “update” del código hacia la carpeta visible desde web para hacer debug, una vez subido dicho código al servidor CVS, y es un auténtico coñazo tener que realizar estos dos pasos a mano cada vez que tocamos el código.
• Además quiero que, una vez hecho el “debug” del código, con un sencillo proceso pueda pasar esa versión del mismo a “producción”, esto es, a la url definitiva donde va a funcionar dicho código. Esto si es sencillo, basta con un “checkout” o “update” del código en la carpeta pública.
• Y por último, por pedir, quiero una recopilación de estrellas porno sumisas a mis deseos, los más sublimes y los más perversos… no, ya en serio…

Todo lo demás es solucionable, pero se ve rápidamente que el problema es el automatizar el paso del código del cliente al CVS y luego el update automático del cvs a la carpeta de debug, ya que CVS no parece a priori soportar tal funcionalidad… y por este motivo he estado a puntito de renunciar completamente… a utilizar un estupendo software.

Por suerte ahí estaba el amigo r0sk, que se ha tomado la molestia (gracias mil) de documentarse y ayudarme a conseguir esta funcionalidad. Para ello ha utilizado un truco más que ingenioso que nos explica, como siempre de forma amena, en su blog.

Fecha de la entrada: Martes, 13 de noviembre del 2007 a las 5:48 pm. Puedes seguir los comentarios a la entrada utilizando su feed RSS 2.0. Si lo deseas, puedes dejarnos un comentario, o hacer trackback desde tu propio sitio web.