Probando fossil
En algún sitio leí que fossil is a github in a box, y realmente lo
parece. Desde que el otro día leyera el artítulo sobre fossil del
amigo Victor me entró la curiosidad y ando probándolo. Mi objetivo es
hacer un resumen de mis impresiones, si queréis o necesitáis más
información la podéis encontrar en el sitio web. Y para avanzar un
poco, lo que veréis en esa página, precisamente, es el repositorio
fossil de fossil... para no marear más la perdiz, vamos al lío.
¿Qué es fossil?
Dicho de forma rápida es un gestor de versiones, como lo son git,
Mercurial, bazaar, o cvs o svn, por poner algunos ejemplos. De
hecho, el mismo Víctor lo presenta en el título de su artículo como un
sustituto de git. Y la verdad es que se puede decir eso... a grandes
rasgos lo puede ser, pero no es sólo eso. Si entramos en detalles no
son herramientas equivalentes. fossil excede el mero hecho de lo
que se puede llamar control de versiones y para explicarlo habría
que compararlo con un sistema estilo github o gitea, metido en un
ejecutable.
En la página web de fossil, que por cierto es un repositorio
fossil, como ya he dicho antes, explican las principales
características con las que cuenta. No voy a repetirlas aquí, pero voy
a hacer algunas anotaciones. Las características que me parecen más
remarcables, además del propio control de versiones son:
- Herramientas de trabajo en equipo: viene con control de errores, foro, wiki y lo que llaman anotaciones técnicas (technotes) que son páginas wiki que tienen asociado un momento temporal y que aparecerán en el timeline del repositorio ─si queremos que aparezcan─ para explicar algo sobre el código o el programa, como puede ser un cambio de versión o cualquier otro tema relacionado con el software.
- Interface web del repositorio: el comando
fossil uinos abre un navegador1. Por defecto nos arrancará en el timeline.
En el timeline no sólo constan los commits de código que hagamos, sino también puede mostrarnos los cambios que hagamos en el wiki, las etiquetas, o en cualquier otro contenido del repositorio. Pero como digo, se puede filtrar qué información mostrar en la misma UI.
- Documentación completa de la herramienta: integrado en la misma interface web provee un sistema de ayuda que proporciona información para todas las opciones de la línea de comandos y muchas más cosas. Es decir, viene con su propio sistema de ayuda cargado y preparado para que no necesitemos consultar ningún manual fuera de la propia herramienta.
- Sencillo, autocontenido: todo está contenido en un sólo
ejecutable. No hay complejas dependencias ni de plugins. Y los
repositorios se guardan en ficheros de bases de datos
sqlite3haciendo que toda la información esté junta sin dispersar ficheros por directorios. - Completa información: Proporciona una completa información sobre el código y sobre los commits. Por ejemplo, se puede visualizar las anotaciones en un fichero.
También se puede visualizar la información completa de un determinado commit, incluyendo diff. Además de que permite modificar los datos de los mismos, como puede ser el comentario con el que se realizó la modificación u otros datos.
![Screenshot_2020-11-29_rerl_Check-in_[df60969127].png](./imagenes/Screenshot_2020-11-29_rerl_Check-in_[df60969127].png)
- Software libre: Licencia BSD.
Si habéis pinchado en el enlace a la página de fossil que he puesto
arriba, ya habéis visto un repositorio fossil en acción. ¿Queréis
ver otro? Pues id a la página de sqlite. Esa página es otro
repositorio, de hecho, fossil y sqlite son del mismo programador.
No tengo claro si creó fossil para el control de versiones de
sqlite o si creó sqlite para fossil, porque los ficheros del
respositorio y todos sus datos se guardan en bases de datos sqlite,
como ya he dicho antes.
Al crear un repositorio es aconsejable invertir un poco de tiempo en
ajustar algunas cosas en el fichero .fossil generado. Por ejemplo,
poner un nombre al proyecto en el apartado de configuración del mismo.
Si queremos tenerlo en un servidor y que se pueda acceder desde fuera
también debemos crear una pagina wiki con el nombre del proyecto,
que será la que se muestre en el apartado home del menú. O también
ajustar algunos parámetros, como explicaré después, para acondicionar
el respositorio a nuestras necesidades, aunque sea un repositorio
privado o local.
Montar o no montar servidor
Con el servidor me encuentro un pequeño escollo a pesar de las
facilidades que da fossil para montar un pequeño, ─o gran─,
servidor. La cosa consiste en tener el ejecutable y acceso a la
máquina: el ejecutable puede colocarse como CGI en un servidor web,
o directamente como un servidor a través de http o ssh, etc. El
único requisito es que el ejecutable esté accesible en la máquina que
hará de servidor del repositorio.
Montar un servidor es tan sencillo como teclear el comando
fossil server [opciones] [servidor]
Entre las opciones podemos encontrar parámetros como el puerto,
forzar el acceso a https, limitar el acceso para hacerlo local con
--locahost, proporcionar una página de error, etc. El servidor puede
ser simplemente un directorio del disco con una colección de ficheros
con extensión .fossil. Si quieres montar un servidor sólo tienes que
abrir los puertos del firewall donde quieres que escuche, lanzar el
servidor y ya tienes un repositorio en tu red local. Por supuesto, si
quieres más detalles te recomiendo leer la ayuda. Por ejemplo, el
comando:
fossil ui
lo que hace es montar un servidor local con dirección
localhost:8080, básicamente es un comando fossil server
--localhost que además lanza el navegador web. Si no tenemos
configurado uno para el repositorio en concreto, nos lanzará el que
tengamos configurado por defecto, pero también podemos decirle cuál
queremos utilizar para ese repositorio. Por ejemplo:
fossil set web-browser falkon
hará que cuando llamemos al entorno gráfico, nos lo abra con el
navegador falkon. También podemos utilizar el mismo entorno gráfico
para hacer estas modificaciones en la configuración que necesitemos,
no solo en el repositorio, sino también en el entorno con el que
trabajamos en él.
Uso básico de fossil
Por lo que he podido ver hasta ahora, los respositorios, tanto
locales como remotos, se mantienen con ficheros sqlite3.
Para hacer las pruebas volqué el repositorio git del proyecto de
raytracer en un repositorio fossil:
git fast-export --all | fossil import --git ~/prueba.fossil
Rebuilding repository meta-data...
100.0% complete...
Vacuuming... ok
project-id: 2c2c41b870550e99cefe4cd941aca798144b8db0
server-id: a69aeb2f5f57f16fd1c772f59eb985708bee2533
admin-user: notxor (password is "V7vgBd8YqN")
En ese procedimiento se genera un fichero fossil que nos sirve de
repositorio. Además, nos proporciona una clave de acceso para el
usuario admin. Ese fichero lo podríamos haber colocado en cualquier
sitio accesible2, como por ejemplo en un path tal que
~/repositorios.
$ mkdir prueba-proyecto $ cd prueba-proyecto $ fossil open ~/repositorios/prueba.fossil LICENSE.txt Makefile README.org mundo.rerl src/registros.hrl src/rerl.erl src/rerl_camara.erl src/rerl_imagen.erl src/rerl_material.erl src/rerl_objeto.erl src/rerl_renderer.erl src/rerl_tesela.erl project-name: <unnamed> repository: /home/notxor/repositorios/prueba.fossil local-root: /home/notxor/prueba-proyecto/ config-db: /home/notxor/.config/fossil.db project-code: 2c2c41b870550e99cefe4cd941aca798144b8db0 checkout: c957955db5afdf98344d16a4d829fcfd79775df8 2020-11-29 09:02:51 UTC parent: 78da994df05b8eb275603b88161e1898c6588db9 2020-11-29 08:41:07 UTC tags: master, trunk comment: Primera aproximación a materiales transparentes. (user: notxor@nueva-actitud.org) check-ins: 65 $ ls -lah total 92K drwxr-xr-x 3 notxor users 105 nov 27 12:37 . drwxr-xr-x 113 notxor users 8,0K nov 27 12:37 .. -rw-r--r-- 1 notxor users 32K nov 27 12:37 .fslckout -rw-r--r-- 1 notxor users 34K nov 27 12:37 LICENSE.txt -rw-r--r-- 1 notxor users 775 nov 27 12:37 Makefile -rw-r--r-- 1 notxor users 332 nov 27 12:37 mundo.rerl -rw-r--r-- 1 notxor users 2,7K nov 27 12:37 README.org drwxr-xr-x 2 notxor users 185 nov 27 12:37 src
Ese comando, como se puede ver en el último listado, aparte de crear
todos los archivos del proyecto, genera un fichero con nombre
.fslckout que es otra base de datos sqlite3. Ese fichero guarda la
información en local como hace el directorio .git.
Ahora hay que decirle a nuestro repositorio local que se coordine con
otro remoto. Si hemos montado un servidor o si lo vamos a utilizar
desde un fichero en nuestro path, necesitamos que se mantenga
actualizado con un fichero .fossil, porque, aunque hemos creado el
local haciendo un open, por defecto no crea el enlace. Así pues,
tenemos que hacer:
$ fossil remote add remoto ~/repositorios/prueba.fossil $ fossil remote list remoto file:///home/notxor/repositorios/prueba.fossil
siguiendo el esquema:
fossil remote add [nombre] [URL]
Podemos establecer tantos remotos como queramos. El siguiente paso es
un consejo, más que una necesidad porque depende de si hemos creado un
servidor para los repositorios remotos o no. Concretamente En mi caso
no lo creé y utilizo repositorios remotos locales, es decir, un
fichero .fossil accesible en el path. El problema es que cuando
añades un repositorio remoto, automáticamente lo activa como
autosync, es decir: automáticamente intenta sincronizar el remoto
cuando hacemos un commit en el local. Si no queremos ese
comportamiento o falla, como ocurre cuando el remoto no está en un
servidor propiamente dicho, sino que es local, os aconsejo desactivar
la autosincronización de repositorios.
$ fossil unset autosync
De esta manera actualizar la información se debe hacer en dos pasos:
primero con commit y luego con push.
También os recomiendo establecer un editor para los commits, que
como podéis suponer, en mi caso he configurado emacsclient para la
línea de comandos con:
$ fossil set editor "emacsclient -t"
Eso hace que el comando commit inicie el editor de nuestro gusto.
Sin embargo, si no tiene uno configurado hará el commit sin texto y
aunque luego lo podemos modificar en cualquier momento, siempre es
conveniente que vaya con las cosas puestas en su sitio y no tener que
hacerlo en varios pasos. El resto del proceso ya nos suena de otras
herramientas de este tipo:
$ fossil commit
emacsclient -t './ci-comment-1B1192236B5F.txt'
New_Version: 0c8f9ac2c71ab213545a0748d480be86301fac4e7aebb24282f279ea29c59884
$ fossil push remoto
Push to file:///home/notxor/repositorios/prueba.fossil
server says: 400 Bad Request
Push done, sent: 649 received: 1000 ip:
Bien, hasta aquí hemos visto un repositorio convertido desde otra
herramienta, pero ¿cómo inicio un repositorio si quiero utilizar
fossil como el control de versiones de mi proyecto? Pues crear un
proyecto nuevo es sencillo:
$ mkdir proyecto-nuevo $ cd proyecto-nuevo/ $ fossil init ../repositorios/proyecto-nuevo.fossil project-id: 668d16b369e69e92a6fb955710b2bf5f6936a31f server-id: 2d3f2b9eb6805b67900cbf761088ae089a636407 admin-user: notxor (initial password is "ztdSAUjxWP") $ ls -lah ../repositorios/ total 236K drwxr-xr-x 2 notxor users 35 nov 29 13:37 . drwxr-xr-x 113 notxor users 8,0K nov 29 13:36 .. -rw-r--r-- 1 notxor users 224K nov 29 13:37 proyecto-nuevo.fossil
En esos pasos creamos el directorio del proyecto e iniciamos un repositorio remoto (aunque local).
$ fossil open ../repositorios/proyecto-nuevo.fossil project-name: <unnamed> repository: /home/notxor/repositorios/proyecto-nuevo.fossil local-root: /home/notxor/proyecto-nuevo/ config-db: /home/notxor/.config/fossil.db project-code: 668d16b369e69e92a6fb955710b2bf5f6936a31f checkout: 00aeb8f8ba9b427317105151db1020840246dc47 2020-11-29 12:37:22 UTC tags: trunk comment: initial empty check-in (user: notxor) check-ins: 1 $ ls -lah total 44K drwxr-xr-x 2 notxor users 23 nov 29 13:37 . drwxr-xr-x 113 notxor users 8,0K nov 29 13:36 .. -rw-r--r-- 1 notxor users 32K nov 29 13:37 .fslckout
En este paso, abrimos el repositorio remoto en el directorio que hemos
creado para el proyecto. No hay ningún fichero aún ni nada que
actualizar, pero se crea el repositorio local. El resto es ir
encadenando instrucciones add, commit y push como hemos visto
antes.
Alguno pensaréis que teniendo el repositorio remoto en el directorio
de al lado en realidad no es remoto y pierde las fuerza de «copia de
seguridad» de tu trabajo. Y es cierto, sin embargo, para compensar, el
fichero .fossil lo puedes sincronizar en un directorio a tu nube
nextcloud, por ejemplo, o añadirlo a tus copias de seguridad
periódicas, o usar synthing o cualquier otra herramienta de
sincronización externa. Es un fichero monolítico sin dependencias
externas; ni siquiera fossil, porque toda la información está
contenida en una base de datos sqlite3; puedes abrirlo como tal,
─pero si lo haces ten cuidado de no tocar nada que no debes─.
Conclusiones
Estoy contento con fossil por las pocas pruebas que he hecho con él,
parece un sistema amigable y tiene características que lo hacen
interesante como son: foro, wiki, bug track, etc. Todo
autocontenido y sin necesitar otras herramientas externas. El slogan
que dice que «/fossil/ es github metido en una caja», tiene
razón. Por lo menos a simple vista y por lo poco que lo he usado y
trasteado.
Me falta ver cómo se comporta en un proyecto compartido con un servidor montado como corresponde. Pero de momento no descarto continuar usando esta herramienta para proyectos personales sin necesitar servidores externos y teniendo la posibilidad de mantener a mano un montón de herramientas para documentación y gestión de proyectos de código.
Lo voy a ir utilizando en pequeños proyectos personales a ver si
descubro alguna característica nueva o echo en falta algo. A ver si
termina de convencerme o desilusionarme. Es un sistema prometedor pero
¿tanto como para abandonar git? No lo creo, o al menos, no de
momento, en mi caso.
Comentarios