---
breaks: false
info: |
Este documento fue creado por la comunidad de Grafoscopio durante nuestros talleres,
llamados Data Weeks y Data Rodas.
Para saber más sobre el proyecto y las recomendaciones de edición y colaboración
sobre este y otros documentos visita el repo.
repo: https://mutabit.com/repos.fossil/documentaton/
sync:
- https://docutopia.tupale.co/documentaton:fossil
- repo://es/capitulos/fossil.md
variants:
- https://docutopia.tupale.co/fossil-dataweek
---
# Fossil: Trabajo colaborativo distribuido
:::success
- **Propósito**: Introducir los sistemas de control de versiones, en especial, Fossil.
- **Ejercicio práctico**: Clonar un repositorio en Fossil, registrarse en él, sincronizarse
y agregar nuevo contenido, hecho en Markdown.
- **Prerequisitos**:
- **Lección**: [Markdown](./markdown).
:::
Fossil es un sistema de colaboración distribuido para gestión de código fuente.
Los SCM (Software Configuration Management) o DVCS (Distributed Version Control System)
resuelven el problema respecto a cómo reproduzco el estado de un sistema
de cómputo y su historia (orientado a archivos).
Al resolver esta inquietud, se está resolviendo una pregunta incidental que
es sobre cómo colaborar, de maneras no centralizadas.
Fossil es el SCM elegido para trabajar con [Grafoscopio][grafoscopio] y el Data Week
por su caracter sencillo y autocontenido, lo cual quiere decir que brinda
mucha funcionalidad en un único programa, con flujos de trabajo y colaboración simples,
y puede ejecutarse en una variedad grande de plataformas de hardware y software, con
mínimos requerimientos de recursos de hardware (poca memoria RAM, menos de 3 Mb en
disco duro) y software, además tanto los datos como los metadatos (salvo las contraseñas)
son repartidos entre todos los usuarios que se sincronicen al repositorio, es decir,
satisface nuestra definición de [infraestructuras de bolsillo](./infraestructuras-de-bolsillo.md).
Existen algunas pocas herramientas para Git, como [Gogs](https://gogs.io/ ),
que siguen el enfoque minimalista de Fossil, si bien no toda la información
parece ser autocontenida e implican los flujos de trabajo complicados propios
de Git.
**Referencias Extra:**
- [Página principal de Fossil](http://fossil-scm.org/ ).
- Son habituales las discusiones y comparaciones de Fossil contra los sistemas
más populares, particularmente Git, así que acá algunos enlaces (de documentos en
Inglés) que te ayudarán a tener una perspectiva informada, para defender el uso de
Fossil vs Git, o para saber cuándo usar cuál:
- [Why You Should Use Fossil](https://www.fossil-scm.org/xfer/doc/trunk/www/whyusefossil.wiki ).
- [The Fossil Web Interface][fossil-web-interface]: Muestra varias de las
características que Fossil integra desde su interfaz web.
Veremos algunas de ellas en este mismo documento.
- [Preguntas y críticas](https://www.fossil-scm.org/xfer/doc/trunk/www/qandc.wiki ).
- [Fossil vs Git](https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki).
- [Citas: Lo que la gente está diciendo][fossil-quotes].
- [Evaluaciones](http://fossil-scm.org/index.html/doc/trunk/www/reviews.wiki ).
- [Documentación embebida para proyectos][fossil-embbeded-doc]: Esta es
la forma de documentación que empleamos para el Data Week y Grafoscopio.
Explica cómo usarla y cómo acceder a la última versión de un documento, o
la que habrá de enviarse al repositorio, o la de alguna fecha o *commit*
específicos.
- [Reglas de Markdown usadas por Fossil](../md_rules).
- [Fossil User Manual](https://www.fossil-scm.org/schimpf-book/home): Un texto detallado y con ejemplos sobre cómo usar Fossil en proyectos colaborativos.
Si bien corresponde a una versión antigua de Fossil, las lógicas de uso y muchas de las interfaces siguen siendo
utilizables hoy en día.
- [Compilando Fossil con soporte para JSON](https://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeline-to-another-format).
- Clay Shirky: [How someday Internet will one day transform the government][shirky-git]:
Una presentación, más bien simplista, sobre cómo estas tecnologías tipo Git y fossil
podrían cambiar prácticas de poder, participación y democracía.
- Fossil en modelo bazar: Explica cómo usar Fossil en contextos donde no se conocen previamente los colaboradores.
- [Bazaar model with Fossil (hilo en el foro)](https://fossil-scm.org/forum/forumpost/7b03087944).
- [Bazar model with Fossil](https://board.asm32.info/bazaar-model-with-fossil-scm.269/).
- [Hacking on the PiDP-8/I Software](https://tangentsoft.com/pidp8i/doc/trunk/HACKERS.md).
- [Contributing To Fossil](https://fossil-scm.org/fossil/doc/trunk/www/contribute.wiki).
[fossil-web-interface]: https://www.fossil-scm.org/xfer/doc/trunk/www/webui.wiki
[fossil-embbeded-doc]: https://www.fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki
[fossil-quotes]: http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki
[shirky-git]: https://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government
## Instalación
Antes de proceder a la instalación es conveniente verificar si ya se tiene
instalado fossil (por ejemplo verificar si el comando "fossil" existe
tecleando `$ which fossil`).
### En Gnu/Linux
Averigua con el gestor de paquetes (apt, pacman) si tu distribución de Linux tiene
Fossil disponible en una [versión relativamente reciente][fossil-version] (como
las que usamos para nuestros talleres) e instálada desde dicho gestor.
[fossil-version]: https://www.fossil-scm.org/index.html/uv/download.html
:::warning
En nuestra experiencia, algunas distribuciones derivadas de Debian,
suelen tener paquetes muy viejos de Fossil.
:::
### Usando gestores/instaladores de software
Más información [acá](./instaladores-gestores-software)
### Windows
#### Con Scoop
:::info
**Importante:** Para hacer estar parte debes haber [instalado previamente Scoop](./instaladores-gestores-software#Scoop).
:::
Abrimos Power Shell y escribimos:
```
scoop install fossil
```
Al ejecutarlo, debemos ver algo como esto:
```
Installing 'fossil' (2.8) [32bit]
fossil-w32-2.8.zip (2.1 MB) [=================================================================================] 100%
Checking hash of fossil-w32-2.8.zip ... ok.
Extracting fossil-w32-2.8.zip ... done.
Linking ~\scoop\apps\fossil\current => ~\scoop\apps\fossil\2.8
Creating shim for 'fossil'.
'fossil' (2.8) was installed successfully!
```
#### Métodos de instalación alternativos
Se puede instalar desde el gestor de paquetes en Linux, Mac, Windows, pero cuando está muy desactualizado,
una alternativa es instalarlo desde el código fuente.
- Entramos a la [página de descargas de Fossil](http://fossil-scm.org/index.html/uv/download.html )
y allí bajamos la última versión disponible para Windows.
- Una vez hallamos descompreso el archivo descargado, nos mostrará los contenidos
del archivo zip, con un único elemento que es el archivo `fossil.exe`.
- Copiamos el archivo `fossil.exe` dentro del zip descargado y lo pegamos a la
carpeta `C:Windows\`.
- Abrimos la consola de comandos en Windows y escribimos `fossil` en ella.
Debe aparecer algo como:
#### Gnu/Linux y Mac
Así se hace esto en Gnu/Linux y Mac, usando comandos en la terminal:
1. Descargar el instalador desde la página web:
cd /tmp
wget http://fossil-scm.org/index.html/uv/fossil-linux-x64-2.3.tar.gz
2. Descomprimimos el archivo:
tar xvfz fossil-linux-x64-2.3.tar.gz
3. Encontraremos un binario llamado `fossil` que copiamos a donde están todos los binarios:
sudo cp fossil /usr/bin
## Trabajar con repositorios
Para usar Fossil, vamos a sincronizarnos contra un repositorio, agregar archivos
a este y mirar cómo ha cambiado su línea de tiempo.
Hay otras cuestiones que vamos a dejar en el radar, pero que no vamos a profundizar,
como el hecho de publicar repositorios propios.
Sin embargo, ese tipo de funcionalidad también está provista por sistemas como
[Chisel](http://chiselapp.com/ ).
### Navegación
Existen determinados lugares para visitar con los cuales uno se puede
hacer una idea de un repositorio de Fossil, sus contenidos y actividad.
A continuación los listamos esos lugares, mostrando algunos ejemplos de
los mismos en distintos repositorios.
- Portada:
- Para Grafoscopio: <http://mutabit.com/repos.fossil/grafoscopio/>
- Para el Data Week: <http://mutabit.com/repos.fossil/dataweek>
(es la misma que está acortada en http://is.gd/oddbog )
- La línea de tiempo:
- Data Week:
- Por omisión: <http://mutabit.com/repos.fossil/dataweek/timeline>
- Los últimos 500 "commits": <http://mutabit.com/repos.fossil/dataweek/timeline?n=500&y=all&t=&ms=exact>
- Los contenidos (archivos o carpetas):
- Para el Data Week: http://mutabit.com/repos.fossil/dataweek/dir
- Los "tickets" (solicitudes, peticiones, asuntos):
- De Grafoscopio: <http://mutabit.com/repos.fossil/grafoscopio/rptview?rn=1>
### *Tickets*: Sugerencias, correcciones y planeación
Una de las maneras más habituales de usar repositorios es a través de los _tickets_ (boletas), que permiten realizar sugerencias sobre
mejoras o ampliaciones, reportar errores para realizar correcciones e incluso hacer una gestión ligera de cómo el proyecto va dando
cuenta de las solicitudes que se hacen sobre el mismo.
Acá veremos cómo realizar cada una de estas actividades.
#### Crear un _ticket_
Empecemos por crear un _ticket_. Estos son los pasos:
- **Visitamos la sección de tickets**: en el del repositorio de Fossil respectivo cliqueamos en el enlace de _tickets_, usualmente
referenciado en la portada o agregamos agregamos `/ticket` a la dirección principal del repositorio, por ejemplo para el repositorio
de esta obra, la página de tickets es: <https://mutabit.com/repos.fossil/documentaton/ticket>.
Veremos una imagen como la siguiente:
{width=60% #fig:tickets-home}
- **Revisamos los _tickets_ preexistentes**: Esto lo hacemos antes de crear un nuevo ticket, de modo que podamos verificar que el nuestro
no se encuentra ya reportado o podamos ver aquellos que estarían relacionados con el nuestro.
Para esto cliqueamos el enlace que dice "All Tickets" y se nos mostrará una página como esta:
{width=60%}
La tabla de resumen previa nos muestra en la primera columna un identificador único para cada ticket, en la siguiente la fecha de
creación, luego su tipo, el subsistema en el cual se presenta (en caso de ser reportado) y un título que resume el asunto del que se
trata.
- **Miramos los detalles de un _ticket_** (Opcional) Al cliquear en el identificador único, en la tabla anterior, podemos ver información en
mayor detalle del cada _ticket_, por ejemplo las conversaciones que se están teniendo al respecto y quiénes participan de las mismas.
Esto es lo que vemos si hacemos click en el enlace [e5100df2ed](https://mutabit.com/repos.fossil/documentaton/tktview?name=e5100df2ed):
{width=40% #fig:detalles-ticket}
- **Creamos uno nuevo _ticket_**: Esto lo hacemos en caso de que ningún _ticket_ se refiera a aquello que queremos reportar, (de lo contrario
es mejor si participamos en la conversación que ya existente al respecto).
Para ello, hacemos click en "New Ticket", bien sea en la página de los detalles de cualquier ticket (ver figura @fig:detalles-ticket ) o en
la página inicial (ver figura @fig:tickets-home).
Si no estamos acreditados en el repositorio veremos una página como la de la figura , que nos permitirá crear _tickets_ de manera anónima,
al tiempo que controla los mensajes indeseados en el repositorio (también conocidos como SPAM).
{#fig:reporte-anonimo width=60%}
Bien sea como usuarios anónimos o registrados en el repositorio, una vez cliqueamos el enlace de "New Ticket", veremos un formulario como
este:
{width=60%}
- **Llenamos el formulario**: eligimos las opciones del formulario que mejor describen lo que queremos y diligenciamos sus campos.
A modo de ejemplo y siguiendo nuestra predilección por lo auto-referencial, crearemos un ticket sobre explicar la creación de nuevos tickets.
El nombre de cada campo estará en _cursiva_ y el valor diligenciado o seleccionado estará al frente en fuente `monoespaciada`.
Así diligenciaremos los campos:
- _Enter a one-line summary of the ticket_: `Explicar cómo crear nuevos tickets`.
- _Type_: `Feature_Request`, pues estamos solicitando una nueva característica en el documento.
Debido a los usos habituales de Fossil, la mayoría de las opciones para este campo están pensadas para proyectos de software.
`Code_Defect` se usa cuando estamos reportando errores en el software; `Build_Problem` para cuando es imposible crear el archivo
derivado a partir de las fuentes (un binario, en caso de software o un PDF, EPUB o similares en el caso de documentos); `Documentation`
se usa para la documentación que acompaña a los proyectos de software (pero en nuestro caso sería muy redudante, pues todo el proyecto
es un documento).
- _Severity_: `Important`.
Acá juzgamos qué tan clave es que dicho asunto sea resuelto dependiendo de cómo nos afecta a nosotros y al proyecto.
- _EMail:_ Colocamos el correo si queremos ser contactados sobre la resolución del mismo.
Obsérvese que también podemos seguir un proyecto a través de la suscripción a su archivo de sindicación en línea o RSS.
(El del repositorio de este libro está en la portada).
- _Format_: `Markdown`.
Es el formato en el cual escribiremos el reporte.
La opción recomendad es Markdown, por todos los argumentos que ya hemos dado.
Es importante anotar que Fossil tiene una variante especial, de modo que aquellas palabras entre paréntesis angulares (`[]`), se convierten
en enlaces al repositorio, lo cual será útil para referenciar _commits_ y eventos particulares, como veremos en la siguiente subsección.
{width=70%}
- **Revisamos el formulario, lo re-editamos y enviamos**: Una vez diligenciado el
formulario, veremos una vista previa muy similar a la del formulario previo, pero el código
Markdown será previsualizado en esta y nos ofrecerá un botón de submit.
Si necesitamos editar algo más, lo continuamos haciendo y cliqueamos el botón
`Preview`, de lo contrario hacemos click en el botón `Submit`, lo cual nos mostrará
el ticket como aparece en el repositorio, como se muestra en la siguiente imagen.
{width=60%}
Uno de los aspectos más importantes a tener en cuenta será el _Ticket UUID_, que es
un identificador alfanumérico único del _ticket_, que usaremos para ubicarlo y referirnos al mismo luego.
La primera parte de éste es el que aparece en la tabla donde se pueden ver todos los _tickets_, a la que
ya nos hemos referido.
- Si hacemos click en la línea de tiempo y seleccionamos la opción _tickets_ de la misma, veremos nuestro nuevo _ticket_
como primero en esa lista, como se muestra a continuación:
{width=60%}
El la combinación alfanumérica que aparece entre paréntesis angulares es la versión resumida del _ticket UUID_ y podemos usarla para enlazarlo desde otros lugares de Fossil, en particular desde otros _commits_.
Este será el tema de la seguiente sección.
#### Cerrar un _ticket_
La sección precedente nos enseñó como abrir un _ticket_ y nos dijo que esta era una de las formas más
habituales de trabajo con los repositorios, como usuarios del proyecto que allí se construye.
Esta sección muestra otra de las formas más habituales de trabajo, como co-autores del mismo: cerrar _tickets_.
Para esta sección, supondremos que tienes familiaridad con el resto del capítulo sobre Fossil.
Si estás leyendo el libro en orden y sólo has leído hasta acá, es conveniente que la saltes y
aprendas el resto de los elementos del trabajo básico con repositorios (clonación, modificación, etc),
antes de proceder a cerrar el _ticket_.
Hemos dejado esta sección acá, simplemente para manetener consistente la presentación.
Cerrar un _ticket_ puede ocurrir por distintos motivos, pero el más usual de ellos es que hicimos trabajo
dentro del repositorio para abordarlo.
De este modo, los _commits_ en el repositorio y los _tickets_ pueden enlazarse, de modo que el trabajo hecho esté en el repositorio conectado con el reporte que solicitaba hacerlo.
Tomemos por ejemplo el ticket de la sección precedente.
Una vez hemos empezado a explicar en la obra el aspecto que el _ticket_ nos solicitaba, escribiendo y modificando los textos que dan cuenta de ello (bien sea en prosa o código) podemos hacer un commit indicándolo, con un comando como este:
```bash
fossil commit -m "Pandoc: Abordando ticket [921caf54a2]."
```
Veamos cómo queda la línea de tiempo en este caso:
{width=60%}
Vemos quel el último commit dice algo como:
```
Pandoc: Abordando ticket [921caf54a2] Leaf check-in 9f8e9e98f1
```
es decir que hemos vinculado el check-in `9f8e9e98f1` con el ticket `921caf54a2` y si miramos los detalles del primero, veremos cuáles archivos cambiaron para poder abordar esta solicitud, en particular veremos esto:
{width=60% #fig:ticket-diff}
Es decir, que un lector del repositorio está en condiciones de ver los archivos que se modificaron y en qué partes, para dar cuenta de determinada solicitud.
Esto puede ocurrir para trozos de texto sustanciales, como en este caso, o porque hicimos cambios pequeños, como agrega una imagen a un capítulo o sus cabeceras, redimensionarla, o porque hicimos varias correciones de estilo u ortográficas.
De este modo, cambios grandes o pequeños, solicitados por los lectores y usuarios de nuestra creación, pueden ser auditados asociándolos con los cambios efecticamente hechos en los
archivos, para dar cuenta de los mismos.
Ahora bien, los vínculos son mejores en la web, si funcionan de doble vía.
Cuando vayamos a cerrar el ticket, entrando en el mismo desde la tabla de resumen de todos ellos, mostrada en la sección precedente,
es conveniente indicar que identificadores de los commits corresponde a aquellos donde se hizo trabajo en el _ticket_.
Por ejemplo, ahora que se ha explicado un poco más sobre como cerrar el _ticket_, haremos
otro _commit_, similar al anterior:
```
fossil commit -m "Fossil > Tickets: Cómo cerrarlos (ver [921caf54a2])."
```
Lo cual produce esta línea de tiempo ahora:
{width=60%}
y cuando editemos el ticket `921caf54a2`, para cerrarlo.
El formulario para cerrar ticket quedaría algo así:
{width=70%}
Nótese que hemos cambiado el campo _Status_ por `Closed` y el campo _Resolution_ por `Fixed`, y en la descripción detalllada de cómo lo cerramos hacemos referencia a aquellos commits que hablaben del mismo en la línea de tiempo, en este ejemplo aquellos con los identifadores `[9f8e9e98f1]` y `[49406fac71]` (recordemos que al usar los paréntesis cuadrados, los convertimos automáticament en un enlace dentro del repositorio).
Veamos cómo queda ahora la línea de tiempo:
{width=70%}
El ticket que hemos cerrado aparece tachado (~~`[921caf54a2]`~~) y todos los estados de la línea de tiempo correspondientes a commits donde se referencio dicho ticket continuan enlazados al mismo.
A su vez, si hacemos click en el ticket, veremos que apunta a los commits en líneas de tiempo donde trabajamos en el mismo:
{width=60%}
De este modo Fossil nos provee una manera ligera de gestionar proyectos, mediante una práctica sencilla: enlazar _commits_ y _tickets_ entre sí.
Una vez hallamos creado un ticket, usamos su UUID resumido y entre paréntesis angulares para los commits que trabajen en el mismo y, una vez cerremos el ticket, hacemos lo propio para los commits, creando así una vinculación en doble vía.
Si por alguna razón se reabre un _ticket_, es posible repetir este procedimiento con futuros _commits_ para abordarlo y ediciones del mismo para cerrarlo.
Ya sea que queremos reportar y corregir errores o solicitar e implementar nuevas características en nuestra obra, esta manera de proceder nos permitirá indicar con agilidad qué hemos hecho en cualquiera de esos frentes y hacerlo transparente a la comunidad que se reune en torno a la obra.
### Clonación
:::warning
**ADVERTENCIA**: asegurarse que los comandos se ejecutan en el directorio correcto
porque se pueden crear un montón de directorios y cosas en un directorio que no se desea.
:::
Cuando se descarga un repositorio lo que se hace es traer toda la historia del mismo
de su lugar remoto a mi disco duro.
Vamos a hacer esto con el repositorio de la Documentanton, desde la consola de comandos.
- Creamos una carpeta para el repositorio del proyecto actual. Para Mac:
`mkdir ~/Documentos/<nombre_repositorio>`
- Para Windows, ingresar a la linea de comandos (cmd):
`md ~/Documentos/<nombre_repositorio>`
Donde *<nombre_repositorio*> es el nombre de la carpeta a descargar (repositorio).
- Nos ubicamos en esa carpeta creada:
`cd ~/Documentos/<nombre_repositorio>`
- Clonamos el repositorio:
`fossil clone http://mutabit.com/repos.fossil/<nombre_repositorio>/ <nombre_repositorio>.fossil`
Al final de proceso deberá aparecer algo similar a:
```bash=
project-id: aa9f6e73b4f326e190f15c4a830c0909619bfa42
server-id: 1f91261cb649d68c08dc75f7609975b787bc754f
admin-user: Pibi (password is "acead4")
```
- Abrimos el repositorio:
`fossil open <nombre_repositorio>.fossil`
y se deben ver los mismos [contenidos del repositorio remoto][dw-contents]
en nuestro disco duro local. Debera aparecer algo similar a:
```bash=
project-name: Documentaton
repository: D:/documentaton/documentaton.fossil
local-root: D:/documentaton/
config-db: C:/Users/palza/AppData/Local/_fossil
project-code: ac6959a5354c5b489888aa795e38efab1fdac313
checkout: 696a19768f970fb89a660e0ec6ffcbf5219eb205 2019-03-10 00:23:10 UTC
tags: trunk
comment: initial empty check-in (user: offray)
check-ins: 1
```
[dw-contents]: http://mutabit.com/repos.fossil/<nombre_repositorio>/dir?ci=tip
### Modificación
Vamos a crear un archivo en una subcarpeta dentro de la carpeta de idiomas, que contiene un de los capítulos del librillo.
- Crear la carpeta propia:
`mkdir -p es/capitulos`
- Descargamos un archivo de Markdown (digamos [la presentación](https://docutopia.tupale.co/documentaton:presentacion#)) y lo salvamos con un nombre corto (digamos `presentacion.md`) dentro de esa carpeta.
- Agregamos ese archivo a ese repositorio
```bash=
fossil add es/capitulos/presentacion.md
```
**Nota**: Recuerda que Los símbolos `<` y `>` no se incluyen
La respuesta debería ser algo como
```bash=
ADDED es/capitulos/presentacion.md
```
- **Realizamos una actualización al repositorio** (en caso de que hayan habido cambios por otros mientras realizábamos los nuestros) y hacemos nuestro primer commit, con un mensaje descriptivo:
```bash=
fossil update
fossil commit -m "<comentario corto descriptivo>."
```
Puede que recibamos mensajes sobre que no podemos autosincronizar.
Por lo pronto no haremos caso de ellos.
Para ver lo que ocurre en el repositorio escribimos `fossil ui`,
que despliega la interfaz gráfica de usuario en nuestra máquina.
(Esto ocurre en menos de 3 Mb!).
Debemos ver algo cómo:
### Sincronización
La sincronización entre repositorios es hecha a través de un servidor que sirve como coordinador.
En nuestro caso, será el repositorio original del Data Week.
Lo anterior quiere decir que debemos registrarnos en dicho repositorio y solicitar
permisos para sincronizarnos con él.
- Entramos a la [página de ingreso (login)](http://mutabit.com/repos.fossil/documentaton/login ),
específicamente a la [página de registro ](http://mutabit.com/repos.fossil/documentaton/register?g= ).
Veremos algo como esto:
{width=85%}
- Configurar usuario de fossil
Esto se debe hacer si el usuario del sistema local (del pc) no es el mismo que se creó en el login del paso
anterior. Fossil por defecto toma el nombre de usuario del sistema local (del PC).
- Crear usuario nuevo en fossil local
`fossil user new <usuario>`
- Ponerlo como usuario por defecto
`fossil user default <usuario>`
Donde <usuario> es el usuario que creamos en el paso anterior del "login" (sin los símbolos `<` `>`).
- Sincronización: dentro del repositorio hacemos:
Hacer un update primero (pues probablemente hay cambios nuevos que no se tienen):
fossil update
`fossil sync http://<usuario>@mutabit.com/repos.fossil/<nombre_repositorio>/`
donde <usuario> es el nombre del usuario con el que nos registramos en Fossil y <nombre_repositorio> es el nombre del repositorio (carpeta descargada)
::: success
En caso de que la actualización falle, es probable que hayas realizado una sincronización con
un usuario incorrecto, verifica el usuario con que estas sincronizando, recuerda que fossil es
sensible a minusculas y mayusculas.
:::
Deberas tener una respuesta como esta:
```bash=
Round-trips: 2 Artifacts sent: 0 received: 4
Sync done, sent: 1123 received: 3782 ip: 45.55.37.99
```
### Cómo resolver las bifurcaciones involutarias (forks).
La diferencia entre "branches" y "forks":
- [What is the difference between a "branch" and a "fork"?](http://fossil-scm.org/index.html/doc/trunk/www/faq.wiki#q2 ).
- [Branching, Forking, Merging, and Tagging Login](http://fossil-scm.org/index.html/doc/trunk/www/branching.wiki ).
El estado del [repositorio](http://mutabit.com/repos.fossil/dataweek/timeline ) a hoy era este:
{width=85%}
Vemos que se han integrado dos bifurcaciones, pero aún quedan tres por integrar.
Cada estado del sistema está descrito por un código alfanumérico único, [suma hash](https://en.wikipedia.org/wiki/Checksum ).
Las ramas que fueron integradas corresponden (en la imagen) a las siguientes sumas hash:
`[f0ea5717e4]` (El commit de Grace) y el tronco (trunk) de ese momento, cuyo _checksum_
corresponde a `[1b5023d5a4]`, produciendo un estado del sistema nuevo, cuyo _checksum_
es `[dcd4e53045]`.
Vamos a integrar una nueva ramificación en el tronco principal.
Para ello, ubicados en el repositorio, desde la terminal
fossil update trunk
fossil merge 0ef40cd985
Aparecerá algo como esto:
Autosync: http://offray@mutabit.com/repos.fossil/<nombre_repositorio>/
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 383 received: 2429 ip: 45.55.37.99
ADDED Participantes/Ivan/intro.md
"fossil undo" is available to undo changes to the working checkout.
WARNING: multiple open leaf check-ins on trunk:
(1) 2018-02-24 18:59:24 [dcd4e53045] (current)
(2) 2018-02-24 01:33:03 [5da6cdb6dc]
(3) 2018-02-24 01:32:45 [0a25a7636d]
(4) 2018-02-24 01:31:51 [0ef40cd985]
Luego hacemos un commit al repositorio:
fossil commit -m "Integrando cambios de Iván."
Y luego mezclamos ese commit con el tronco principal, que de ahora en adelante llamaremos
simplemente "trunk".
Veremos algo como esto:
{width=85%}
**NOTA:** Si olvidas hacer el `fossil update trunk` antes de hacer el merge, puedes usar `fossil undo` para revertir el cambio.
## Varios
- **¿Cómo saber la URL del repositorio?**
Tiene que ser dada por el "proveedor" del repositorio.
- **¿Qué quiere decir cuando aparece "Fossil internal error: repository doesn't not exist ...
mapeda.fosil"?**
Que se está intentando abrir un repositorio sin estar ubicado en la carpeta donde se clonó,
o que se está intentando clonar en la carpeta de otro repositorio, sin haberlo cerrado previamente
- Ayuda en fossil: ```fossil help COMMAND ``` (con ```fossil help``` da la lista de
posibles comandos )
[grafoscopio]: http://mutabit.com/grafoscopio/
<!--
[[Indice](./indice-tematico)] [< [Markdown](./markdown)] [[Grafoscopio](./grafoscopio) >]
-->