Por qué SQLite no usa Git

• El código fuente de SQLite se gestiona con Fossil, no con Git; Fossil es un sistema de control de versiones diseñado y escrito específicamente para dar soporte a SQLite
• Fossil ofrece una función de conciencia situacional (situational awareness) que muestra los cambios recientes de todas las ramas en una sola pantalla, y además se puede consultar desde el celular
• Mientras que Git solo rastrea el historial anterior de un check-in y dificulta seguir sus descendientes posteriores, Fossil muestra fácilmente los check-ins posteriores y la estructura de ramas
• Con Git hay que tener presentes 5 estados: directorio de trabajo, staging, head local y remoto, etc.; con Fossil solo se consideran el directorio de trabajo y el check-in, lo que implica 60% menos carga
• Incluso quienes ya están acostumbrados a Git pueden acceder al código fuente de SQLite de la misma forma mediante el mirror en GitHub, descargas web o instalación de Fossil

---

Resumen y premisa del texto

• SQLite usa Fossil en lugar de Git, y Fossil es un sistema de control de versiones creado directamente con el objetivo de dar soporte a SQLite
• Este texto no es una comparación entre Fossil y Git, ni busca recomendar que se deje de usar Git
  • Si estás conforme con Git, no hay problema en seguir usándolo
  • Si Git no te termina de encajar, o estás pensando en mejoras o alternativas, aquí se presentan algunos puntos de vista útiles
• Este documento ha sido revisado varias veces para mejorar su claridad y corregir errores, y se puede consultar todo el historial de edición

Razones por las que SQLite no usa Git

Git no ofrece buena conciencia situacional

• El timeline de Fossil ofrece, en una sola pantalla, un resumen de los cambios recientes de todas las ramas; con unos pocos clics se puede ver el detalle, y además funciona desde el celular
• GitHub y GitLab no tienen una función equivalente
  • La vista de network es lenta al renderizar (antes del caché), da pocos detalles y casi no funciona en móvil
  • La vista de commits es rápida y funciona en móvil, pero solo muestra una rama a la vez, así que cuesta saber si ya revisaste todos los cambios
  • GitHub y GitLab son servicios de terceros, no componentes centrales de Git, así que agregan dependencias extra
• Los usuarios de Git suelen instalar visores gráficos de terceros, pero eso requiere instalación y mantenimiento aparte, además de depender de la plataforma
  • Una de las buenas herramientas, GitUp, solo funciona en Mac
  • Todas las herramientas exigen sincronizar el repositorio local y luego abrir una GUI de escritorio; no es posible revisar el estado del proyecto desde fuera usando el celular

En Git es difícil encontrar los descendientes de un check-in

• Git permite mirar hacia atrás en el historial, pero seguir lo que vino después es difícil
  • Para un check-in antiguo concreto, se puede ver lo anterior, pero es complicado averiguar qué vino después
• Fossil ofrece una pantalla que muestra todos los check-ins derivados del último major release
• En Git no es imposible encontrar descendientes, pero sí difícil
  • En Stack Overflow existe una secuencia de comandos para Unix, pero ese comando solo imprime una lista de descendientes sin estructura de ramas
  • Ese comando solo funciona si tienes un clon local; en interfaces web como GitHub o GitLab no se pueden ver los descendientes
• En Fossil, la información sobre descendientes está reflejada en todo el sitio web
  • En todas las páginas de información de check-ins aparece un pequeño gráfico de "Context" que muestra los check-ins inmediatamente anteriores y posteriores
  • También ofrece funciones que ayudan a la conciencia situacional, como hacer clic para ir al siguiente check-in
• En Git, con extensiones, herramientas o comandos adecuados, esto sería posible en teoría, pero no es fácil y casi no se hace; como resultado, los desarrolladores terminan teniendo menos visibilidad sobre cómo cambia el código

El modelo mental de Git es innecesariamente complejo

• Quienes usan Git tienen que mantener siempre en mente estas 5 cosas
  1. El directorio de trabajo (working directory)
  2. El "index" o área de staging
  3. El head local
  4. La copia local del head remoto
  5. El head remoto real
• Quienes usan Fossil solo necesitan considerar el directorio de trabajo y el check-in sobre el que están trabajando, lo que implica 60% menos distracción
  • Esto ayuda a ahorrar los limitados ciclos mentales de la persona desarrolladora y a concentrarse más en el software que se está construyendo
• Un usuario que usa tanto Git como Fossil comentó en HN que "Fossil da la tranquilidad de saber, con un solo comando, que todo quedó sincronizado con el servidor, pero con git no tengo esa misma tranquilidad"

Git no rastrea los nombres históricos de las ramas

• Git conserva el DAG completo de la secuencia de check-ins, pero las etiquetas de rama son información local que no se sincroniza; además, cuando una rama se cierra, no se conserva, lo que vuelve engorroso revisar ramas antiguas
• Ejemplo: si alguien pregunta qué pasó con la rama prefer-coroutine-sort-subquery de hace 2 años
  • Fossil: muestra claramente que esa rama terminó fusionándose en trunk, dónde empezó y que los cambios de trunk se fusionaron en la rama en dos ocasiones
  • GitHub: no muestra nada de esa información y en la práctica resulta inútil para entender qué pasó
• Una GUI de terceros podría hacerlo mejor, pero sigue limitada por el hecho de que Git no preserva los nombres históricos de ramas al sincronizar
  • El solo hecho de necesitar una herramienta de terceros para obtener esa información ya evidencia una debilidad del sistema principal

Git exige más soporte administrativo

• Git es software complejo: instalarlo o actualizarlo en estaciones de trabajo requiere un instalador, y montar un servidor Git tampoco es tan sencillo
  • La mayoría usa servicios de terceros como GitHub o GitLab, lo que introduce dependencias adicionales
• Fossil es un único binario independiente que queda instalado con solo ponerlo en $PATH
  • Ese único binario incluye tanto las funciones centrales de Git como las de GitHub o GitLab
  • Permite administrar, sin software adicional, un servidor comunitario con wiki, seguimiento de bugs, foro, distribución de paquetes y gestión de login
  • Montar un servidor comunitario toma apenas unos minutos
  • Funciona sin problemas incluso en un VPS de $5/mes o una Raspberry Pi, mientras que GitLab y similares exigen más recursos
• Cuanto menor sea la carga administrativa, más tiempo pueden dedicar las personas desarrolladoras al software (SQLite) en lugar del sistema de control de versiones

Git ofrece una mala experiencia de usuario

• La historieta xkcd 1597 exagera, pero está bastante cerca de la realidad
• Hay poco desacuerdo en que Git ofrece una experiencia de usuario inferior a la ideal, y su implementación interna queda demasiado expuesta en la interfaz
  • Incluso existe un sitio de parodia que genera páginas man falsas de git, precisamente por lo mala que es su interfaz
• Un buen sistema de control de versiones debería apoyar, no frustrar; Git ha mejorado en los últimos 10 años, pero todavía le queda camino por recorrer

Guía para acceder al código fuente de SQLite si usas Git

Mirror oficial en GitHub

• Desde el 2019-03-20 existe un mirror oficial en Git del código fuente de SQLite en GitHub
• Es una exportación incremental del repositorio oficial de Fossil, y un trabajo cron actualiza el repositorio de GitHub una vez por hora
  • Es un mirror unidireccional y de solo lectura; no acepta pull requests ni cambios
  • Todos los cambios solo entran a través de Fossil
• Los hashes que identifican check-ins y archivos son distintos entre el mirror Git y Fossil
  • La razón principal es que Fossil usa hashes SHA3-256, mientras que Git usa SHA1
  • Al exportar, el hash original de Fossil se agrega como pie del comentario del check-in, y al referirse a check-ins de SQLite se recomienda usar siempre el hash original de Fossil para evitar confusiones

Acceso web

• El repositorio Fossil de SQLite ofrece enlaces de descarga para Tarball, ZIP Archive y SQLite Archive de cualquier versión anterior
• El formato de URL es simple, así que se puede integrar fácilmente en herramientas de automatización
  • Formato base: https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
  • En VERSION se puede usar un prefijo de hash, nombre de rama o tag (por ejemplo, version-3.23.1)
  • Para la versión más reciente se usa release, y para el trunk más reciente, trunk
  • Para ZIP o SQLite Archive, basta con cambiar /tarball/ por /zip/ o /sqlar/

Acceso con Fossil

• Fossil es fácil de instalar y usar; se indica el procedimiento para Unix (en Windows es similar)
  • Descarga el ejecutable de Fossil y colócalo en $PATH
  • Clona el repositorio con fossil clone y luego ábrelo con fossil open
  • Después puedes ejecutar ./configure; make (en Windows con MSVC, nmake /f Makefile.msc)
• Con el comando fossil update VERSION se puede cambiar el checkout a otra versión (VERSION puede ser trunk, un prefijo de hash, una rama o un tag)
• Dentro del checkout, el comando fossil ui levanta un sitio web local
  • Como no se pueden hacer push de cambios sin iniciar sesión, no hay riesgo de dañar el proyecto, así que se puede explorar y experimentar con libertad

Verificación de integridad del código fuente

• En la raíz del árbol de código fuente existe un archivo "manifest"
  • Ese archivo incluye todos los nombres de archivo y el hash SHA1 o SHA3-256 de cada uno (los archivos antiguos usan SHA1; los nuevos, SHA3-256)
  • Se pueden extraer esos hashes con un script y compararlos con los archivos fuente para verificar su integridad
• El nombre hash de un check-in es el hash SHA3-256 del propio archivo manifest, y si la última línea empieza con # Remove this line..., esa línea puede omitirse

[GN⁺]

Opiniones de Hacker News

• Hice una lista de las herramientas de control de versiones que usé durante décadas, con el año en que se crearon y el último año en que las usé: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~presente
  Al menos para mí, la vida útil de estas herramientas fue de unos 15 años
  Pero cuando les digo a los juniors: “cuando tengan mi edad, git será un recuerdo lejano y extraño”, me miran raro
  git es una gran herramienta y merecía tener éxito, pero sería una lástima si este problema terminara con git

  • Para ser justos, con cualquier tipo de herramienta, cuando el dominio del problema se entiende lo suficiente, la velocidad del cambio se desacelera
    Había un artículo en Joel on Software que decía que el software, en general, queda casi terminado alrededor de la versión 4, y el ejemplo era el software de oficina, especialmente Excel
    Si uno abre Excel 4 hoy, parece cierto en el sentido de que básicamente hace todas las funciones centrales
    Creo que git durará al menos el doble que las herramientas de control de versiones anteriores
  • Subversion es básicamente CVS bien hecho
    El problema es que CVS era un callejón sin salida que no podía escalar a un modelo de desarrollo distribuido
    Git volvió al modelo RCS local y le agregó commits atómicos, y así logró salir del óptimo local que era Subversion
    Hubo decisiones polémicas, como no rastrear renombrados o no tener números de revisión lineales, pero no terminaron siendo un gran problema, y permitió trabajar de forma muy eficiente sin los problemas de rendimiento de cosas como darcs
    Viendo la cantidad de intentos por arreglar el control de versiones entre 1995 y 2010, el modelo de datos básico de git parece muy difícil de mejorar, incluso incluyendo complementos como git-lfs
    Podrán aparecer nuevas interfaces de línea de comandos, pero desplazar al jugador dominante existente se volvió cada vez más difícil, y no conozco a nadie a mi alrededor que use git switch y git restore en lugar del sobrecargado y confuso git checkout
  • No sé qué estaremos usando dentro de 15 años, pero lo realmente triste de esa lista es que en 2015 dejé de usar mercurial y todavía sigo usando git
  • En mi primera empresa migramos un proyecto de clearcase a git, y hasta yo, que odiaba clearcase, creo que hasta entonces no había muchas razones para cambiarlo por otra cosa
    En otros departamentos de la empresa había algo de svn, pero nada más
    Los sistemas de control de versiones no cambian tan rápido
    Las herramientas de la lista previas a la aparición del control de versiones distribuido en realidad tienen mucho en común, y creo que git se va a quedar por bastante tiempo
  • Internet tiende a fijar las cosas
    Históricamente hubo varios idiomas dominantes, pero el inglés será el idioma final; hubo varios lenguajes de scripting, pero javascript será el lenguaje final; hubo varios protocolos de red, pero TCP/IP será el protocolo final
    Creo que con git pasa lo mismo
    Lo único que podría desplazar a git sería algo como glitch[1], donde un entorno para nuevos programadores trae su propio sistema de control de versiones
    [1]: https://medium.com/glitch/reinventing-version-control-with-g...

• Creo que git tiene mala fama porque nadie logra ponerse de acuerdo sobre cómo usarlo
  Basta ver los PR de GitHub y los push a ramas, rebase y merge: son herramientas que hacen esencialmente lo mismo de maneras completamente distintas
  El problema es que ninguna de las dos partes está equivocada
  Hacer rebase de commits pequeños reduce la complejidad innecesaria del historial, mientras que merge conserva lo que realmente ocurrió y ayuda a entender por qué se hicieron los cambios
  Claro que los merges inversos son lo peor, pero ese es otro dolor de cabeza
  Al pushear a una rama podés no hacer nunca force push, pero en una rama de PR terminás haciendo force push siempre
  Incluso las cosas fáciles crean grietas imposibles de cerrar
  Yo aprendí a llamar origin al repositorio principal y fork a mi fork, pero algunas personas aprenden a llamar upstream al repositorio principal y origin a su fork
  Ninguno de los dos enfoques es necesariamente incorrecto, pero si origin puede apuntar a dos lugares completamente distintos, comunicarse con claridad se vuelve muy difícil

  • Parafraseando a Bjarne Stroustrup, solo hay dos tipos de sistemas de control de versiones: aquellos de los que la gente se queja y aquellos que nadie usa
  • Una filosofía que me ayudó es: “hacé lo que corresponda para el objetivo inmediato de ahora, y después reevaluá y adaptate”
    En la práctica, dentro de un PR hago rebase de commits de forma activa centrándome solo en “¿qué hace que la revisión sea más fácil?”
    Cuando termina la revisión, pregunto “¿cuál es la forma más fácil de operar y entender esto en el futuro?”, y puedo hacer squash de todo o reestructurarlo en partes desplegables de manera independiente para facilitar el rollback
    La clave es que estas tareas pueden tener necesidades distintas, y está bien usar enfoques diferentes en cada momento
    Solo que requiere más criterio individual, y es difícil enseñarlo e imponerlo en todo un equipo grande
  • Es importante distinguir entre desacuerdos locales y desacuerdos sociales
    Los primeros son cosas que no afectan a otras personas
    Por ejemplo, a tus compañeros no les importa si nombrás los repositorios remotos como origin y upstream, o como fork y origin
    Los segundos son cosas que hay que coordinar con otras personas
    Por ejemplo, qué forma tendrá el historial final de git
  • git tiene mala fama porque su interfaz de línea de comandos es terriblemente desordenada
    Si Apple hubiera diseñado la interfaz de línea de comandos de git, la experiencia de usuario habría sido mil millones de veces mejor, y la potencia se habría reducido solo alrededor de un 10%

• Me alegra que Fossil les funcione bien, pero esta frase me hace ruido: “Fossil es un único binario ejecutable independiente que se instala con solo ponerlo en el $PATH, y ese único binario incluye tanto las funciones centrales de Git como las de GitHub/GitLab…”
  Aunque git tenga varios problemas, no es de esos que meten hasta el fregadero de la cocina
  Prefiero el enfoque de “hacer una sola cosa y hacerla bien”

  • En realidad, Git también agrupa muchas cosas que la gente no conoce
    Por ejemplo, si ejecutas git instaweb, levanta un servidor CGI local y un script CGI en Perl para ofrecer una UI web muy simple: https://git-scm.com/docs/git-instaweb
    En ese sentido, no es muy distinto de la funcionalidad central de Fossil
    Git también tiene muchas funciones de integración con clientes de correo que quienes solo usan GitHub probablemente ni siquiera saben que existen, ni por qué existen
    Cosas como git send-email, que permite enviar parches por correo directamente desde git: https://git-scm.com/docs/git-send-email
  • La idea de que se puede aislar “una cosa” y verla como si no fuera en sí misma “un conjunto de otras cosas” es un mito bastante dañino del mundo de la programación
    Todo es una composición, todo es una canalización de comandos y todo está hecho de varias cosas
    “Lo que hay que hacer” no es absoluto, sino que depende del punto de vista de quien lo mira
    El principio de responsabilidad única no se aplica tal cual a la realidad; no es más que un compromiso para mantener el equilibrio entre cohesión y modularidad
    Dónde cortar y llamar a algo “uno” depende de nosotros y de nuestras necesidades
    Para mucha gente, las herramientas de GitHub están tan integradas en su flujo de trabajo que Git por sí solo no les sirve en absoluto
    Para ellos, GitHub es “una cosa”, y SQLite tiene su propia “cosa”
  • SQLite es excelente y está claro que Richard es un genio, pero su obsesión con el monolito de un solo binario siempre me pareció extraña
    Como se dijo, va en contra de la filosofía Unix de hacer una cosa bien
    Para mí, es claramente más limpio dividir el sistema en componentes que luego puedan reemplazarse o modificarse de forma independiente
  • git, en su entorno *nix original, no mete hasta el fregadero de la cocina, pero Git para Windows sí lo hace
    El instalador pesa más de 50 MB y, si no recuerdo mal, incluso incluye una terminal
    En cambio, Fossil se puede descargar como un binario ejecutable independiente de 3.3 MB para cada plataforma compatible
  • Como git no agrupa esas cosas, se termina dependiendo de GitHub o GitLab para aportar las piezas faltantes que en la práctica necesita un sistema moderno de gestión de código fuente

• https://git-man-page-generator.lokaltog.net es lo más gracioso que he visto en mucho tiempo

  • La descripción de git-erase-working-tree dice “borra cuidadosamente el árbol de trabajo actual de la configuración y la raíz upstream, y debe usarse cuando quieras hacer quiltimport hacia la GUI activa”; suena útil
  • Que git-molest-head “acose incorrectamente el head upstream usando el índice remoto, y ejecute los hooks adecuados para tabular el head dado” suena un poco demasiado provocador
  • Me tomó demasiado tiempo darme cuenta de que esto no era real
    Git tiene comandos tan raros que ya ni sorprende
  • Mis comandos favoritos son git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon y git-pat-tree-object
  • No suena tan verosímil
    Para decir mejor tonterías le hace falta más sazón de LLM

• Discusiones anteriores:
  2021, 356 comentarios: https://news.ycombinator.com/item?id=29125934
  2018, 608 comentarios: https://news.ycombinator.com/item?id=16806114
  Seguro hay más, pero el mismo documento aparece por varias rutas, también sin el dominio www, sin la ruta /drafts/ y sin la ruta /matrix/, lo que hace más difícil encontrar publicaciones anteriores

• Aquí hay críticas legítimas a Git, pero algunas son un poco raras.
  He usado Git en todo tipo de situaciones, desde repositorios personales locales hasta repositorios corporativos muy grandes, y honestamente nunca me he topado con más o menos la mitad de estos problemas.
  También está eso de que “network tarda en renderizar, muestra mucha menos información detallada y casi no funciona en móvil”, y espero que nunca llegue el día en que mi equipo tenga que considerar dispositivos móviles como medio para revisar el estado de las ramas.
  Ni siquiera se me había ocurrido ese caso de uso.
  ¿A otras personas les pasa seguido?

  • Todo el tiempo.
    Diría que al menos el 50% de mi exploración de código la hago desde el teléfono.
    Uso mucho la interfaz web móvil de GitHub para eso, y el soporte para buscar referencias ha sido de enorme ayuda.
    La búsqueda todavía no es muy buena, y detesto que la torpeza típica de una SPA siga rompiendo la búsqueda básica dentro de la página.
    Cuando tengo que revisar el código de Firefox uso Searchfox [0], que es rápido y excelente, y casi no tengo quejas.
    Eso sí, blame en móvil podría mejorar.
    Para dar contexto: soy estudiante de posgrado, investigo lenguajes de programación y sistemas, y en mi tiempo libre también hago bastante hacking de IoT.
    Según dónde se trace la línea generacional, soy de los Gen Z mayores o de los Millennial más jóvenes posibles.
    [0] https://searchfox.org
  • Alguna vez intenté revisar proyectos en el tren camino al trabajo para alargar mi jornada laboral.
    Salvo por la cobertura de datos inestable, GitHub funcionaba bien y también era fácil hacer revisiones de código ligeras.
    GitHub pulse[1] es una buena UI para ver actividad reciente.
    El espejo de SQLite no trabaja en GitHub, así que solo tiene historial de commits y esta página está vacía, pero el proyecto Caddy enlazado es un mejor ejemplo.
    Personalmente me parece más útil que una línea de tiempo.
    Me pregunto si alguien ya hizo una vista equivalente para git/GitHub.
    No parece tan difícil.
    [1] https://github.com/caddyserver/caddy/pulse
  • Uso git para administrar mi blog.
    Hice un editor para Android para editar en GitHub, y después lo modifiqué para que también funcionara con GitLab.
    Hay muchas razones, pero la mayoría se reducen a que git, ya sea en GitHub o GitLab, es casi imposible de usar en móvil.
    Se puede revisar el estado, pero poco más que eso.
    Este artículo también me pegó fuerte en otros aspectos.
    Aunque escribí un libro de O’Reilly sobre GitHub, después de más de 10 años usando git todavía no siento que lo entienda por completo.
    Los señalamientos de aquí me resultan muy identificables.
  • No hay ninguna razón por la que esa función no deba funcionar en móvil.
    Si estuviera mejor diseñada e implementada, por supuesto que habría funcionado también en móvil.
    La gente entra a GitHub desde el móvil con frecuencia por las mismas razones por las que entra a GitHub desde otras plataformas.
    Yo sin duda lo he hecho.
    Estas observaciones sobre git no son necesariamente “problemas”, sino más bien juicios de valor sobre sus funciones.
    Uno puede estar de acuerdo o no, pero no son necesariamente el tipo de cosas con las que tengas que toparte.
  • Hay muchas formas de trabajar que no son óptimas, pero que vale la pena dejar como opción, y que esas opciones funcionen lo mejor posible es mejor que no tener ninguna opción.
    Creo que es la diferencia entre una degradación gradual del rendimiento y fallar de inmediato.
    Por muy buena que sea una opción impecable y de lujo, si es la única opción, es frágil y por eso termina siendo basura.

• Hace unos días vi un video que explicaba alternativas a Git, y Fossil, por supuesto, era una de ellas.
  He usado Fossil en algunos proyectos y me pareció bien.
  Pijul https://pijul.org/, explicado en esta presentación, me pareció muy interesante, y ya se ha discutido antes en HN.
  Fuente: https://www.youtube.com/watch?v=M4KktA_jbOE

  • Todavía estoy tratando de entenderlo, pero jj también es interesante: https://github.com/martinvonz/jj
  • Pijul siempre me pareció fascinante.
    Se siente como el santo grial del control de versiones.
    Pero en mis proyectos personales de todos modos desarrollo en línea recta, y en el trabajo no controlo qué se usa, así que nunca lo he usado en la práctica.
  • Pijul estará listo cuando admita envío de parches por correo electrónico como alternativa universal, para que quienes no quieran crear una cuenta en un servicio específico también puedan enviar parches a upstream.

• Probé Fossil en un proyecto local personal
  Es un sistema de control de versiones bastante competente y su UI web también es bastante buena
  Eso sí, hay que tener cuidado de hacer backups frecuentes de la base de datos SQLite del repositorio subyacente
  Después de actualizar Fossil y hacer algunos commits, por error hice un commit con una versión más antigua de Fossil, y la base de datos del repositorio Fossil se corrompió de forma irrecuperable; perdí varios días de trabajo
  En 10 años de uso diario, Git nunca me corrompió un repositorio por diferencias de versión

  • Como contraejemplo, yo he usado Fossil de manera totalmente abusiva
    Tengo versiones con años de diferencia entre sí desperdigadas en distintos sistemas, y simplemente sigo usando el binario que había cuando configuré cada sistema
    Hay macOS, varias variantes de Linux y una máquina con FreeBSD; si voy más atrás, creo que también hubo Windows
    Sincronizo entre ellos con soluciones improvisadas
    Algunos repositorios tienen más de 10 años; uno tiene más de 10 mil commits, y otro mide varios GB porque hice check-in de todo el entorno de desarrollo
    A veces me ha dicho que necesitaba reconstruirse, y cada vez lo logró
    Si detecto un typo durante un commit, por costumbre también lo interrumpo con ctrl-c
    Aun así, nunca me ha fallado
    Fossil es, por lejos, el programa más confiable que he usado
  • Me cuesta estar de acuerdo con esa afirmación
    El formato de artefactos subyacente de Fossil ha sido compatible desde el principio hasta hoy
    Ha habido mejoras, pero no cambios incompatibles, y tampoco ha habido reportes de ese tipo de roturas entre la gran cantidad de usuarios del Fossil Forum
    Si tuviera que adivinar, lo más probable es que hayas hecho check-in de algo con una versión más nueva de Fossil usando una funcionalidad mejorada, y luego hayas intentado extraerlo con una versión antigua de Fossil que no entendía esa nueva función, recibiendo un error
    Por ejemplo, al principio Fossil solo usaba hashes SHA1, pero después del ataque SHAttered se mejoró para admitir tanto SHA1 como SHA3
    Claro que es una suposición, pero parece la explicación más plausible
    Nunca he hecho un backup puro de los repositorios de SQLite, del repositorio autoalojado de Fossil ni de más de 100 repositorios Fossil que tengo a mano
    Para recuperación ante desastres, sí mantengo clones en otras máquinas
    De hecho, en varias máquinas alrededor del mundo hay tareas cron que ejecutan sync cada hora para repositorios Fossil importantes, como el de SQLite
    Pero nunca he hecho un backup puro
    Hace unos años, el repositorio principal de SQLite sí se corrompió una vez
    De algún modo se cerró el descriptor de archivo 2, y al abrir la base de datos SQLite que era el repositorio, se abrió usando el descriptor de archivo 2
    Luego, algún bug en Fossil provocó un assert(), que escribió en el descriptor de archivo 2 y sobrescribió parte de la base de datos
    Restauramos el repositorio desde un clon, corregimos la falla de assertion en Fossil y reforzamos SQLite para que no use descriptores de archivo menores que 3
    Material relacionado para ver: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
  • ¿Es un comportamiento conocido?
    Considerando el enfoque de confiabilidad de los desarrolladores de SQLite, parece algo que debería considerarse un bug crítico que hay que corregir
  • Sí se me ha corrompido un repositorio git
    Aunque normalmente no fue irrecuperable

• Vaya, esto me llevó a meterme a fondo
  Probablemente fue de lo mejor que he visto en mucho tiempo
  Parece que se puede usar Fossil y a la vez espejarlo en Git/GitHub: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
  La UI integrada se ve bien, parece usable de verdad y es fácil de explorar
  Eso sí, esperaba que la UI también permitiera hacer commits, pero no encontré esa opción
  Así no habría que mezclar la línea de comandos y la interfaz web para terminar el trabajo
  Si se pudiera crear una UI envoltorio sobre Fossil que soporte open, init, commit, sync, sync-with-git, start-web-interface, o incluso integrarla en el propio Fossil, creo que podría ser bastante útil para personas menos técnicas o que no son desarrolladoras pero trabajan con código, por ejemplo gente de biología, matemáticas o ciencia de datos que administra Jupyter notebooks y similares
  Claro que un cliente de UI simple para git también podría servir para eso, pero entonces se perderían la wiki y los tickets integrados
  La capacidad de trabajar localmente también es útil, aunque git también puede hacer eso
  En cualquier caso, he visto que personas menos técnicas rechazan git, o el control de versiones en general
  Se ve el potencial de tener wiki y tickets integrados en el mismo repositorio
  También es interesante que haya un solo archivo que respaldar

• Para un desarrollador de software, un sistema de control de versiones es una herramienta como el IDE o el sistema operativo base
  Cuanto menos tengas que trastear con este tipo de herramientas, más productivo eres
  Habiendo usado varios sistemas de control de versiones, Fossil para mí alcanza el sweet spot perfecto
  Literalmente lo configuras y te olvidas