Anteriormente hemos hablado de sistemas de control de versiones basados en repositorios centralizados, con la clásica arquitectura cliente-servidor. Ahora hablaremos de darcs , donde cada copia del proyecto es un repositorio válido, y por lo tanto, es un potencial servidor.

Una arquitectura descentralizada como la de darcs tiene importantes ventajas: Las distintas ramas de desarrollo son más fáciles de administrar, y no es necesario crear cuentas de usuario en distintas máquinas para dar acceso a los desarrolladores. Si uno quiere trabajar solo, la administración es mínima, por lo que es muy bueno para quienes nunca han usado control de versiones y quieren comenzar ahora. Másss .

David Roundy es un físico dedicado a estudiar maneras de representar el cambio. Cuando se dio cuenta de que sus resultados podrían ser aplicados a sistemas de control de versiones, entonces nació Darcs, que de partida arranca con la ventaja de tener una buena base teórica sobre parches.

Pero vamos a lo práctico. Supongamos que darcs está instalado en nuestro sistema, y que tenemos un proyecto llamado sushi ubicado en un directorio homónimo. Para crear un repositorio, simplemente tenemos que ubicarnos en el directorio donde se encuentra el proyecto, y ejecutar en la linea de comandos

$ darcs init

y listo. Tenemos un repositorio válido, aunque por ahora vacío. Para agregar los archivos debemos hacer

$ darcs add *

y luego grabamos los cambios (en este caso la adición de los archivos).

$ darcs record --all

Esa acción nos pedirá un nombre para el parche y un comentario descriptivo. El repositorio ya está funcionando y puede ser adquirido por otras personas usando darcs. Si cambiamos algo en el proyecto, lo registramos nuevamente con darcs record generando un nuevo parche. Como no hay servidor , no hay necesidad de estar conectado para registrar todos los cambios o para echar marcha atrás. Yo considero esto una ventaja importante, sobre todo para trabajar solo.

Veamos ahora la manera de coordinar el trabajo con otras personas. Supongamos que el directorio es visible en una URL. Una copia del proyecto se genera de la siguiente manera.

$ darcs get http://alguna.parte.sk/sushi

Ahora existen 2 repositorios válidos del proyecto, y por supuesto, a partir de ambos se pueden generan más copias. No existe repositorio central (a menos que por consenso se genere uno). Es importante saber que cada operación de tipo record, sólo será registrado en el repositorio local. Para poder compartir los cambios entre repositorios es necesario ejecutar los comandos darcs push y darcs pull. El primero empuja cambios a otro repositorio, y el segundo trae los cambios desde otro repositorio. Aquí viene la otra ventaja. Supongamos que el otro usuario generó los parches A, B y C. A mí sólo me interesan los parches A y C. Entonces, cuando ejecuto darcs pull, puedo elegir qué parches aplicar. No tengo porqué actualizar con la última versión del proyecto.

Pushing y pulling se hace de una manera segura a través de conexiones vía ssh. Desafortunadamente, esto requiere que uno administre adecuadamente las cuentas de usuario. Pero, si uno quiere evitarse ese problema, darcs ofrece una alternativa que a mi me gusta mucho. Luego de registrar los cambios con record, se ejecuta

$ darcs send -o parche

lo que generará un archivo, llamado "parche" en este ejemplo, que puedo enviar por email como attachment. Al otro lado, quien quiera aplicar los cambios en su repositorio debe hacer

$ darcs apply parche

y seleccionar los parches que quiera para su repositorio. Como ven, todo funciona realmente de manera descentralizada.

La desventaja que tiene darcs, es que no es tan maduro como CVS o SVN, por lo tanto tiene que seguir evolucionando para mejorar algunas cosas, pero es ciertamente una buena alternativa a considerar para el control de versiones de cualquier proyecto.