Notxor tiene un blog

Defenestrando la vida

Probando fossil

2020-11-30

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:

  1. 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.
  2. Interface web del repositorio: el comando fossil ui nos abre un navegador1. Por defecto nos arrancará en el timeline.
Screenshot_2020-11-29_rerl_Timeline.png

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.

  1. 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.
Screenshot_2020-11-29_rerl_Help.png
  1. 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 sqlite3 haciendo que toda la información esté junta sin dispersar ficheros por directorios.
  2. 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.
Captura-vista-fichero.png

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
  1. 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.

Nota al pie de página:

1

Se puede configurar cuál, no tiene por qué ser el navegador que tengas configurado por defecto.

2

Puede ser cualquier sitio al que tengamos acceso directo. Si está en la red hay que montar un servidor para acceder por http, https, ssh o cualquier otro método de los permitidos.

Categoría: fossil linux

Comentarios

Debido a algunos ataques mailintencionados a través de la herramienta de comentarios, he decidido no proporcionar dicha opción en el Blog. Si alguien quiere comentar algo, me puede encontrar en Mastodon y en Diaspora con el nick de Notxor.

También se ha abierto un grupo en Telegram, para usuarios de esa red.

Disculpen las molestias.