Tutorial de Fossil

Fossil es un Sistema Distribuído de Gestión de la Configuración bajo licencia GPL, conceptualmente muy similar a GIT, pero con diferencias relevantes que permiten su uso en entornos con muchas limitantes técnicas. Por eso, está dentro de mi lista de Software de Guerrilla que recomiendo tener a mano para misiones cortas y rápidas.

Si eres administrador en este sitio, puedes crear un nuevo repositorio fossil

Atención: La siguiente información asume que el lector entiende conceptos básicos de Gestión de la Configuración. Si usted no tiene conocimientos sobre Gestión de la Configuración, le recomiendo empezar por Gestión de la configuración 101

Las siguientes instrucciones están pensadas para correr Fossil sobre Linux. De todas formas, debería funcionar todo exactamente igual en sistemas operativos menores.

Flujo de Trabajo

Vamos a revisar un caso desde 0 donde generaremos un directorio local, una «copia de trabajo» que se sincronice con el repositorio. Este proceso tiene 2 variantes:

Variante 1: Crear Repositorio vacío desde 0

Crear un repositorio vacío es extremadamente simple:

> fossil new «repo»

Donde «repo» es el nombre del archivo que contendrá el repositorio. Sí, finalmente todo cae dentro de ese archivo: Versiones, Líneas Base, Branches, Configuraciones de Usuario, Wiki, Sistema de Tickets, etc. Todo. El archivo corresponde a una base de datos SQLite

Este comando da como resultado:

> fossil new «repo»
project-id: 5d4cfcceaf83f4701ac9a312931a01ec70938e9c
server-id:  db5bd876877b40b14f8a33ab4de77ebd5558a779
admin-user: bicubico (initial password is "05d78b")

Al finalizar el comando, se contará con un nuevo archivo llamado «repo», puedes poner el nombre que quieras.

Este archivo no hace mucho por si mismo. Para aprender a incorporar información, mira la sección Gestión de Configuración

Toma nota del usuario y password incial entregados, los necesitarás para la configuración del repositorio.

Variante 2: Clonar Repositorio existente desde una URL

La otra alternativa, es que quieras trabajar a partir de un repositorio existente.

Caso 1: Repositorio Público

> fossil clone «URL» «repo»

Caso 2: Repositorio Restringido

> fossil clone http://«usuario»:«password»@«URL» «repo»

donde «URL» es la URL al repositorio en un servidor Fossil. Más adelante se explica cómo hacer tu propio servidor fossil. El resultado de esta operación, es que se generará un archivo local («repo» para los ejemplos de esta página) que contiene todo el repositorio. Para hacer modificaciones al contenido del repositorio local (y luego al remoto) deberás primero ejecutar el comando open. Mira la sección Gestión de Configuración para ver eso.

Configuración

Filtrando archivos «Basura»

Para evitar versionar archivos sin importancia, podemos establecer reglas de le indiquen a Fossil que ignore los archivos subidos que presenten algún patrón particular.

> fossil settings ignore-glob "*.o,*.obj,*.exe, */obj/*, */bin/*, */debug/*" --global

Generando un Servidor de Fossil

Fossil posee un servidor web interno que permite acceder a la Wiki, al sistema de Tickets y al listado de archivos desde una interfaz web amistosa. Para ver esta interfaz en modo local, basta con usar:

> fossil ui

o para generar servidor accesible desde otras IPs (por ejemplo, desde otro computador en la misma red) se usa:

> fossil server

Para cualquiera de los casos, el resultado de esta invocación genera por consola la siguiente información:

> fossil server
Listening for HTTP requests on TCP port 8080

Gestión de Configuración

Para trabajar con Fossil, lo primero que debes hacer es desplegar la información del repositorio en tu entorno local. Es en ese entorno local donde harás las modificaciones a los archivos, añadirás documentos, código, etc. Y luego «empujarás» tus cambios hacia el servidor de Fossil. Dependiendo si tienes conexión a la red, o no, podrás empujar hacia tu repositorio local, o sincronizar al repositorio en el servidor.

> mkdir «directorio» && cd «directorio»
«directorio»/ > fossil open ../«repo»

Aquí estamos creando un directorio donde residirán los archivos del directorio local, ubicado un directorio más “adelante” en la estructura. Por eso abrimos el archivo «repo» haciendo referencia al directorio anterior.

Si el repositorio tenía información, se desplegará dentro del directorio. Si estaba vacío, a pesar de no desplegarse nada en el interior, igualmente se establece un vínculo entre el contenido de ese «directorio» con «repo», así, cuando se añadan archivos, o se realice un Commit, se harán directamente contra el «repo» sin necesidad de entregarle nuevamente la ruta.

Para todos los sistemas de Gestión de Configuración es necesario ser explícito en las instrucciones. El sistema no es un «dropbox» que guarda todo. El sistema guarda lo que el usuario, en conciencia, dice que se guarda.

Esto significa que para añadir (o eliminar) un elemento del sistema de gestión de configuración es necesario añadirlo en forma explícita. Un comando útil, si quieres añadir todo es:

> fossil add .

O por el contrario, si lo que se desea es añadir un archivo específico, es posible usar:

> fossil add main.cpp

Añadir (o eliminar) usando los parámetros add o rm no hacen nada por si solos. De hecho, es perfectamente posible hacer cientos o miles de cambios en los archivos y nada quedará «sellado» en el sistema. Sólo cuando hagas commit es cuando realmente se ejecutarán los cambios.

Para saber el listado de cambios que están listos para ser ingresados al sistema con commit, puedes usar el comando:

> fossil changes

Por otro lado, si sientes que no están todos los archivos que deberían estar dentro del paquete de commit, puedes revisar el listado de archivos que no tienen instrucciones de ser parte del sistema, usando:

> fossil extras

Cuando esté todo preparado y listo para enviar los cambios al servidor de Fossil, pueden usar commit para enviar el paquete. A pesar de que se puede usar sin parámetros, recomiendo fuertemente usar «fossil commit -m “mensaje”» para asignar una descripción al conjunto de cambios.

> fossil commit -m "Primer conjunto de código."

Algo importante: Fossil, por defecto, opera con un esquema de Autosync. Eso significa que automáticamente al hacer un Commit, primero trae la última versión de lo que está en el servidor. Detecta conflictos, y si no hay problema, recién entonces envía los cambios. Esto es muy similar a la operación por defecto de Subversion.

> fossil commit -m "Primer commit, carga de archivos base"

Casos Especiales

Dado que fossil, por su naturaleza realmente descentralizada, puede ejecutarse como server en servidores ad-hoc que pueden tener cambios en sus URL de sincrinización, pueden volver a establecer la url con el repositorio padre a través de la siguiente instrucción:

fossil remote-url «URL»

Software de Guerrilla

Software de Guerrilla.- Dícese del software efectivo, de bajo consumo de recursos y de disponibilidad inmediata que puede salvarte la vida. Porque nunca se sabe cuando vas a tener que armar un entorno de trabajo desde 0 en menos de 1 hora.

Fossil: Sistema distribuído de Gestión de Configuración, Documentación, Wiki y Ticket System

Fossil es maravilloso, efectivo y tremendamente flexible. Puedes leer más acá

TiddlyWiki: Una wiki completa en un solo archivo


GMO: Guilt Management Office

Muchas más veces de lo que me gustaría, me encuentro con organizaciones (especialmente la que tienen una jerarquía de muchos niveles) en que es “Estilo de Management” consiste en pedir fechas y mandar minutas de compromisos. Hasta ahí, todo relativamente normal, pero el uso de estas minutas es para cubrirse las espaldas y poder responsabilizar a otro de lo que no funciona.

Aparte de ser un comportamiento radicalmente egoísta y que muestra la nula capacidad o interés de trabajar en equipo hacia un objetivo común, estás prácticas de “Aseguramiento de la existencia de Culpables” y de escalamiento por conveniencia generan que se adopte el mismo esquema para protección, lo que redunda en tener neuronas y talentos dedicados a la Gestión de Culpabilidad en vez de hacer trabajo real productivo.

¿Cómo reconocer si hay una GMO operando en mi organización? Fácil:

  • Áreas paralelas buscan compromisos de fechas sin interesarse en trabajo real a hacer
  • Correos asociados a peticiones de compromisos van con copia a 3 niveles de Management
  • Roles evitan apoyar iniciativas que son de otras áreas
  • Se generan con facilidad reuniones periódicas para obtener status de proyecto con participantes de múltiples áreas
  • Cuando algo falla, la primera pregunta es “¿Quién es responsable?” en vez de “¿Cómo ayudo a resolverlo?”

~~DISQUS~~