Warum SQLite nicht Git verwendet
(sqlite.org)- Der Quellcode von SQLite wird nicht mit Git, sondern mit Fossil verwaltet, einem Versionsverwaltungssystem, das eigens zur Unterstützung von SQLite entworfen und entwickelt wurde
- Fossil bietet mit Situational Awareness eine Funktion, die die jüngsten Änderungen aller Branches auf einem einzigen Bildschirm zeigt und auch auf dem Smartphone zugänglich ist
- Git verfolgt bei Check-ins nur die vorherige Historie, während sich nachfolgende Descendants nur schwer nachverfolgen lassen; Fossil zeigt dagegen nachfolgende Check-ins und die Branch-Struktur leicht verständlich an
- Bei Git muss man fünf Zustände im Kopf behalten – Working Directory, Staging, lokaler/entfernter Head usw. –, während bei Fossil nur Working Directory und Check-in relevant sind, also 60 % weniger mentale Last
- Auch Nutzer, die an Git gewöhnt sind, können über den GitHub-Mirror, Web-Downloads oder eine Fossil-Installation auf denselben SQLite-Quellcode zugreifen
Überblick und Voraussetzungen des Artikels
- SQLite verwendet statt Git Fossil, und Fossil ist ein eigens entwickeltes Versionsverwaltungssystem mit dem Ziel, SQLite zu unterstützen
- Dieser Text ist kein genereller Vergleich zwischen Fossil und Git und empfiehlt auch nicht, Git nicht mehr zu verwenden
- Wer mit Git zufrieden ist, kann es selbstverständlich weiter nutzen
- Wer mit Git nicht gut zurechtkommt oder über Verbesserungen bzw. Alternativen nachdenkt, findet hier mögliche Perspektiven
- Dieses Dokument wurde mehrfach überarbeitet, um die Verständlichkeit zu verbessern und Fehler zu korrigieren; die vollständige Bearbeitungshistorie ist einsehbar
Warum SQLite nicht Git verwendet
Git bietet keine gute Situational Awareness
- Die Timeline von Fossil liefert auf einem einzigen Bildschirm eine Zusammenfassung der jüngsten Änderungen über alle Branches hinweg; mit wenigen Klicks lassen sich Details prüfen, und das Ganze funktioniert auch auf dem Smartphone
- In GitHub und GitLab gibt es nichts wirklich Vergleichbares
- Die Network-Ansicht rendert langsam (vor dem Caching), bietet wenig Details und funktioniert auf Mobilgeräten kaum
- Die Commits-Ansicht ist schnell und mobil nutzbar, zeigt aber immer nur einen einzelnen Branch gleichzeitig, sodass schwer zu erkennen ist, ob wirklich alle Änderungen erfasst wurden
- GitHub und GitLab sind keine Kernbestandteile von Git, sondern Dienste von Drittanbietern, was zusätzliche Abhängigkeiten schafft
- Git-Nutzer installieren daher oft grafische Viewer von Drittanbietern, doch diese erfordern separate Installation und Pflege und sind plattformabhängig
- Eines der besseren Werkzeuge, GitUp, funktioniert nur auf dem Mac
- Alle diese Tools verlangen die Synchronisierung eines lokalen Repositories und den Start einer Desktop-GUI; von unterwegs per Smartphone den Projektstatus zu prüfen, ist damit nicht möglich
In Git ist es schwierig, Descendants eines Check-ins zu finden
- Git kann gut in die Vergangenheit zurückblicken, aber es ist schwer, den weiteren Verlauf nach vorn zu verfolgen
- Für einen bestimmten alten Check-in ist die vorherige Historie sichtbar, aber es ist mühsam festzustellen, was danach kam
- Fossil bietet eine Ansicht, die alle Check-ins zeigt, die von einem aktuellen Major Release abgeleitet sind
- Auch in Git ist es nicht unmöglich, Descendants zu finden, aber es ist schwierig
- Auf Stack Overflow gibt es eine Befehlssequenz für Unix, doch sie gibt nur eine Liste der Descendants ohne Branch-Struktur aus
- Dieser Befehl funktioniert nur mit einem lokalen Klon; über Weboberflächen wie GitHub oder GitLab lassen sich Descendants nicht prüfen
- In Fossil sind Informationen über Descendants in die gesamte Website eingebettet
- Auf jeder Check-in-Informationsseite erscheint ein kleiner „Context“-Graph, der den vorherigen und den nächsten Check-in zeigt
- Dazu kommen Funktionen, die Situational Awareness fördern, etwa das Weiterklicken zum nächsten Check-in
- Theoretisch ist Ähnliches in Git mit passenden Erweiterungen, Tools und Befehlen möglich, praktisch ist es aber so umständlich, dass es kaum genutzt wird – und dadurch sinkt das Bewusstsein der Entwickler für die Entwicklung des Codes
Das mentale Modell von Git ist unnötig komplex
- Git-Nutzer müssen stets diese fünf Dinge im Kopf behalten
- das Working Directory
- den „Index“ bzw. den Staging-Bereich
- den lokalen Head
- die lokale Kopie des Remote-Head
- den tatsächlichen Remote-Head
- Fossil-Nutzer müssen nur das Working Directory und den Check-in, an dem sie arbeiten, berücksichtigen; das bedeutet 60 % weniger Ablenkung
- So werden die begrenzten Konzentrationsressourcen der Entwickler geschont, damit sie sich auf die eigentliche Software konzentrieren können
- Ein Nutzer, der sowohl Git als auch Fossil verwendet, schrieb auf HN, dass Fossil mit einem einzigen Befehl das beruhigende Gefühl gibt, dass alles mit dem Server synchronisiert ist, während Git dieses Gefühl nicht vermittelt
Git verfolgt frühere Branch-Namen nicht
- Git bewahrt zwar das vollständige DAG einer Check-in-Sequenz, aber Branch-Tags sind lokale Informationen, werden nicht synchronisiert und bleiben nach dem Schließen eines Branches nicht erhalten; dadurch wird die Untersuchung alter Branches umständlich
- Beispiel: Man fragt sich, was aus dem Branch „prefer-coroutine-sort-subquery“ von vor zwei Jahren geworden ist
- Fossil zeigt klar, dass dieser Branch letztlich in den Trunk gemergt wurde, wo er begonnen hat und dass Änderungen aus dem Trunk zweimal in den Branch zurückgemergt wurden
- GitHub zeigt davon überhaupt nichts und ist praktisch unbrauchbar, wenn man verstehen will, was passiert ist
- GUI-Tools von Drittanbietern können besser sein, stoßen aber an die Grenze, dass Git beim Synchronisieren frühere Branch-Namen nicht bewahrt
- Schon die Tatsache, dass man für solche Informationen Werkzeuge von Drittanbietern braucht, ist selbst eine Schwäche des Kernsystems
Git erfordert mehr administrativen Aufwand
- Git ist komplexe Software; für Installation und Upgrades auf Workstations braucht es Installationsprogramme, und auch der Aufbau eines Git-Servers ist nicht gerade einfach
- Daher nutzen die meisten GitHub oder GitLab und schaffen sich damit zusätzliche Abhängigkeiten
- Fossil ist eine einzelne eigenständige Binärdatei, deren Installation abgeschlossen ist, sobald sie im $PATH liegt
- Diese eine Binärdatei umfasst sowohl die Kernfunktionen von Git als auch die von GitHub bzw. GitLab
- Sie kann ohne zusätzliche Software einen Community-Server mit Wiki, Bug-Tracking und Forum betreiben, Paket-Downloads bereitstellen und das Login-Management übernehmen
- Der Aufbau eines Community-Servers dauert nur wenige Minuten
- Selbst auf einem VPS für 5 US-Dollar pro Monat oder auf einem Raspberry Pi läuft das problemlos, während GitLab und ähnliche Systeme höhere Anforderungen haben
- Je geringer der Verwaltungsaufwand, desto mehr Zeit können Entwickler statt mit dem Versionsverwaltungssystem mit ihrer eigentlichen Software – hier SQLite – verbringen
Git bietet eine schlechte User Experience
- Der xkcd-Comic 1597 ist zwar überzeichnet, kommt der Realität aber ziemlich nahe
- Dass Git keine besonders gute User Experience bietet, ist kaum umstritten; seine interne Implementierung schlägt direkt auf die Oberfläche durch
- Es gibt sogar eine Parodieseite, die gefälschte Git-Manpages erzeugt – so schlecht ist die Oberfläche
- Ein gutes Versionsverwaltungssystem sollte unterstützen statt frustrieren; Git hat sich in den letzten zehn Jahren verbessert, hat aber weiterhin einen langen Weg vor sich
Leitfaden für Git-Nutzer zum Zugriff auf den SQLite-Quellcode
Offizieller GitHub-Mirror
- Seit dem 20.03.2019 gibt es auf GitHub einen offiziellen Git-Mirror des SQLite-Quellcodes
- Er wird inkrementell aus dem offiziellen Fossil-Repository exportiert; ein Cron-Job aktualisiert das GitHub-Repository einmal pro Stunde
- Es handelt sich um einen einseitigen, schreibgeschützten Mirror; Pull Requests oder andere Änderungen werden nicht angenommen
- Alle Änderungen werden ausschließlich über Fossil eingebracht
- Die Hashes zur Identifikation von Check-ins und Dateien unterscheiden sich zwischen Git-Mirror und Fossil
- Der Hauptgrund ist, dass Fossil SHA3-256 und Git SHA1 verwendet
- Beim Export wird der ursprüngliche Fossil-Hash als Footer an den Check-in-Kommentar angehängt; bei Verweisen auf SQLite-Check-ins wird zur Vermeidung von Verwechslungen empfohlen, immer den ursprünglichen Fossil-Hash zu verwenden
Zugriff über das Web
- Das SQLite-Fossil-Repository bietet Download-Links für Tarball, ZIP Archive und SQLite Archive zu beliebigen früheren Versionen
- Das URL-Format ist einfach und lässt sich leicht in Automatisierungswerkzeuge integrieren
- Grundformat:
https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz - Für VERSION können ein Hash-Präfix, ein Branch-Name oder ein Tag wie „version-3.23.1“ verwendet werden
- Für das neueste Release wird „release“, für den aktuellen Trunk „trunk“ verwendet
- Für ZIP bzw. SQLite Archive wird „/tarball/“ durch „/zip/“ oder „/sqlar/“ ersetzt
- Grundformat:
Zugriff mit Fossil
- Fossil ist leicht zu installieren und zu verwenden; für Unix wird das Verfahren beschrieben, unter Windows ist es ähnlich
- Die ausführbare Fossil-Datei herunterladen und im $PATH ablegen
- Das Repository mit
fossil cloneklonen und anschließend mitfossil openöffnen - Danach kann
./configure; makeausgeführt werden (unter Windows mit MSVC:nmake /f Makefile.msc)
- Mit dem Befehl
fossil update VERSIONwird der Checkout auf eine andere Version umgestellt; für VERSION können trunk, ein Hash-Präfix oder ein Branch bzw. Tag verwendet werden - Mit
fossil uilässt sich innerhalb des Checkouts eine lokale Website starten- Ohne Login können keine Änderungen gepusht und damit auch keine Schäden am Projekt verursacht werden; deshalb kann man frei stöbern und experimentieren
Integritätsprüfung des Quellcodes
- Im Wurzelverzeichnis des Source Tree befindet sich eine Datei namens „manifest“
- Diese Datei enthält alle Dateinamen sowie den jeweiligen SHA1- oder SHA3-256-Hash (ältere Dateien mit SHA1, neue Dateien mit SHA3-256)
- Mit einem Skript lassen sich die Hashes extrahieren und gegen die Quelldateien prüfen
- Der Hash-Name eines Check-ins ist der SHA3-256-Hash der Datei „manifest“ selbst; beginnt die letzte Zeile mit „# Remove this line...“, kann diese Zeile ausgelassen werden
1 Kommentare
Hacker-News-Kommentare
Ich habe einmal die Versionsverwaltungswerkzeuge, die ich über die Jahrzehnte benutzt habe, samt Erscheinungsjahr und letztem Nutzungsjahr aufgelistet: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~heute
Zumindest für mich lag die Lebensdauer solcher Werkzeuge bei ungefähr 15 Jahren
Wenn ich Junioren allerdings sage: „Wenn ihr in meinem Alter seid, wird git eine ferne und seltsame Erinnerung sein“, schauen sie mich merkwürdig an
git ist ein großartiges Werkzeug und hat seinen Erfolg verdient, aber es wäre schade, wenn dieses Problemfeld mit git endet
Auf Joel on Software gab es einmal einen Beitrag, dass Software nach etwa 4 Versionen im Wesentlichen fertig sei; das Beispiel war Bürosoftware, insbesondere Excel
Wenn man heute Excel 4 startet, scheint das zu stimmen, weil es die Kernfunktionen im Grunde alle schon beherrscht
git wird wahrscheinlich mindestens doppelt so lange überleben wie frühere Versionsverwaltungswerkzeuge
Das Problem war, dass CVS eine Sackgasse war, die sich nicht auf ein verteiltes Entwicklungsmodell erweitern ließ
Git ging zum lokalen RCS-Modell zurück und ergänzte atomare Commits, womit es aus dem lokalen Optimum namens Subversion ausbrach
Es traf zwar umstrittene Entscheidungen, etwa Umbenennungen nicht nachzuverfolgen oder keine linearen Revisionsnummern zu haben, aber das erwies sich nicht als großes Problem und ermöglichte sehr effizientes Arbeiten ohne die Performance-Probleme von darcs
Wenn man sich ansieht, wie viele Versuche es zwischen 1995 und 2010 gab, Versionsverwaltung zu verbessern, wirkt das grundlegende Datenmodell von git nur noch sehr schwer verbesserbar, selbst mit Erweiterungen wie git-lfs
Neue Kommandozeilenoberflächen kann es geben, aber den bestehenden Platzhirsch zu verdrängen wird immer schwieriger, und ich kenne niemanden in meinem Umfeld, der statt des überladenen und verwirrenden
git checkouttatsächlichgit switchundgit restorebenutztIn anderen Abteilungen der Firma gab es ein wenig svn, aber das war es auch schon
Versionsverwaltungssysteme ändern sich nicht so schnell
Die Werkzeuge in der Liste vor dem Aufkommen verteilter Versionsverwaltung hatten tatsächlich vieles gemeinsam, und ich glaube, git wird noch ziemlich lange bleiben
Historisch gab es viele dominierende Sprachen, aber Englisch wird die endgültige Sprache sein; es gab viele Skriptsprachen, aber javascript wird die endgültige Sprache sein; es gab viele Netzwerkprotokolle, aber TCP/IP wird das endgültige Protokoll sein
Ich denke, für git gilt dasselbe
Was git verdrängen könnte, wären höchstens Umgebungen für neue Programmierer wie glitch[1], die ein eigenes Versionsverwaltungssystem gleich mitbringen
[1]: https://medium.com/glitch/reinventing-version-control-with-g...
Ich glaube, git hat einen schlechten Ruf, weil sich niemand auf eine Art der Nutzung einigen kann
Schon GitHub-PRs und Branch-Pushes, rebase und merge sind Werkzeuge, die im Kern dasselbe tun, aber auf völlig unterschiedliche Weise
Das Problem ist, dass keine der beiden Seiten falsch liegt
Wenn man kleine Commits per rebase umordnet, reduziert das unnötige Komplexität in der Historie, während merge tatsächlich bewahrt, was passiert ist, und so hilft, die Gründe für Änderungen zu verstehen
Natürlich sind Rückwärts-Merges das Schlimmste, aber das ist noch einmal ein eigenes Ärgernis
Beim Pushen auf einen Branch kann man komplett auf force push verzichten, aber bei PR-Branches macht man praktisch immer force push
Sogar einfache Dinge erzeugen unüberbrückbare Gräben
Ich habe gelernt, das Haupt-Repository origin und meinen Fork fork zu nennen, aber manche lernen, das Haupt-Repository upstream und ihren Fork origin zu nennen
Beides ist nicht unbedingt falsch, aber wenn origin auf zwei völlig verschiedene Orte zeigen kann, wird klare Kommunikation sehr schwierig
In der Praxis bedeutet das, dass ich Commits innerhalb eines PRs aktiv per rebase umarbeite und mich nur auf die Frage konzentriere: „Was macht das Review am einfachsten?“
Wenn das Review abgeschlossen ist, frage ich: „Welche Form ist später am einfachsten zu betreiben und zu verstehen?“ Dann kann ich alles squashen oder es in unabhängig deploybare Teile umstrukturieren, damit Rollbacks leichter werden
Der entscheidende Punkt ist, dass diese Arbeiten unterschiedliche Anforderungen haben können und es in Ordnung ist, zu verschiedenen Zeitpunkten unterschiedliche Vorgehensweisen zu verwenden
Es verlangt allerdings mehr Urteilsvermögen vom Einzelnen und ist schwerer, es einem großen Team insgesamt beizubringen und durchzusetzen
Erstere betrifft Dinge, die keine Auswirkungen auf andere haben
Ob du zum Beispiel deine Remote-Repositories
originundupstreamnennst oderforkundorigin, ist deinen Kollegen egalLetztere betrifft Dinge, die mit anderen abgestimmt werden müssen
Zum Beispiel die Frage, welche Form die endgültige git-Historie haben soll
Wenn Apple die Kommandozeilenoberfläche von git entworfen hätte, wäre sie aus Sicht der User Experience vermutlich milliardenfach besser und nur etwa 10 % weniger mächtig gewesen
Schön, dass Fossil für sie gut funktioniert, aber dieser Satz stößt mir auf: „Fossil ist eine einzelne, eigenständige ausführbare Binärdatei, die installiert ist, sobald man sie in
$PATHlegt, und diese eine Datei enthält sowohl die Kernfunktionen von Git als auch die Funktionen von GitHub/GitLab …“Git hat zwar viele Probleme, ist aber nicht die Art von Ding, die gleich noch die Küchenspüle mit hineinpackt.
Ich finde den Ansatz „eine Sache gut machen“ besser.
Wenn man zum Beispiel
git instawebausführt, startet es einen lokalen CGI-Server und ein Perl-CGI-Skript und bietet damit eine sehr einfache Web-UI: https://git-scm.com/docs/git-instawebIn dieser Hinsicht unterscheidet es sich nicht groß von den Kernfunktionen von Fossil.
Git hat auch viele Funktionen zur Integration mit E-Mail-Clients, von deren Existenz und Zweck Leute, die nur GitHub benutzen, wahrscheinlich nicht einmal wissen.
Dazu gehört etwa
git send-email, mit dem man direkt aus Git E-Mail-Patches versenden kann: https://git-scm.com/docs/git-send-emailAlles ist zusammengesetzt, alles ist eine Pipeline von Befehlen und aus mehreren Dingen gemacht.
Was die „zu erledigende Sache“ ist, ist nicht absolut, sondern hängt von der Perspektive des Betrachters ab.
Das Single-Responsibility-Prinzip lässt sich nicht 1:1 auf die Realität anwenden, sondern ist nur ein Kompromiss, um die Balance zwischen Kohäsion und Modularität zu halten.
Wo wir den Schnitt setzen und etwas „eins“ nennen, hängt von uns und unseren Bedürfnissen ab.
Für viele Menschen sind GitHub-Werkzeuge so stark in ihren Workflow integriert, dass Git allein überhaupt nicht benutzbar ist.
Für sie ist GitHub die „eine Sache“, und SQLite hat eben seine eigene „eine Sache“.
Wie schon gesagt, widerspricht das der Unix-Philosophie, eine Sache gut zu machen.
Für mich ist es offensichtlich sauberer, ein System in Komponenten zu zerlegen, die sich später unabhängig austauschen oder verändern lassen.
Der Installer ist über 50 MB groß und enthält, wenn ich mich richtig erinnere, sogar ein Terminal.
Fossil dagegen kann man für jede unterstützte Plattform als eigenständige 3,3-MB-Binärdatei herunterladen.
https://git-man-page-generator.lokaltog.net ist das Lustigste, was ich seit Langem gesehen habe.
git-erase-working-treeklingt nützlich: „die aktuelle Working Tree des Upstream-Root und der Konfiguration sorgfältig löschen und in die aktive GUI quiltimportieren“.git-molest-headals „den Upstream-Head mithilfe des Remote-Index unsachgemäß belästigen und die passenden Hooks ausführen, um den gegebenen Head in eine Tabelle zu verwandeln“ ist vielleicht etwas zu provokant.Git hat so viele seltsame Befehle, dass mich inzwischen nichts mehr überrascht.
git-tease-chain,git-scrub-dangling-object,git-seize-mailmap,git-dress-graft,git-strangle-tree,git-satisfy-daemonundgit-pat-tree-object.Um überzeugenderen Unsinn zu erzeugen, bräuchte es wohl noch mehr LLM-Würze.
Frühere Diskussionen:
2021, 356 Kommentare: https://news.ycombinator.com/item?id=29125934
2018, 608 Kommentare: https://news.ycombinator.com/item?id=16806114
Es gab wohl noch mehr, aber dass dasselbe Dokument über mehrere Pfade auffindbar ist — auch ohne
www-Domain, ohne/drafts/-Pfad und ohne/matrix/-Pfad — macht es schwerer, frühere Einreichungen zu finden.Daran ist auch berechtigte Kritik an Git, aber manches wirkt schon etwas seltsam
Ich habe Git in ganz unterschiedlichen Situationen verwendet, von lokalen privaten Repositories bis hin zu sehr großen Unternehmens-Repositories, und ehrlich gesagt ist mir ungefähr die Hälfte dieser Probleme noch nie begegnet
Das gilt auch für die Aussage, „network ist langsam beim Rendern, bietet deutlich weniger Details und funktioniert auf Mobilgeräten fast gar nicht“, und ich hoffe, der Tag kommt nie, an dem unser Team Mobilgeräte als Mittel in Betracht ziehen muss, um den Status von Branches zu prüfen
So einen Anwendungsfall habe ich noch nie in Betracht gezogen
Kommt das bei anderen wirklich häufig vor?
Mindestens 50 % meiner Code-Erkundung mache ich anscheinend auf dem Handy
Dafür nutze ich oft das mobile GitHub-Webinterface, und die Unterstützung zum Auffinden von Referenzen war wirklich eine große Hilfe
Die Suche ist weiterhin eher schwach, und ich hasse es, dass das für SPAs typische Ruckeln die normale Seitensuche ständig kaputtmacht
Wenn ich den Firefox-Code durchforsten muss, nutze ich Searchfox [0]; das ist schnell und großartig, und ich habe kaum Beschwerden
Nur blame könnte auf Mobilgeräten noch etwas besser sein
Als Kontext: Ich bin Doktorand, forsche zu Programmiersprachen und Systemen und betreibe in meiner Freizeit auch einiges an IoT-Hacking
Je nachdem, wo man die Generationengrenze zieht, bin ich entweder ein älterer Gen Z oder der denkbar jüngste Millennial
[0] https://searchfox.org
Abgesehen von der instabilen Datenabdeckung funktionierte GitHub gut, und auch leichtes Code-Review war problemlos möglich
GitHub pulse[1] hat eine gute UI, um aktuelle Aktivitäten anzusehen
Da am SQLite-Mirror nicht auf GitHub gearbeitet wird, gibt es dort nur den Commit-Verlauf und diese Seite ist leer, aber das verlinkte Caddy-Projekt ist ein besseres Beispiel
Mir persönlich scheint das nützlicher als eine Timeline zu sein
Ich frage mich, ob schon jemand eine gleichwertige Ansicht für git/GitHub gebaut hat
Es scheint nicht besonders schwer zu sein
[1] https://github.com/caddyserver/caddy/pulse
Zum Editieren auf GitHub habe ich einen Android-Editor gebaut und ihn später so angepasst, dass er auch mit GitLab funktioniert
Es gibt viele Gründe dafür, aber größtenteils liegt es daran, dass git auf Mobilgeräten fast unmöglich zu benutzen ist, egal ob auf GitHub oder GitLab
Den Status kann man prüfen, aber darüber hinaus wird es fast sofort schwierig
Dieser Beitrag hat mich auch in anderer Hinsicht stark angesprochen
Obwohl ich ein O’Reilly-Buch über GitHub geschrieben habe, habe ich git nach über zehn Jahren Nutzung immer noch nicht vollständig verstanden
Ich kann die Kritikpunkte hier gut nachvollziehen
Wenn sie besser entworfen und implementiert wäre, würde sie natürlich auch mobil funktionieren
Leute greifen auf Mobilgeräten aus denselben Gründen auf GitHub zu wie auf anderen Plattformen
Ich selbst habe das definitiv auch schon getan
Solche Beobachtungen über git sind nicht unbedingt „Probleme“, sondern eher Werturteile über Funktionen
Man kann ihnen zustimmen oder widersprechen, aber es sind nicht unbedingt Dinge, denen man zwangsläufig begegnen muss
Das scheint der Unterschied zwischen graduellem Leistungsabfall und sofortigem Scheitern zu sein
Selbst wenn eine perfekt vergoldete Option noch so gut ist, wird sie fragil und damit wertlos, wenn sie die einzige Option ist
Vor ein paar Tagen habe ich ein Video gesehen, das Git-Alternativen erklärte, und Fossil war natürlich auch darunter
Ich habe Fossil in einigen Projekten verwendet, und es war in Ordnung
Pijul https://pijul.org/, das in diesem Vortrag vorgestellt wurde, fand ich sehr interessant, und auf HN wurde es früher auch schon diskutiert
Quelle: https://www.youtube.com/watch?v=M4KktA_jbOE
Es wirkt wie der heilige Gral der Versionsverwaltung
Aber in privaten Projekten entwickle ich ohnehin linear, und bei der Arbeit habe ich keine Kontrolle darüber, was verwendet wird, daher habe ich es nie wirklich benutzt
Ich habe Fossil für persönliche lokale Projekte verwendet.
Es ist ein ziemlich leistungsfähiges Versionsverwaltungssystem, und auch das Web-UI ist ziemlich gut.
Man sollte nur darauf achten, die zugrunde liegende SQLite-Repository-Datenbank regelmäßig zu sichern.
Nachdem ich Fossil aktualisiert und ein paar Commits gemacht hatte, habe ich versehentlich wieder mit einer älteren Fossil-Version committet; dabei wurde die Fossil-Repository-Datenbank irreparabel beschädigt, und ich habe mehrere Tage Arbeit verloren.
Git hat mir in 10 Jahren täglicher Nutzung nie ein Repository zerstört, unabhängig von der Version.
Auf verschiedenen Systemen liegen willkürlich Versionen auseinander, die mehrere Jahre Unterschied haben, und ich benutze beim Einrichten eines Systems einfach weiter die Binärdatei, die damals dabei war.
Darunter sind macOS, verschiedene Linux-Varianten und auch FreeBSD-Boxen; weiter zurück gab es wohl auch Windows.
Ich synchronisiere zwischen ihnen mit allerlei Behelfslösungen.
Manche Repositories sind über 10 Jahre alt, eines hat mehr als 10.000 Commits, und ein anderes ist mehrere GB groß, weil ich die komplette Entwicklungsumgebung eingecheckt habe.
Ich habe gelegentlich gesagt bekommen, dass ein Rebuild nötig sei, und es hat jedes Mal funktioniert.
Wenn ich während eines Commits einen Tippfehler entdecke, breche ich aus Gewohnheit auch mal mit
ctrl-cab.Trotzdem hat es mich nie enttäuscht.
Fossil ist mit Abstand das zuverlässigste Programm, das ich je benutzt habe.
Das zugrunde liegende Artefaktformat von Fossil ist vom Anfang bis heute kompatibel.
Es gab Verbesserungen, aber keine inkompatiblen Änderungen, und auch unter den vielen Nutzern im Fossil Forum gibt es keine Berichte über solche Beschädigungen.
Meine Vermutung wäre, dass hier eher mit einem neueren Fossil eine Funktion verwendet wurde, um etwas einzuchecken, und dann mit einem älteren Fossil, das diese neue Funktion nicht versteht, versucht wurde, es auszuchecken, woraufhin ein Fehler auftrat.
Fossil verwendete anfangs zum Beispiel nur SHA1-Hashes, wurde nach dem SHAttered-Angriff aber erweitert, sodass sowohl SHA1 als auch SHA3 unterstützt werden.
Natürlich ist das nur eine Vermutung, aber sie erscheint mir am plausibelsten.
Ich habe für das SQLite-Repository, das selbstgehostete Fossil-Repository von Fossil selbst und die über 100 Fossil-Repositories, die ich verwalte, noch nie ein reines Backup erstellt.
Zur Absicherung gegen Katastrophen habe ich aber Klone auf anderen Maschinen.
Tatsächlich laufen auf mehreren Maschinen weltweit cron-Jobs, die wichtige Fossil-Repositories wie SQLite stündlich per
syncabgleichen.Aber ein reines Backup habe ich nie erstellt.
Vor ein paar Jahren wurde das zentrale SQLite-Repository tatsächlich einmal beschädigt.
Irgendwie war der File-Descriptor 2 geschlossen worden, und beim Öffnen des Repositorys, also der SQLite-Datenbank, wurde es als File-Descriptor 2 geöffnet.
Danach führte irgendein Bug in Fossil zu einem
assert(), das auf File-Descriptor 2 schrieb und so Teile der Datenbank überschrieb.Wir haben das Repository aus einem Klon wiederhergestellt, den Assertion-Fehler in Fossil behoben und SQLite so gehärtet, dass es keine File-Deskriptoren kleiner als 3 verwendet.
Dazu passend: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
Wenn man den Zuverlässigkeitsansatz der SQLite-Entwickler bedenkt, wirkt das wie ein schwerwiegender Bug, der behoben werden müsste.
Meistens waren sie aber nicht irreparabel.
Wow, darin habe ich mich richtig festgelesen.
Das war wahrscheinlich das Beste, was ich seit Langem gelesen habe.
Es sieht so aus, als könnte man Fossil verwenden und trotzdem nach Git/GitHub spiegeln: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
Das eingebaute UI sieht ordentlich aus, tatsächlich brauchbar und leicht zu durchsuchen.
Ich hätte mir nur gewünscht, dass Commits auch im UI unterstützt werden, aber ich konnte das nicht finden.
Dann müsste man nicht Kommandozeile und Web-Interface mischen, um die Arbeit abzuschließen.
Wenn man über Fossil ein Wrapper-UI bauen könnte, das
open,init,commit,sync,sync-with-git,start-web-interfaceunterstützt, oder wenn man das direkt in Fossil einbauen könnte, wäre das wahrscheinlich ziemlich nützlich für weniger technische Menschen oder Nicht-Entwickler, die trotzdem mit Code arbeiten, etwa in Biologie, Mathematik oder Data Science, um Jupyter-Notebooks und Ähnliches zu verwalten.Natürlich könnte man für so etwas auch einfach einen simplen Git-UI-Client verwenden, aber dann ginge das eingebaute Wiki und Ticketsystem verloren.
Die Möglichkeit, lokal zu arbeiten, ist ebenfalls nützlich, aber das kann Git auch.
Jedenfalls habe ich schon erlebt, dass weniger technische Leute Git oder Versionsverwaltung allgemein eher ablehnen.
Ich sehe aber Potenzial darin, eingebautes Wiki und Tickets im selben Repository zu haben.
Dass es nur eine Datei zum Sichern gibt, ist ebenfalls interessant.
Für Softwareentwickler ist ein Versionsverwaltungssystem ein Werkzeug wie die IDE oder das zugrunde liegende Betriebssystem.
Je weniger man an solchen Werkzeugen herumbastelt, desto produktiver ist man.
Nachdem ich verschiedene Versionsverwaltungssysteme benutzt habe, liegt Fossil für mich genau im perfekten sweet spot.
Im Wortsinn: einmal einrichten und dann vergessen.