Pourquoi SQLite n’utilise pas Git

 (sqlite.org)
2 points par GN⁺ 2023-07-24 | 1 commentaires | Partager sur WhatsApp
  • Le code source de SQLite est géré avec Fossil, et non Git ; Fossil est un système de gestion de versions spécialement conçu et écrit pour prendre en charge SQLite
  • Fossil offre une fonctionnalité de conscience de la situation (situational awareness) qui affiche sur un seul écran les changements récents de toutes les branches, et reste accessible même depuis un téléphone
  • Alors que Git ne suit que l’historique antérieur d’un check-in et rend difficile le suivi des descendants ultérieurs, Fossil affiche facilement les check-ins descendants et la structure des branches
  • Avec Git, il faut garder en tête 5 états — répertoire de travail, staging, head local/distant, etc. — tandis qu’avec Fossil il suffit de considérer le répertoire de travail et le check-in, soit 60 % de charge en moins
  • Même les utilisateurs habitués à Git peuvent accéder de la même manière au code source de SQLite via le miroir GitHub, les téléchargements Web ou l’installation de Fossil

Présentation et prémisses du texte

  • SQLite utilise Fossil plutôt que Git, et Fossil est un système de gestion de versions créé directement dans le but de prendre en charge SQLite
  • Ce texte n’est pas une comparaison entre Fossil et Git, et n’incite pas non plus à abandonner Git
    • Si Git vous convient, vous pouvez tout à fait continuer à l’utiliser
    • Si Git ne vous convient pas, ou si vous réfléchissez à des améliorations ou à des alternatives, il propose un point de vue utile
  • Ce document a été révisé à plusieurs reprises afin d’améliorer sa clarté et de corriger des erreurs, et l’historique complet des modifications est consultable

Les raisons pour lesquelles SQLite n’utilise pas Git

Git n’offre pas une bonne conscience de la situation

  • La timeline de Fossil fournit, sur un seul écran, un résumé des changements récents de toutes les branches ; quelques clics suffisent pour consulter les détails, et elle est utilisable même sur téléphone
  • GitHub et GitLab n’ont pas de fonctionnalité comparable
    • La vue network est lente à rendre (avant mise en cache), fournit peu de détails et fonctionne à peine sur mobile
    • La vue commits est rapide et fonctionne sur mobile, mais n’affiche qu’une seule branche à la fois, ce qui rend difficile de savoir si l’on a bien vu tous les changements
    • GitHub et GitLab sont des services tiers, et non des composants centraux de Git, ce qui crée une dépendance supplémentaire
  • Les utilisateurs de Git installent souvent des visualiseurs graphiques tiers, mais ceux-ci doivent être installés et maintenus séparément, et dépendent de la plateforme
    • GitUp, l’un des bons outils disponibles, ne fonctionne que sur Mac
    • Tous ces outils exigent de synchroniser un dépôt local puis de lancer une interface graphique de bureau ; il est impossible de vérifier l’état du projet depuis l’extérieur avec un téléphone

Git rend difficile la recherche des check-ins descendants

  • Git permet de regarder vers le passé, mais il est difficile de suivre ce qui s’est passé ensuite
    • Pour un check-in ancien donné, l’historique antérieur est visible, mais il est délicat de déterminer ce qui est arrivé après
  • Fossil fournit un écran qui affiche tous les check-ins dérivés de la dernière version majeure
  • Trouver les descendants n’est pas impossible avec Git, mais c’est difficile
    • Une séquence de commandes pour Unix existe sur stackoverflow, mais cette commande n’affiche qu’une liste de descendants, sans structure de branches
    • Cette commande ne fonctionne que si l’on dispose d’un clone local ; il est impossible de consulter les descendants via une interface Web comme GitHub ou GitLab
  • Avec Fossil, les informations sur les descendants sont intégrées dans l’ensemble des pages Web
    • Chaque page d’information d’un check-in affiche un petit graphe « Context » montrant les check-ins immédiatement précédent et suivant
    • Des fonctionnalités comme le clic vers le check-in suivant aident à conserver la conscience de la situation
  • Avec Git, cela serait théoriquement possible au moyen d’extensions, d’outils ou de commandes adaptés, mais ce n’est pas facile et cela se fait donc rarement ; au final, les développeurs perçoivent moins bien l’évolution du code

Le modèle mental de Git est inutilement complexe

  • Les utilisateurs de Git doivent toujours garder en tête les 5 éléments suivants
    1. Le répertoire de travail (working directory)
    2. L’« index » ou zone de staging
    3. Le head local
    4. La copie locale du head distant
    5. Le véritable head distant
  • Les utilisateurs de Fossil n’ont à considérer que le répertoire de travail et le check-in en cours, soit 60 % de dispersion de l’attention en moins
    • Cela économise la capacité de concentration limitée des développeurs (brain-cycles) et les aide à se concentrer sur le logiciel qu’ils développent
  • Un utilisateur de HN qui utilise à la fois Git et Fossil a indiqué que « Fossil donne, avec une seule commande, l’assurance que tout a été synchronisé avec le serveur, alors que je n’obtiens pas cette assurance avec git »

Git ne suit pas les anciens noms de branches

  • Git conserve le DAG complet de la séquence de check-ins, mais les tags de branche sont des informations locales qui ne sont pas synchronisées ; lorsqu’une branche est fermée, ils ne sont pas conservés, ce qui complique l’examen des branches passées
  • Exemple : si l’on demande ce qu’est devenue la branche « prefer-coroutine-sort-subquery » d’il y a deux ans
    • Fossil : indique clairement que cette branche a finalement été fusionnée dans trunk, son point de départ, ainsi que les indices montrant que des changements de trunk ont été fusionnés deux fois dans la branche
    • GitHub : ne montre aucune de ces informations et s’avère en pratique inutile pour comprendre ce qui s’est passé
  • Les interfaces graphiques tierces peuvent faire mieux, mais elles restent limitées par le fait que Git ne préserve pas les anciens noms de branches lors de la synchronisation
    • Le simple fait d’avoir besoin d’un outil tiers pour obtenir l’information souhaitée constitue en soi une faiblesse du système central

Git demande davantage de support d’administration

  • Git est un logiciel complexe : son installation et ses mises à niveau sur les postes de travail nécessitent un installeur, et mettre en place un serveur Git n’est pas simple non plus
    • La plupart des gens utilisent des services tiers comme GitHub ou GitLab, ce qui crée une dépendance supplémentaire
  • Fossil est un unique binaire autonome dont l’installation est terminée dès qu’il est placé dans le $PATH
    • Ce seul binaire inclut à la fois les fonctionnalités du cœur de Git et celles de GitHub ou GitLab
    • Il permet, sans logiciel supplémentaire, d’administrer un serveur communautaire avec wiki, suivi de bugs et forum, de proposer des téléchargements de paquets, de gérer les connexions, etc.
    • La mise en place d’un serveur communautaire prend quelques minutes
    • Il fonctionne correctement même sur un VPS à 5 $/mois ou un Raspberry Pi, tandis que GitLab et d’autres solutions demandent davantage de ressources
  • Moins la charge d’administration est importante, plus les développeurs peuvent consacrer de temps au logiciel (SQLite) plutôt qu’au système de gestion de versions

Git offre une mauvaise expérience utilisateur

  • La BD xkcd 1597 est exagérée, mais proche de la réalité
  • Il y a peu de désaccord sur le fait que Git offre une expérience utilisateur sous-optimale, et que son implémentation interne transparaît telle quelle dans son interface
    • L’interface est suffisamment mauvaise pour qu’il existe un site parodique générant de fausses pages de man git
  • Un bon système de gestion de versions devrait apporter du soutien plutôt que de la frustration ; Git s’est amélioré au cours des dix dernières années, mais il lui reste encore beaucoup de chemin à parcourir

Guide d’accès au code source de SQLite pour les utilisateurs de Git

Miroir GitHub officiel

  • Depuis le 2019-03-20, il existe sur GitHub un miroir Git officiel du code source de SQLite
  • Il s’agit d’un export incrémental du dépôt Fossil officiel ; une tâche cron met à jour le dépôt GitHub une fois par heure
    • C’est un miroir unidirectionnel et en lecture seule : les pull requests et les modifications ne sont pas acceptées
    • Toutes les modifications sont saisies uniquement via Fossil
  • Les hashs d’identification des check-ins et des fichiers diffèrent entre le miroir Git et Fossil
    • La raison principale est que Fossil utilise des hashs SHA3-256, tandis que Git utilise SHA1
    • Lors de l’export, le hash Fossil d’origine est ajouté en pied de commentaire du check-in ; pour éviter toute confusion dans les références aux check-ins de SQLite, il est recommandé d’utiliser toujours le hash Fossil d’origine

Accès Web

  • Le dépôt Fossil de SQLite fournit des liens de téléchargement Tarball, ZIP Archive et SQLite Archive pour n’importe quelle version passée
  • Le format des URL est simple, ce qui facilite l’intégration dans des outils d’automatisation
    • Format de base : https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
    • VERSION peut être un préfixe de hash, un nom de branche ou un tag (par exemple « version-3.23.1 »)
    • Utilisez « release » pour la dernière version publiée, et « trunk » pour le dernier trunk
    • Pour ZIP ou SQLite Archive, remplacez « /tarball/ » par « /zip/ » ou « /sqlar/ »

Accès avec Fossil

  • Fossil est facile à installer et à utiliser ; la procédure est fournie pour Unix (Windows est similaire)
    • Téléchargez l’exécutable fossil puis placez-le dans le $PATH
    • Clonez le dépôt avec fossil clone, puis ouvrez-le avec fossil open
    • Vous pouvez ensuite exécuter ./configure; make (avec MSVC sous Windows : nmake /f Makefile.msc)
  • La commande fossil update VERSION permet de basculer le checkout vers une autre version (VERSION peut être trunk, un préfixe de hash, une branche ou un tag)
  • Dans un checkout, la commande fossil ui lance un site Web local
    • Sans connexion, vous ne pouvez pas pousser de changements, donc vous ne risquez pas d’endommager le projet et pouvez explorer et expérimenter librement

Vérification de l’intégrité du code source

  • Un fichier « manifest » se trouve à la racine de l’arborescence source
    • Ce fichier contient tous les noms de fichiers ainsi que le hash SHA1 ou SHA3-256 de chaque fichier (SHA1 pour les anciens fichiers, SHA3-256 pour les nouveaux)
    • Un script peut extraire les hashs et les comparer aux fichiers sources pour vérification
  • Le nom de hash d’un check-in est le hash SHA3-256 du fichier « manifest » lui-même ; si la dernière ligne commence par « # Remove this line... », cette ligne peut être omise

À lire aussi

1 commentaires

 
GN⁺ 2023-07-24
Commentaires sur Hacker News

  • J’ai essayé de récapituler les outils de gestion de versions que j’ai utilisés au fil des décennies, avec leur année de création et la dernière année où je m’en suis servi : sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~aujourd’hui
    Pour moi au moins, la durée de vie de ces outils a tourné autour de 15 ans
    Pourtant, quand je dis à des juniors : « quand vous aurez mon âge, git sera un souvenir lointain et étrange », ils me regardent bizarrement
    git est un excellent outil et il méritait son succès, mais je trouverais ça dommage que ce problème se termine avec git

    • Pour être juste, pour n’importe quel type d’outil, une fois que le domaine du problème est suffisamment bien compris, la vitesse du changement ralentit
      Il y avait sur Joel on Software un article disant qu’un logiciel est en général quasiment achevé au bout d’environ 4 versions, avec comme exemple les logiciels bureautiques, en particulier Excel
      Ça me paraît juste, dans le sens où si on lance Excel 4 aujourd’hui, les fonctions essentielles sont fondamentalement déjà là
      git me semble parti pour durer au moins deux fois plus longtemps que les outils de gestion de versions précédents
    • Subversion, c’était fondamentalement CVS bien fait
      Le problème, c’est que CVS était une impasse incapable d’évoluer vers un modèle de développement distribué
      Git est revenu au modèle RCS local en y ajoutant les commits atomiques, ce qui lui a permis de sortir de l’optimum local qu’était Subversion
      Il y a eu des choix controversés, comme le fait de ne pas suivre les renommages ou l’absence de numéros de révision linéaires, mais ça n’a pas posé de gros problème, et ça a permis un travail très efficace sans les soucis de performances de darcs
      Quand on voit le nombre de tentatives entre 1995 et 2010 pour corriger la gestion de versions, le modèle de données de base de git semble très difficile à améliorer, même avec des ajouts comme git-lfs
      De nouvelles interfaces en ligne de commande peuvent apparaître, mais il est devenu de plus en plus difficile de détrôner l’acteur en place, et je ne connais personne autour de moi qui utilise git switch et git restore au lieu du surchargé et déroutant git checkout
    • Je ne sais pas ce qu’on utilisera dans 15 ans, mais ce qu’il y a de vraiment triste dans cette liste, c’est qu’en 2015 j’ai arrêté d’utiliser mercurial alors que j’utilise encore git
    • Dans ma première entreprise, on a migré un projet de clearcase vers git, et même moi qui détestais clearcase, je pense qu’avant ça il n’y avait pas vraiment de raison impérieuse de changer
      Il y avait bien un peu de svn dans d’autres équipes de l’entreprise, mais pas plus que ça
      Les systèmes de gestion de versions ne changent pas si vite
      Les outils listés avant l’arrivée du versioning distribué avaient en réalité beaucoup de points communs, et git me semble bien parti pour rester longtemps
    • Internet a tendance à figer les choses
      Historiquement, plusieurs langues ont dominé, mais l’anglais sera la langue finale ; il y a eu plusieurs langages de script, mais javascript sera le langage final ; il y a eu plusieurs protocoles réseau, mais TCP/IP sera le protocole final
      Je pense que git, c’est pareil
      Ce qui pourrait éventuellement détrôner git, ce serait plutôt un environnement pour nouveaux programmeurs comme glitch[1], avec son propre système de gestion de versions intégré
      [1]: https://medium.com/glitch/reinventing-version-control-with-g...

  • Je pense que si git a mauvaise réputation, c’est parce que personne n’arrive à se mettre d’accord sur la manière de l’utiliser
    Rien qu’avec les PR GitHub et les pushs sur branche, ou rebase et merge, on a des outils qui accomplissent fondamentalement la même chose de façons complètement différentes
    Le problème, c’est qu’aucune des deux approches n’est réellement fausse
    Rebase sur de petits commits réduit la complexité inutile de l’historique, tandis que merge conserve ce qui s’est réellement passé et aide à comprendre pourquoi un changement a eu lieu
    Bien sûr, les merges en sens inverse sont les pires, mais c’est encore un autre casse-tête
    Quand on push sur une branche, on peut ne jamais faire de force push, alors que sur une branche de PR on finit toujours par en faire
    Même les choses simples créent des fractures impossibles à résoudre
    Moi, on m’a appris à appeler le dépôt principal origin et mon fork fork, mais certaines personnes apprennent à appeler le dépôt principal upstream et leur fork origin
    Les deux ne sont pas forcément faux, mais si origin peut désigner deux emplacements totalement différents, il devient très difficile de communiquer clairement

    • Pour paraphraser Bjarne Stroustrup, il n’existe que deux types de systèmes de gestion de versions : ceux dont les gens se plaignent et ceux que personne n’utilise
    • Une philosophie qui m’a aidé, c’est : « fais ce qui convient à l’objectif direct du moment, puis réévalue et adapte »
      En pratique, je rebase activement les commits d’une PR en me concentrant uniquement sur la question : « qu’est-ce qui rendra la revue la plus facile ? »
      Une fois la revue terminée, je me demande : « quelle forme sera la plus simple à exploiter et à comprendre par la suite ? », et je peux tout squash, ou bien restructurer en morceaux déployables indépendamment pour faciliter un rollback
      L’idée clé, c’est que ces tâches peuvent répondre à des besoins différents, et qu’il est acceptable d’utiliser des approches différentes selon le moment
      En contrepartie, cela demande davantage de jugement individuel, et c’est plus difficile à enseigner et à faire appliquer à toute une grande équipe
    • Il est important de distinguer les désaccords locaux des désaccords sociaux
      Les premiers sont des choses qui n’affectent pas les autres
      Par exemple, que vous appeliez les dépôts distants origin et upstream, ou fork et origin, vos collègues s’en moqueront
      Les seconds sont des choses qui doivent être coordonnées avec les autres
      Par exemple, la question de la forme finale qu’on veut laisser à l’historique git
    • Si git a mauvaise réputation, c’est parce que son interface en ligne de commande est affreusement brouillonne
      Si Apple avait conçu l’interface en ligne de commande de git, elle serait un milliard de fois meilleure du point de vue de l’expérience utilisateur, avec seulement 10 % de puissance en moins

  • Tant mieux si Fossil leur convient, mais cette phrase me gêne : « Fossil est un binaire autonome unique qui s’installe simplement en le plaçant dans le $PATH, et ce seul fichier inclut à la fois les fonctionnalités essentielles de Git et celles de GitHub/GitLab… »
    Git a beau avoir plusieurs problèmes, ce n’est pas une approche du genre on fourre même l’évier de cuisine dedans
    Je préfère l’approche consistant à « faire une seule chose et la faire bien »

    • En réalité, Git embarque aussi beaucoup de choses que les gens connaissent mal
      Par exemple, si vous lancez git instaweb, il démarre un serveur CGI local et des scripts CGI Perl pour fournir une interface web très simple : https://git-scm.com/docs/git-instaweb
      De ce point de vue, ce n’est pas si différent des fonctionnalités de base de Fossil
      Git propose aussi beaucoup de fonctions d’intégration avec les clients e-mail dont les gens qui n’utilisent que GitHub ignorent probablement jusqu’à l’existence, et encore plus l’utilité
      Par exemple git send-email, qui permet d’envoyer directement des patchs par e-mail depuis Git : https://git-scm.com/docs/git-send-email
    • L’idée qu’on puisse isoler « une seule chose » et considérer qu’elle n’est pas elle-même « un ensemble d’autres choses » est un mythe assez néfaste dans le monde de la programmation
      Tout est composite, tout est pipeline de commandes, tout est fait de plusieurs éléments
      Ce qu’il « faut faire » n’est jamais absolu, cela dépend du point de vue de celui qui regarde
      Le principe de responsabilité unique ne s’applique pas tel quel au réel ; ce n’est qu’un compromis pour maintenir un équilibre entre cohésion et modularité
      L’endroit où l’on coupe pour appeler quelque chose « un » dépend de nous et de nos besoins
      Pour beaucoup de gens, les outils GitHub sont tellement intégrés à leur flux de travail que Git seul leur est totalement inutilisable
      Pour eux, GitHub est « la seule chose », tout comme SQLite a sa propre « seule chose »
    • SQLite est excellent, et Richard est clairement un génie, mais son attachement au monolithe binaire unique m’a toujours semblé étrange
      Comme cela a été dit, cela va à l’encontre de la philosophie Unix consistant à bien faire une seule chose
      Pour moi, il est clairement plus propre de découper un système en composants qu’on pourra remplacer ou modifier indépendamment plus tard
    • Git, dans son environnement *nix d’origine, ne fourre pas tout jusqu’à l’évier de cuisine, mais Git for Windows, lui, le fait
      L’installateur fait plus de 50 Mo et, si je me souviens bien, inclut même un terminal
      À l’inverse, Fossil permet de télécharger un binaire autonome de 3,3 Mo pour chaque plateforme prise en charge
    • Justement parce que Git n’embarque pas ces éléments, on finit par dépendre de GitHub ou GitLab, qui fournissent les pièces manquantes réellement nécessaires à un système moderne de gestion de code source

  • https://git-man-page-generator.lokaltog.net est la chose la plus drôle que j’aie vue depuis longtemps

    • La description de git-erase-working-tree — « efface soigneusement l’arbre de travail courant et la configuration de la racine amont, pour l’importer via quiltimport dans l’interface graphique active » — a l’air utile
    • git-molest-head, décrit comme « malmener de façon incorrecte la tête amont à l’aide de l’index distant et exécuter les hooks appropriés pour tabulariser la tête donnée », est un peu trop provocant
    • J’ai mis bien trop longtemps à comprendre que ce n’était pas réel
      Git a des commandes suffisamment étranges pour que ça ne me surprenne même plus
    • Mes commandes préférées sont git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon et git-pat-tree-object
    • Ça ne sonne pas très crédible
      Pour mieux dire des absurdités, il lui faudrait un peu plus d’assaisonnement LLM

  • Discussions précédentes :
    2021, 356 commentaires : https://news.ycombinator.com/item?id=29125934
    2018, 608 commentaires : https://news.ycombinator.com/item?id=16806114
    Il y en a probablement d’autres, mais comme ce même document peut être trouvé via plusieurs chemins — avec ou sans domaine www, avec ou sans chemin /drafts/, avec ou sans chemin /matrix/ — il est plus difficile de retrouver les publications précédentes

  • Il y a là des critiques légitimes de Git, mais certaines me paraissent assez étranges.
    J’ai utilisé Git dans des contextes très variés, du dépôt local personnel aux très gros dépôts d’entreprise, et honnêtement je n’ai jamais rencontré environ la moitié de ces problèmes.
    C’est aussi le cas du passage disant que « network est lent à afficher, donne beaucoup moins de détails et ne fonctionne presque pas sur mobile », et j’espère ne jamais voir arriver le jour où notre équipe devra considérer les appareils mobiles comme un moyen de vérifier l’état des branches.
    Je n’ai même jamais envisagé un tel cas d’usage.
    Est-ce que cela arrive souvent à d’autres ?

    • Tout le temps.
      J’ai l’impression qu’au moins 50 % de mon exploration de code se fait sur téléphone.
      J’utilise beaucoup l’interface web mobile de GitHub pour ça, et l’aide à la recherche de références a été vraiment précieuse.
      La recherche reste médiocre, et je déteste le fait que les saccades typiques des SPA cassent sans arrêt la recherche intégrée dans la page.
      Quand je dois fouiller dans le code de Firefox, j’utilise Searchfox [0] ; c’est rapide, excellent, et j’ai très peu de reproches à lui faire.
      Cela dit, le blame sur mobile pourrait être meilleur.
      Pour ajouter un peu de contexte, je suis doctorant, je fais de la recherche en langages de programmation et en systèmes, et je fais aussi pas mal de bidouillage IoT sur mon temps libre.
      Selon l’endroit où l’on place la frontière entre les générations, je suis soit un Gen Z âgé, soit le plus jeune des Millennial possible.
      [0] https://searchfox.org
    • Il m’est déjà arrivé de consulter des projets dans le train du trajet domicile-travail pour essayer de prolonger mes heures de travail.
      Mis à part la couverture réseau instable, GitHub fonctionnait bien et permettait même de faire facilement de petites revues de code.
      GitHub pulse[1] offre une bonne interface pour voir l’activité récente.
      Le miroir SQLite n’étant pas travaillé sur GitHub, cette page est vide à part l’historique des commits, mais le projet Caddy lié donne un meilleur exemple.
      Personnellement, cela me paraît plus utile qu’une timeline.
      Je me demande si quelqu’un a déjà créé une vue équivalente pour git/GitHub.
      Cela ne semble pas très difficile.
      [1] https://github.com/caddyserver/caddy/pulse
    • J’utilise git pour gérer mon blog.
      J’ai créé un éditeur Android pour modifier depuis GitHub, puis je l’ai adapté pour qu’il fonctionne aussi avec GitLab.
      Il y a de nombreuses raisons à cela, mais la principale est que git, que ce soit sur GitHub ou GitLab, est presque impossible à utiliser sur mobile.
      On peut vérifier l’état, mais faire davantage est presque toujours difficile.
      Cet article m’a aussi beaucoup parlé sur d’autres aspects.
      Bien que j’aie écrit un livre O’Reilly sur GitHub, après plus de 10 ans d’utilisation de git, j’ai toujours l’impression de ne pas le comprendre complètement.
      Je me reconnais dans les remarques faites ici.
    • Il n’y a aucune raison que cette fonctionnalité ne marche pas sur mobile.
      Si elle avait été mieux conçue et mieux implémentée, elle fonctionnerait évidemment aussi sur mobile.
      Les gens consultent souvent GitHub sur mobile pour les mêmes raisons qu’ils y accèdent depuis d’autres plateformes.
      Je l’ai clairement déjà fait moi aussi.
      Ce genre d’observations sur git relève moins de « problèmes » que de jugements de valeur sur les fonctionnalités.
      On peut être d’accord ou non, sans que ce soit forcément le genre de chose qu’il faille absolument rencontrer.
    • Ce n’est pas optimal, mais beaucoup de solutions ont de la valeur dès lors qu’elles restent disponibles comme option, et il vaut mieux qu’une telle option fonctionne aussi bien que possible plutôt qu’elle n’existe pas du tout.
      Cela ressemble à la différence entre une dégradation progressive des performances et un échec immédiat.
      Même si une option premium bien dorée est formidable, si c’est la seule disponible, elle est fragile et donc nulle.

  • Il y a quelques jours, j’ai vu une vidéo présentant des alternatives à Git, et Fossil en faisait naturellement partie.
    J’ai utilisé Fossil sur quelques projets et je l’ai trouvé correct.
    Pijul https://pijul.org/ présenté dans cette intervention m’a paru très intéressant, et il avait déjà été discuté sur HN auparavant.
    Source : https://www.youtube.com/watch?v=M4KktA_jbOE

    • J’essaie encore de le comprendre, mais jj est aussi intéressant : https://github.com/martinvonz/jj
    • Pijul a toujours été fascinant.
      Cela donne l’impression du Saint Graal du contrôle de version.
      Mais sur mes projets personnels, je développe de toute façon de manière linéaire, et au travail je ne contrôle pas ce qu’on utilise, donc je ne l’ai jamais réellement employé.
    • On pourra considérer que Pijul est prêt quand il prendra en charge l’envoi de patchs par e-mail comme solution de rechange générique, afin que les personnes qui ne veulent pas créer de compte de service spécifique puissent quand même soumettre des patchs en amont.

  • J’ai utilisé Fossil pour un projet local personnel
    C’est un système de gestion de versions tout à fait capable, et son interface web est aussi plutôt bonne
    Cela dit, il faut veiller à sauvegarder souvent la base de données de dépôt SQLite sous-jacente
    Après avoir mis à niveau Fossil, fait quelques commits, puis committé par erreur avec une version plus ancienne de Fossil, la base de données du dépôt Fossil s’est retrouvée corrompue de manière irrécupérable, et j’ai perdu plusieurs jours de travail
    En 10 ans d’usage quotidien, Git n’a jamais corrompu un dépôt, quelle que soit la version utilisée

    • À titre de contre-exemple, j’ai utilisé Fossil de manière complètement déraisonnable
      J’ai sur différents systèmes des versions espacées de plusieurs années qui traînent un peu n’importe comment, et quand je configure un système, je continue simplement à utiliser le binaire déjà présent
      Il y a du macOS, plusieurs variantes de Linux, des machines FreeBSD, et si je remonte plus loin, je crois qu’il y a aussi eu Windows
      Je synchronise tout cela entre eux de façon bricolée
      Certains dépôts ont plus de 10 ans, l’un d’eux dépasse les 10 000 commits, et un autre fait plusieurs Go parce que j’y ai versionné tout l’environnement de développement
      Il m’est arrivé de dire qu’un rebuild était nécessaire, et ça a réussi à chaque fois
      Quand je repère une faute de frappe pendant un commit, j’ai même l’habitude d’interrompre avec ctrl-c
      Et malgré tout, ça ne m’a jamais laissé tomber
      Fossil est de très loin le programme le plus fiable que j’aie jamais utilisé
    • J’ai du mal à être d’accord avec cette affirmation
      Le format d’artefact sous-jacent de Fossil est resté compatible du début jusqu’à aujourd’hui
      Il y a eu des améliorations, mais aucun changement cassant, et aucun rapport de ce type de corruption n’a été signalé parmi les nombreux utilisateurs du Fossil Forum
      Mon hypothèse est qu’après avoir versionné quelque chose avec une fonctionnalité améliorée dans une version plus récente de Fossil, vous avez essayé de l’extraire avec une ancienne version de Fossil qui ne comprenait pas cette nouvelle fonctionnalité, et vous avez obtenu une erreur
      Par exemple, Fossil n’utilisait au départ que des hachages SHA1, mais après l’attaque SHAttered, il a été amélioré pour prendre en charge à la fois SHA1 et SHA3
      Bien sûr, ce n’est qu’une supposition, mais c’est ce qui me paraît le plus plausible
      Je n’ai jamais fait une seule sauvegarde pure de mes dépôts SQLite, du dépôt d’auto-hébergement de Fossil lui-même, ni de la centaine de dépôts Fossil ou plus que j’ai sous la main
      En revanche, je garde des clones sur d’autres machines pour la reprise après sinistre
      En réalité, des tâches cron exécutées sur plusieurs machines à travers le monde font un sync toutes les heures pour des dépôts Fossil importants comme SQLite
      Mais je n’ai jamais fait de sauvegarde pure
      Il y a quelques années, le dépôt SQLite principal a bien été corrompu une fois
      Le descripteur de fichier 2 s’était retrouvé fermé par hasard, et la base de données SQLite du dépôt a été ouverte en utilisant ce descripteur
      Ensuite, un bug de Fossil a déclenché un assert(), qui a écrit sur le descripteur de fichier 2 et écrasé une partie de la base de données
      Nous avons restauré le dépôt à partir d’un clone, corrigé le défaut d’assertion de Fossil, et renforcé SQLite pour qu’il n’utilise pas de descripteurs de fichier inférieurs à 3
      À voir aussi : https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
    • Est-ce un comportement connu ?
      Vu l’approche de la fiabilité des développeurs de SQLite, j’aurais tendance à penser qu’il faut considérer cela comme un bug critique à corriger
    • Il m’est déjà arrivé d’avoir un dépôt git corrompu
      En général, ce n’était simplement pas irrécupérable

  • Waouh, ça m’a complètement happé
    C’était probablement l’une des meilleures choses que j’aie lues depuis longtemps
    On dirait qu’on peut utiliser Fossil tout en faisant aussi un miroir vers Git/GitHub : https://fossil-scm.org/home/doc/trunk/www/inout.wiki
    L’interface intégrée a l’air correcte, réellement utilisable et facile à parcourir
    En revanche, j’espérais qu’elle permette aussi de faire des commits depuis l’UI, mais je n’ai pas trouvé
    Ce serait utile pour ne pas avoir à mélanger ligne de commande et interface web juste pour terminer son travail
    S’il était possible de créer au-dessus de Fossil une interface wrapper qui prenne en charge open, init, commit, sync, sync-with-git, start-web-interface, ou de l’intégrer directement à Fossil, cela pourrait être assez utile pour des personnes moins techniques ou non développeuses qui manipulent quand même du code, par exemple en biologie, en mathématiques ou en data science, afin de gérer des notebooks Jupyter, etc.
    Bien sûr, un simple client UI pour git pourrait aussi servir à cela, mais on perdrait alors le wiki intégré et le système de tickets
    La possibilité de travailler en local est également utile, mais git le permet aussi
    Quoi qu’il en soit, j’ai déjà vu des personnes moins techniques être rebutées par git, ou même par le versioning en général
    Je vois bien le potentiel d’avoir un wiki et un système de tickets intégrés dans le même dépôt
    Le fait qu’il n’y ait qu’un seul fichier à sauvegarder est aussi intéressant

  • Pour un développeur logiciel, un système de gestion de versions est un outil au même titre que l’IDE ou le système d’exploitation de base
    Moins on bidouille ce genre d’outils, plus on est productif
    Ayant utilisé plusieurs systèmes de gestion de versions, Fossil atteint pour moi le sweet spot parfait
    En pratique, on le configure puis on l’oublie