Hace poco comentábamos sobre que había tantos lenguajes de programación que uno puede entrar en crisis a la hora de elegir el más adecuado.
Ahora estoy tratando de elegir un sistema de control de versiones para mis proyectos personales, y me sucede algo similar. Existen tantos sistemas de control de versiones que no sé cuál es el más adecuado. Aquí pueden ver una comparación entre varios de elllos. (Incluso algunos proyectos como Axiom, no llegan a decidirse por uo de ellos y ofrecen su código fuente a través de varios de ellos).
Los sistemas de control de versión son un componente esencial en el desarrollo del software libre. Los sistemas de control de versiones hacen posible que varios programadores compartan el código en el que están trabajando a través de la red. Cuando un programador hace una modificación, ella está inmediatamente visible para los demás desarrolladores. Además el sistema lleva el control de las versiones del proyecto, y es posible pedirle algo como “quiero ver el código fuente del proyecto tal como estaba el viernes a las tres de la tarde”. Usando CVS, pude por ejemplo, colaborar en proyectos de software libre como Bluefish o Yacas, trabajando con programadores en Holanda o en Rusia, a los cuáles nunca he conocido personalmente.
El interés de los sistemas de control de versiones no está limitado a los programadores. También son útiles para otros propósitos: por ejemplo los científicos podemos usarlos para escribir un trabajo (paper) en colaboración.
En un comienzo CVS era el sistema de control de versiones más utilizado. Sin duda, CVS es una herramienta que ha sido muy útil durante muchos años, y todavía es utilizada por muchos proyectos de software libre. Representó un gran avance sobre la era pre-CVS, donde el desarrollo se hacía intercambiando parches (patchs) que se aplicaban a mano, en un proceso engorroso y propenso a los errores.
Sin embargo, con el tiempo, se han empezado a notar sus limitaciones. Para mí las más notables son tres: CVS no soporta mover o renombrar archivos o directorios conservando la historia; tampoco soporta copiar un archivo conservando la historia, y finalmente las operaciones de escritura al repositorio (commits) no son atómicas.
Después apareció Subversion, un proyecto que se propuso superar las deficiencias de CVS pero conservando su filosofía básica, y realmente creo que es una gran herramienta. De a poco, la mayoría de los grandes proyectos, se están moviendo a Subversion: GCC, KDE y ahora Gnome. También Sourceforge ofrece ahora soporte para Subversion.
Sin embargo, el modelo de desarrollo centralizado de CVS y Subversion (que requiere un repositorio central al que los desarrolladores tengan acceso a través de la red) no es adecuado para muchos propósitos.
Se han desarrollado por ello, sistemas de control de versiones distribuidos, que no requieren un repositorio central como por ejemplo: SVK (construido sobre Subversion), GNU Arch, Mercurial, Monotone , Darcs, Bazaar y Git (creado por el mismísimo Linus Torvalds para manejar el código fuente del núcleo de Linux; cuando su elección del sistema privativo Bitkeeper mostró haber sido un claro error).
Seguramente voy a elegir algun sistema de control distribuido porque tengo varias computadoras que uso para desarrollo que no tienen conección permanente a la red, hasta ahora el que más me seduce es Mercurial. Entre otras cosas por estar escrito en Python. Si quieren dejarme algún consejo al repecto en los comentario, es bienvenido.
Por suerte existe Tailor, una herramienta para convertir entre los diferentes sistemas de control de versiones. Prové convertir mi repositorio de Subversion a Mercurial sin éxito (Tailor parece confundido por un directorio que borré de mi repositorio), pero sí funcionó convertirlo de Subversion a Darcs.
Actualización: Quiero recomendarles este video de Bryan O’Sullivan, uno de los desarrolladores pincipales de Mercurial, hablando en las Google TechTalks sobre este proyecto.
