Ya comenté hace algún tiempo algunas opciones para Source Control Management, y recientemente le he vuelto a pegar un repaso al tema, más que nada por inquietud que por una necesidad inmediata.
Me he llevado una grata sorpresa, porque parece que las cosas han cambiado un poco y ahora hay más opciones para lo que yo buscaba en aquel momento.
En mi revisión del tema me he encontrado en primer lugar con un avance imparable de Subversion, que ya descarté en su momento por solo corregir los defectos del venerable CVS y mantener algunas necesidades que no me eran convenientes (montar un servidor de svn o cvs, no me convence para mis pequeños desarrollos).
En segundo lugar he dado con dos proyectos que pintan realmente bien, ambos con un modelo de desarrollo distribuido (es decir: no centralizado):
- GIT: este es el proyecto que comenzó Linus para tener un
SCMlibre que se ajustara a las necesidades del desarrollo del kernel Linux. Es una buena apuesta porque está en desarrollo activo, y previsiblemente tendrá un excelente soporte durante mucho tiempo por emplearse como base para los desarrolladores deLinux. - Bazaar: este proyecto está respaldado por Canonical, la empresa detrás de Ubuntu. Su punto fuerte sobre
GITes que está programado en Python y por lo tanto es muy portable, con soporte paraLinux,Windows,Macy*BSD. Su debilidad está quizás en que no tienen todavía un servidor dedicado lo suficientemente potente.
En este momento ambas propuestas son completamente funcionales, y trabajan con una filosofía casi idéntica, permitiendo ambos diferentes modelos de desarrollo.
El hecho de que sean SCM distribuidos no debe confundirnos: aún con esta característica se puede seguir una estrategia centralizada. Es tan sencillo como definir una rama considerada central en la que se aplicarán los cambios que realicen los diferentes programadores en sus propias ramas de desarrollo.
Además de la ventaja de ser distribuidos (me parece impagable poder hacer los commit que necesite en mi rama, sin miedo a fastidiar nada y sin permiso especial de nadie, pudiendo aplicar los cambios que desee en cualquier momento a la rama principal de ser necesario), la forma de distribuir las ramas, y en muchos casos modificarlas, puede ser sobre protocolos existentes como HTTP, FTP o SFTP, de manera que no es necesario disponer de un servidor dedicado (aunque sería más eficiente, por supuesto).
¿Cómo es de complicado trabajar con ellos? Con algo de experiencia con CVS o svn es muy fácil. Veamos un ejemplo de uso sencillo en ambos casos, sin pretender ser un tutorial (estos ejemplos pueden contener errores :D), solo quiero resaltar las similitudes entre ambas herramientas.
Configuramos nuestros datos:
GIT$ git repo-config --global user.name "John Foo"
$ git repo-config --global user.email devel@midominio.dom Bazaar
$ echo -e "[DEFAULT]\nemail = John Foo <devel@midominio.dom>" \
> $HOME/.bazaar/bazaar.conf
Obtenemos una rama para trabajar:
GIT$ git clone http://www.desarrollo.dom/devel/main mi_main Bazaar
$ bzr branch http://www.desarrollo.dom/devel/main mi_main
Trabajamos un poco, pero no mucho:
GIT$ cd mi_main
...hack hack hack... Bazaar
$ cd mi_main
...hack hack hack...
Vemos nuestros cambios:
GIT$ git diff
...aquí va un diff con los cambios realizados... Bazaar
$ bzr diff
...aquí va un diff con los cambios realizados...
Guardamos los cambios en el historial de nuestro repositorio:
GIT$ git commit -a -m 'he hecho unos cuantos hacks'
Bazaar
$ bzr commit -m 'he hecho unos cuantos hacks'
Ahora ya tendríamos que integrar nuestros cambios, de así desearlo, con la rama principal de desarrollo, y las diferencias empiezan a aparecer (por ahora vemos que no hay muchas a nivel de uso muy básico).
Igual esto ha sido suficiente para que le pique la curiosidad a más de uno, así que voy a apuntar a: a tutorial introduction to GIT y quick hacking with Bazaar.
La única pega que le veo a estos dos SCM es su relativa novedad en el mercado, con lo que no abunda la integración de estas herramientas en los diferentes entornos de desarrollo, pero imagino que poco a poco se irá corrigiendo la situación, porque su futuro promete mucho.
Bueno, hay otra pega. No he podido decidirme todavía por uno de los dos :).

![[xml]](/images/xml.gif)
