Sistemas para control (o gestión o manejo) de versiones tienen utilidad mucho mas allá que solo para la programación. Y en cualquier circunstancia donde estas usando muchos archivos para realizar un proyecto (como por ejemplo una tesis de grado) es indispensable manejar las versiones en las cuales están los archivos. También cuando no estás trabajando en un equipos, y eres el único que contribuye.
Para personas que no están tan cerca al mundo de programación, los sistemas de control de versiones no aparecen en su radar. Pero quizás debería porque las ventajas son múltiples, y la mayor ventaja es deshacerse de una vez de decenas (he visto hasta cientos) de versiones de un archivo marcados como miarchivo.doc, miarchivo_jun3.doc, miarchivo_final.doc etc. etc.
A la hora de entregar el trabajo el riesgo de no reconocer lo que realmente era la última versión es grande. Esto aplica aún más si estas trabajando con datos, y quizás hasta escribiendo pedacitos de código en R (por ejemplo). Algo que hiciste hace dos años, al comenzar el trabajo de tésis, fácilmente se te puede perder entre un mundo de nombres de archivos ambiguos a la hora de tener que hacer una pequeña revisión en una gráfica o un análisis.
Las opciones más visibles son subversion (o svn) y git (como se usa en github). Y son dos representantes de una aproximación diferente al control de versiones. Subversion es un sistema centralizado (en inglés: Centralized Version Control System – CVS), y asume que hay un servidor central desde el cual se gestionan todos los archivos del proyecto. Por el otro lado están los sistemas descentralizados (en inglés: Decentralized Version Control System – DVCS).
Pero ambos son relativamente difíciles de instalar y configurar, y ninguno ofrece un sistema para manejar tareas directamente. Hay que conectar algo como Trac o Mantis, pero eso hace la labor de configurarlo aún más difícil.
En mi opinión el uso de un sistema de control de versiones es indispensable, y siempre trato de entusiasmar a participantes de los cursos que doy a que por lo menos traten de usarlo una vez para sus propios proyectos.
Uno de los secretos mejor guardados en el mundo del control de versiones, o así parece, es Fossil-SCM, el cual fue creado en el 2006 por Richard Hipp y se continua desarrollando por una comunidad dedicada a hacerlo lo mejor posible. La parte más impresionante de Fossil es que con un solo pequeño programa te da un sistema completo con control de versiones, gestión de incidencias y un wiki. Además es un DVCS, lo que significa que no es necesario estar conectado a la red para trabajar. Y si quieres simplemente usas solo tu repositorio local (en tu disco duro) para trabajar. Siempre tendrás la opción más adelante incluir acceso en linea para ti mismo o para más participantes del proyecto.
Esto no significa que Fossil sea limitado de alguna forma. Puedes crear un flujo de trabajo tan detallado como quieras, y verás que en el transcurso del tiempo vas a usar cada vez más opciones. La ventaja para experimentar es que es increíblemente rápido, también en máquinas que quizás no sean las más potentes.
Hay excelente documentación para el uso de Fossil, que desafortunadamente está en Inglés. Aún así es bastante accesible. Ademas existe un lugar donde puedes crear fósiles en línea (y así acceder tu proyecto desde cualquier lugar) el cual es gratis – y hasta donde sé sin ánimo de lucro. Lo encontraras en <>>.
Si no acostumbras configurar cosas en tu computador, la instrucción de “poner Fossil en tu $PATH” es quizás demasiado breve. Significa que necesitas agregar el directorio donde colocaste el ejecutable de Fossil (fossil.exe en Windows por ejemplo) a la variable $PATH de tu computador. Si lo buscas en linea encontraras como hacerlo para tu sistema.
Sabrás que haz logrado completar la instalación si en tu línea de comandos puedes dar la instrucción:
fossil version
Te debe aparecer un mensaje como:
This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC
Si este mensaje no aparece, sigue buscando como incluir Fossil en tu $PATH. Si esto funciona bien puedes empezar a jugar con Fossil para ver como funciona. Usando la linea de comandos (Terminal en OSX o Linux, CMD en Windows) busca el sitio donde quieres crear un directorio de prueba. Por ejemplo:
cd Documents
mkdir fossilrepos
cd fossil repos
Ahora puedes crear un nuevo repositorio con el comando init:
fossil init mirepositorio.fossil
Recuerda que esto es un DVCS, y esto significa que un repositorio no te deja hacer nada hasta crear un directorio de trabajo (inglés: working directory). Para empezar a trabajar con el repositorio necesitas instruir a Fossil donde quieres trabajar.
Para crear un directorio de trabajo, sube un nivel de regreso a Documentos, y después crea un nuevo directorio que llamaremos MiDirectorioDeTrabajo de esta forma:
cd ..
mkdir MyWorkingDirectory
cd MyWorkingDirectory
Como aquí es donde vamos a trabajar y crear los archivos que pertenecen al proyecto, necesitamos establecer la conexión con el repositorio de Fossil que hemos creado antes. Lo hacemos así:
fossil open ../fossilrepos/myrepository.fossil
Puedes usar este directorio igual que cualquier otro, y verlo con tu explorador de archivos favorito, guardar documentos, copiar documentos etc. etc. Para este ejemplo crea un documento de texto en el directorio MiDirectorioDeTrabajo. Ahora que hay algo allí podemos hacer nuestro primer envío de cambios (ingles: commit). En otras palabras: vas a incluir la primera versión del archivo.
Dentro de MiDirectorioDeTrabajo puedes dar la instrucción:
fossil commit -m "Enviando mi primer archivo"
Verás que no pasa nada! Porque? Porque estas enviando cambios, pero el nuevo archivo todavía no es parte del proyecto. Fossil respeta tus instrucciones de lo que se ha de incluir, y lo que no. Así que primero necesitamos decir:
fossil add miarchivo.txt
Ahora si repites la operación de arriba:
fossil commit -m "Enviando mi primer archivo"
Veras que se incluyo tu nuevo archivo. La -m es una abreviación para incluir el mensaje. Si solo dices fossil commit te dejará espacio para incluir un mensaje (enviar cambios sin mensajes es mala costumbre, aunque repitas el mismo mensaje más de una vez).
Ahora que tienes tu repositorio configurado, y has enviado el primer archivo que forma parte del proyecto es hora de ver la interfaz de Fossil. Abrirá en una ventana de tu navegador de web tras decir:
fossil ui &
Todo lo que vez aquí es exclusivamente parte del repositorio en donde estamos trabajando. Puedes tener múltiples proyectos abiertos de esta forma. Por defecto eres el administrador y puedes empezar a hacer cambios en la ventana de administración. Pero primero miremos a lo que esta en pantalla.
EL proyecto abre en la ventana principal del Wiki. Y aquí puedes mantener notas o documentación sobre el proyecto. O, por ejemplo, una colección de eslabones a páginas en línea que usas con frecuencia al trabajar en el proyecto. El contenido lo compartes con todos los que estén usando el repositorio.
También hay una Linea de Tiempo, y este es un informe de todos los cambio que han sido sometidos al repositorio, incluyendo tiquetes y cambios al wiki. Al iniciar el repositorio verás el primer envío de los cambios. Si cambias el archivo y lo envías nuevamente, verás el cambio y tu anotación de inmediato en esta pagina.
Bajo Archivos verás la lista de los archivos y/o directorios que han sido creados. Si el archivo se puede mostrar en el navegador de web también mostrará el contenido (por ejemplo texto, o una figura en png).
Bajo Ramas encontrarás una sola rama llamada “Trunk” (ingles para Tronco). Esta ha sido creada por defecto y si tienes buena razón para hacerlo la puedes cambiar. Vale la pena explorar las posibilidades que ramas ofrecen para manejar tu proyecto tan pronto estés cómodo en el uso básico de Fossil.
Bajo Tiquetes tienes la posibilidad de crear tiquetes y ver informes de los que ya han sido creados. A veces los llaman incidencias o tareas, dependiendo del flujo de trabajo que han de facilitar. Cuano trabajo solo en un proyecto lo veo como mi lista de cosas por hacer, y es una forma eficaz de evitar que se te olvide hacer algo y de asignar prioridades a las cosas por hacer antes de entregar el proyecto.
Hay formas mucho mas elaboradas de trabajar con Fossil, y tienes todas las posibilidades de hacerlo a medida de tu forma de trabajar o la de tu equipo o cliente.
Para los que quieran ensayar a Fossil en un entorno traducido al Español, tengo una versión traducida aquí que se deja clonar. No es posible en este momento de traducir todo el contenido, y la documentación de Fossil está en Inglés. Pero ojala la traducción del interfaz ayudo para bajar el nivel de entrada.