Warum werden Quellcodeverwaltungssysteme immer noch hauptsächlich mit Dateien gesichert?

22

Es scheint, dass immer noch mehr Versionsverwaltungssysteme Dateien als Mittel zum Speichern der Versionsdaten verwenden. Vault und TFS verwenden SQL Server als Datenspeicher, was meiner Meinung nach sowohl für die Datenkonsistenz als auch für die Geschwindigkeit besser wäre.

Warum verwendet SVN, glaube ich, GIT, CVS usw. das Dateisystem immer noch im Wesentlichen als Datenbank? MSSQL, Oracle, Postgre usw.)?

EDIT: Ich denke, eine andere Möglichkeit, meine Frage zu stellen, ist "Warum rollen VCS-Entwickler ihr eigenes strukturiertes Datenspeichersystem, anstatt ein vorhandenes zu verwenden?"

version-control

— Andy
quelle

29

Was, glauben Sie, verwenden die meisten Datenbanken als Basisdaten? Die meisten verwenden Dateien (einige verwenden jedoch den direkten Zugriff auf Festplatten). Sie können alle Funktionen einer Datenbank nutzen, indem Sie "Nur Dateien" verwenden.

— Joachim Sauer

2

@JoachimSauer Fair point, allerdings müsstest du dann natürlich selbst eine Datenbank anlegen. Was dumm ist, wenn Ihr gewünschter Funktionsumfang in der Nähe der vorhandenen Lösungen liegt und Sie keine guten Gründe haben, einen davon nicht zu verwenden.

1

@JoachimSauer Ja, das ist mir klar, aber DBM-Systeme haben Möglichkeiten, um sicherzustellen, dass nichts Inkonsistentes in die Datenbank gelangt. Sofern diese dateibasierten Repositorys nicht Transactional NTSF verwenden, besteht immer noch die Möglichkeit, dass sie beschädigt sind. Und ich vertraue mehr auf eine echte Datenbank als auf eine Reihe von Entwicklern, die das Rad grundlegend neu erfinden, da wir meiner Meinung nach der Meinung sind, dass Quellcodeverwaltungssysteme Datenintegrität erfordern.

— Andy

2

@delnan Transaktionsunterstützung und interne Konsistenz. Wir stellen jetzt unser SVN-Repository von Band wieder her, auf das der SVN-Server nicht alle Dateien geschrieben hat, die er eigentlich haben sollte. Auch auf der Suche nach riesigen Datenmengen. Mein Punkt ist, warum versuchen, das Rad neu zu erfinden.

— Andy

7

Jedes Hauptbetriebssystem wird mit einem eingebauten Dateisystem geliefert. Alle diese Dateisysteme verfügen über die gleichen grundlegenden Funktionen (Dateien, Ordner, Beständigkeit derselben). Grundsätzlich ist eine Datenbank eine zusätzliche Abhängigkeit, die der Endbenutzer installieren und auf dem neuesten Stand halten muss. Die Quellcodeverwaltung ist nicht das Hauptgeschäft der meisten Leute (es sei denn, Sie sind SourceForge oder Github). VC wird häufig vom neuesten Mitglied des Teams über die Befehlszeile auf Servern installiert. Einfache Installation und Einrichtung ist wichtig.

— GlenPeterson

23

TL; DR: Nur wenige Versionskontrollsysteme verwenden eine Datenbank, da dies nicht erforderlich ist.

Warum sollten sie nicht eine Frage für eine Frage beantworten? Welche Vorteile bieten "echte" Datenbanksysteme in diesem Zusammenhang gegenüber einem Dateisystem?

Bedenken Sie, dass die Revisionskontrolle hauptsächlich ein paar Metadaten und viele Textunterschiede erfasst. Text wird nicht effizienter in Datenbanken gespeichert, und die Indizierbarkeit des Inhalts spielt keine Rolle.

Nehmen wir an, dass Git (aus Gründen des Arguments) eine BDB oder SQLite-DB als Back-End zum Speichern von Daten verwendet hat. Was wäre daran zuverlässiger? Alles, was einfache Dateien beschädigen könnte, kann auch die Datenbank beschädigen (da dies auch eine einfache Datei mit einer komplexeren Codierung ist).

Wenn das Revisionskontrollsystem schnell genug und zuverlässig genug ist und nicht optimiert werden muss, warum sollte dann das gesamte Design geändert werden, um ein komplexeres System zu verwenden?

— Mikebabcock
quelle

2

TLDR? Ihre Antwort war doppelt so lang und die Frage war so kurz wie sie ist!

— Brad

25

@Brad Die drei folgenden Wörter TL;DRsind die gekürzte Version der Antworten, keine Aussage, dass die Frage zu lang ist und er sie nicht gelesen hat, bevor er geantwortet hat.

6

@Andy Mercurial hat auch "grep in history" und git hat es wahrscheinlich auch. Es ist auch schon blitzschnell. Experten überlassen: Die Leute, die VCS entwickeln, sind Experten.

3

Ich möchte nur hinzufügen, dass ich Ihren Standpunkt verstehe. Wenn VCS fehlerhafte Daten schreibt, spielt es keine Rolle, ob diese Daten in eine Datei oder Datenbank geschrieben werden. Die Kehrseite ist jedoch, dass dateibasierte Repos wahrscheinlich in mehr als eine Datei gleichzeitig schreiben und normalerweise keine Transaktionsunterstützung dafür vorhanden ist. Wenn also eine Datei schreibt, aber eine andere fehlschlägt, ist Ihr VCS jetzt beschädigt, im Gegensatz zu Mehrfachtabellenschreibungen in einer Datenbank Transaktion wird als Einheit als fehlgeschlagen bestätigt. Ich habe das Gefühl, dass eine Gruppe von Entwicklern, die Datenbanksoftware erstellt, mehr Erfahrung damit hat als die Leute, die SVN schreiben ... aber vielleicht irre ich mich.

— Andy

6

Ihre Wahl von git "aus Gründen des Arguments" ist hier ein wichtiger Punkt: git hat ein sehr gutes Modell zum Schreiben seiner Objekte, aber viele Werkzeuge tun dies nicht. Wenn der Computer während eines Commits ausgeschaltet wird, haben Sie mit git einige der Objekte in das Dateisystem geschrieben und sie sind nur noch nicht erreichbar. Bei anderen VCSs haben Sie möglicherweise die Änderungen an die Hälfte der Dateien angehängt (und es kommt zu Verwirrung). Sie könnten argumentieren, dass andere Tools zur Versionskontrolle schlecht entworfen sind (und Sie hätten Recht), aber wenn Sie ein VCS schreiben, ist dies der Fall Es ist viel einfacher, einfach eine SQL-Transaktion zu verwenden und sie das Richtige tun zu lassen.

— Edward Thomson

25

Sie scheinen viele Annahmen zu treffen, möglicherweise basierend auf Ihren Erfahrungen mit SVN und CVS.

Git und Mercurial sind im Grunde wie SVN und CVS

Das Vergleichen von Git und CVS ist wie das Vergleichen von iPad und Atari. CVS wurde erstellt, als Dinoaurier die Erde durchstreiften . Subversion ist im Grunde eine verbesserte Version von CVS. Unter der Annahme, dass moderne Versionskontrollsysteme wie git und Mercurial wie sie funktionieren, ergibt das wenig Sinn.

Eine relationale Datenbank ist effizienter als eine Einzweckdatenbank

Warum? Relationale Datenbanken sind sehr kompliziert und möglicherweise nicht so effizient wie Einzweckdatenbanken. Einige Unterschiede auf den ersten Blick:

Versionskontrollsysteme benötigen keine komplizierten Sperren, da Sie sowieso nicht mehrere Commits gleichzeitig ausführen können.
Verteilte Versionskontrollsysteme müssen sehr platzsparend sein, da die lokale Datenbank eine vollständige Kopie des Repos ist.
Versionskontrollsysteme müssen nur auf einige bestimmte Arten nach Daten suchen (nach Autor, nach Revisions-ID, manchmal nach Volltextsuche). Es ist trivial, eine eigene Datenbank zu erstellen, die Autoren- / Revisions-ID-Suchen unterstützt, und die Volltextsuche ist in keiner relationalen Datenbank, die ich ausprobiert habe, sehr schnell.
Versionskontrollsysteme müssen auf mehreren Plattformen funktionieren. Dies erschwert die Verwendung einer Datenbank, die als Dienst installiert und ausgeführt werden muss (z. B. MySQL oder PostgreSQL).
Versionskontrollsysteme auf Ihrem lokalen Computer müssen nur ausgeführt werden, wenn Sie etwas tun (z. B. ein Commit). Es ist verschwenderisch, einen Dienst wie MySQL die ganze Zeit laufen zu lassen, nur für den Fall, dass Sie einen Commit durchführen möchten.
In den meisten Fällen möchten Versionskontrollsysteme niemals den Verlauf löschen, sondern ihn lediglich anhängen. Dies kann zu unterschiedlichen Optimierungen und unterschiedlichen Methoden zum Schutz der Integrität führen.

Relationale Datenbanken sind sicherer

Nochmals, warum? Sie scheinen davon auszugehen, dass Versionskontrollsysteme wie git und Mercurial keine atomaren Commits haben, da Daten in Dateien gespeichert sind . Relationale Datenbanken auch speichern ihre Datenbanken als Dateien. Es ist hier bemerkenswert, dass CVS keine atomaren Commits ausführt, aber das liegt wahrscheinlich daran, dass es aus dem dunklen Zeitalter stammt, und nicht daran, dass sie keine relationalen Datenbanken verwenden.

Es gibt auch das Problem, die Daten vor Beschädigung zu schützen, sobald sie in der Datenbank sind, und die Antwort ist dieselbe. Wenn das Dateisystem beschädigt ist, spielt es keine Rolle, welche Datenbank Sie verwenden. Wenn das Dateisystem nicht beschädigt ist, ist möglicherweise Ihr Datenbankmodul defekt. Ich verstehe nicht, warum eine Versionskontrolldatenbank dafür anfälliger ist als eine relationale Datenbank.

Ich würde argumentieren, dass verteilte Versionskontrollsysteme (wie Git und Mercurial) besser zum Schutz Ihrer Datenbank geeignet sind als eine zentralisierte Versionskontrolle, da Sie das gesamte Repo von jedem Klon aus wiederherstellen können. Wenn also Ihr zentraler Server zusammen mit all Ihren Sicherungen spontan brennt, können Sie ihn wiederherstellen, indem Sie ihn git initauf dem neuen Server und dann git pushvon einem beliebigen Entwicklercomputer ausführen .

Das Rad neu zu erfinden ist schlecht

Gerade weil Sie können eine relationale Datenbank für jedes Speicherproblem verwenden bedeutet nicht , Sie sollten . Warum verwenden Sie Konfigurationsdateien anstelle einer relationalen Datenbank? Warum Bilder im Dateisystem speichern, wenn Sie die Daten in einer relationalen Datenbank speichern könnten? Warum sollten Sie Ihren Code im Dateisystem belassen, wenn Sie ihn alle in einer relationalen Datenbank speichern könnten?

"Wenn Sie nur einen Hammer haben, sieht alles aus wie ein Nagel."

Es gibt auch die Tatsache, dass Open-Source-Projekte es sich leisten können , das Rad immer dann neu zu erfinden, wenn es bequem ist, da Sie nicht die gleichen Ressourcenbeschränkungen haben wie kommerzielle Projekte. Wenn Sie einen Freiwilligen haben, der Experte für das Schreiben von Datenbanken ist, warum sollten Sie ihn dann nicht verwenden?

Was den Grund angeht, warum wir den Autoren von Revisionskontrollsystemen vertrauen, dass sie wissen, was sie tun. Ich kann nicht für andere VCS sprechen, aber ich bin ziemlich zuversichtlich, dass Linus Torvalds Dateisysteme versteht .

Warum verwenden einige kommerzielle Versionskontrollsysteme dann eine relationale Datenbank?

Höchstwahrscheinlich eine Kombination der folgenden:

Einige Entwickler möchten keine Datenbanken schreiben.
Entwickler von kommerziellen Versionskontrollsystemen haben Zeit- und Ressourcenbeschränkungen, sodass sie es sich nicht leisten können, eine Datenbank zu schreiben, wenn sie etwas in der Nähe haben, was sie bereits wollen. Außerdem sind Entwickler teuer, und Datenbankentwickler (wie z. B. Benutzer, die Datenbanken schreiben) sind wahrscheinlich teurer, da die meisten Benutzer nicht über diese Erfahrung verfügen.
Benutzer von kommerziellen Versionskontrollsystemen kümmern sich mit geringerer Wahrscheinlichkeit um den Aufwand beim Einrichten und Ausführen einer relationalen Datenbank, da sie bereits eine haben.
Benutzer von kommerziellen Versionskontrollsystemen möchten mit größerer Wahrscheinlichkeit eine relationale Datenbank, die ihre Revisionsdaten sichert, da sich diese möglicherweise besser in ihre Prozesse integrieren lässt (wie z. B. Sicherungen).

— Setzen Sie Monica wieder ein
quelle

1

Eine Sache: SVN-Commits sind atomar. Tatsächlich ist dies ein wichtiges Verkaufsargument (oder zumindest, als sie CSV-Benutzer zum Umstieg überreden mussten).

1

@delnan - Beachten Sie, dass es einen großen Unterschied zwischen der theoretischen Atomizität gibt, die Sie erhalten, svnwenn sich verschiedene Verzeichnisse in Ihrem Arbeitsverzeichnis in verschiedenen svnRevisionen befinden, und der tatsächlichen Repository-weiten Atomizität, die Sie mit gitoder erhalten hg.

— Mark Booth

2

@Andy Und mein Punkt ist, dass Sie genau dieselben Szenarien ohne eine vollständige relationale Datenbank handhaben können. Wenn zwei Personen genau zur gleichen Zeit einen Commit ausführen, kann der Server einen nach dem anderen ausführen. Die Implementierung ist nicht kompliziert. Wenn Sie dies mit einem lokalen Benutzer tun möchten, benötigen Sie nur eine Sperrdatei. Wenn Sie ein Commit starten, müssen Sie die Datei sperren. Wenn Sie ein Commit beenden, geben Sie die Sperre frei. Wenn Sie Commits für mehrere Zweige gleichzeitig zulassen möchten, verwenden Sie für jeden Zweig eine Sperrdatei. Sicher, SQLite würde das für mich tun, aber es ist nicht notwendig .

— Setzen Sie Monica

1

Ebenso ist die Implementierung eines einfachen Journals nicht kompliziert. (1) Schreiben Sie das neue Commit in eine Datei. (2) Kopieren Sie die alte Indexdatei. (3) Schreiben Sie eine neue Indexdatei. (4) Löschen Sie die Kopie der alten Indexdatei. Wenn Sie bei Schritt 1, 2 oder 4 einen Fehler feststellen, müssen Sie nur die neu erstellten Dateien bereinigen. Wenn Sie in Schritt 3 fehlschlagen, müssen Sie nur die alte Indexdatei zurückkopieren. Jemand, der Dateisysteme besser versteht, könnte wahrscheinlich eine effizientere Version davon erstellen, aber Sie können jederzeit auf den Quellcode von SQLite verweisen, wenn Sie dies benötigen (es ist gemeinfrei).

— Setzen Sie Monica

1

@ BrendanLong Tolle Punkte. Schätzen Sie die Diskussion. Um es klar zu sagen, ich glaube, dass beide Arten von Backing Stores Vor- und Nachteile haben. Ich glaube nicht, dass es nur eine richtige Antwort gibt. Allerdings war ich ein bisschen überrascht, dass es nur drei zu geben scheint (vier, wenn Sie Vault und Vercity getrennt zählen), die SQL verwenden, und die große Mehrheit nicht, das ist alles.

— Andy

18

Wird svnverwendet, um BDB für Repositorys zu verwenden. Dies wurde schließlich beseitigt, weil es anfällig für Brüche war.

Ein anderes VCS, das derzeit eine DB (SQLite) verwendet, ist fossil. Es enthält auch einen Bug-Tracker.

Ich vermute, der wahre Grund ist, dass VCS mit vielen Dateien arbeiten. Dateisysteme sind nur eine andere Art von Datenbank (hierarchisch, auf CLOB / BLOB-Speichereffizienz ausgerichtet). Normale Datenbanken kommen nicht so gut zurecht, weil es dafür keinen Grund gibt - es gibt bereits Dateisysteme.

— Mike Larsen
quelle

1

BDB würde nicht genau als zuverlässig gelten - wie SQLite ist es eine In-Process-Datenbank. Trotzdem denke ich, dass die Zuverlässigkeit von Oracle / MSSQL / MySQL / Postgres, abhängig davon, wie Sie sie konfigurieren, sich nicht wesentlich von den Dateisystemen unterscheidet. Das Hauptproblem besteht darin, dass RDBMS nicht für die hierarchischen und grafischen Strukturen erstellt werden, mit denen VCSs normalerweise arbeiten. Und in diesem Fall gewinnen Dateisysteme einfach.

— Mike Larsen

3

@Andy: Fossil wurde vom Schöpfer von SQLite erstellt. Es ist nicht wirklich überraschend :-)

— Jörg W Mittag

1

@ Andy: Ich würde SQLite viel mehr vertrauen als Oracle oder MSSQL. Kein Wunder, dass es mit Abstand die am häufigsten verwendete SQL-Datenbank ist. Es ist auch diejenige, die für die unterschiedlichsten Architekturen portiert ist, wobei jede ihre eigenen Herausforderungen hat, wodurch der gemeinsam genutzte Code unglaublich kugelsicher wird.

— Javier

1

@ Javier Ich würde Sqlite nicht so sehr vertrauen wie MSSQL oder Oracle. Wie Mike sagte, macht mir der In-Process-Teil Angst, als ob Ihre App sterben würde, was dazu führen könnte, dass Ihre Datenbank jetzt beschädigt wird. Bei einer Client / Server-Datenbank bricht der sterbende Client die Transaktion ab. Um nicht zu sagen, es ist unmöglich, dass CS-DBs korrupt sind, aber ich denke, es ist weniger wahrscheinlich, dass die DB-Engine mit der Anwendung kombiniert wird.

— Andy

5

@Andy, dafür sind Transaktionen gedacht. Unabhängig davon, zu welchem Zeitpunkt Sie eine gute DB-Engine beenden, wird eine bestimmte Transaktion entweder festgeschrieben oder nicht. SQLites Implementierung von Atomic Commits ( sqlite.org/atomiccommit.html ) ist besonders ausgefeilt.

— Javier

10

Ein Dateisystem ist eine Datenbank. Natürlich keine relationale Datenbank, aber die meisten sind sehr effiziente Schlüssel- / Wertspeicher. Und wenn Ihre Zugriffsmuster für einen Schlüsselwertspeicher (z. B. das Git-Repository-Format) gut konzipiert sind, bietet die Verwendung einer Datenbank wahrscheinlich keine wesentlichen Vorteile gegenüber der Verwendung des Dateisystems. (Tatsächlich ist es nur eine weitere Abstraktionsebene, die sich in den Weg stellt.)
Viele der Datenbankfunktionen sind nur zusätzliches Gepäck. Volltextsuche? Ist die Volltextsuche für den Quellcode sinnvoll? Oder müssen Sie es anders kennzeichnen? Dies erfordert auch, dass Sie bei jeder Revision vollständige Dateien speichern, was ungewöhnlich ist. Viele Versionskontrollsysteme speichern Deltas zwischen Revisionen derselben Datei, um Speicherplatz zu sparen, z. B. Subversion und Git (zumindest bei Verwendung von Packdateien).
Die plattformübergreifenden Anforderungen machen die Verwendung einer Datenbank schwieriger.

Die meisten Tools zur Versionskontrolle können auf mehreren Plattformen ausgeführt werden. Bei zentralisierten Tools zur Versionskontrolle betrifft dies nur die Serverkomponente, es ist jedoch immer noch schwierig, sich auf einen einzelnen Datenbankserver zu verlassen, da Unix-Benutzer Microsoft SQL Server nicht installieren können und Windows-Benutzer möglicherweise nicht bereit sind, PostgreSQL oder MySQL zu installieren. Das Dateisystem ist der kleinste gemeinsame Nenner. Es gibt jedoch mehrere Tools, bei denen der Server auf einem Windows-Computer installiert werden muss und daher SQL Server erforderlich ist, z. B. SourceGear Vault und Microsoft Team Foundation Server .

Verteilte Versionskontrollsysteme machen dies noch schwieriger, da jeder Benutzer eine Kopie des Repository erhält. Dies bedeutet, dass jeder Benutzer eine Datenbank benötigt, um das Repository zu speichern. Dies impliziert, dass die Software:
1. Beschränkt sich auf eine Untergruppe von Plattformen, auf denen eine bestimmte Datenbank vorhanden ist
2. Zielt auf ein einzelnes Datenbank-Backend ab, das plattformübergreifend ist (z. B. SQLite).
3. Zielt auf ein steckbares Speicher-Backend ab, sodass jede gewünschte Datenbank (möglicherweise einschließlich des Dateisystems) verwendet werden kann.
Die meisten verteilten Versionskontrollsysteme verwenden daher nur das Dateisystem. Eine bemerkenswerte Ausnahme ist SourceGears Veracity , das in einer SQLite-Datenbank (nützlich für lokale Repositorys) oder einer relationalen Datenbank wie SQL Server (möglicherweise nützlich für einen Server) gespeichert werden kann. Ihr Cloud-gehostetes Angebot verwendet möglicherweise ein nicht relationales Speicher-Backend wie Amazon SimpleDB , aber ich weiß nicht, dass das wahr ist.

— Edward Thomson
quelle

Genau wie der Kommentar eines Teufels, scheinen die meisten Leute, die diese Art von "Warum nicht eine Datenbank verwenden?" - Fragen stellen, "Warum nicht ein RDBMS verwenden?" Zu bedeuten. mit all den ACID-Konformitäten und anderen damit verbundenen Problemen. Die Tatsache, dass alle Dateisysteme bereits Datenbanken eigener Art sind, wurde bereits verworfen.

— Mikebabcock

6

Soweit ich in vielen Angeboten gesehen habe, scheinen Dateien "gut genug" für den Job zu sein, was vernünftig ist, wenn man berücksichtigt, dass die Ausgabe von VCSes am Ende des Tages auch Dateien ist.

Es gibt viele Unternehmen, die ein RDBMS-Back-End mit einer svn / git / etc-Schnittstelle anbieten. Daher ist das, wonach Sie fragen, im Grunde bereits vorhanden.

— Dimitrios Mistriotis
quelle

5

Ich würde sagen, das liegt daran, dass die primäre Datenstruktur eines Versionskontrollsystems eine DAG ist, die Datenbanken sehr schlecht zugeordnet ist. Ein Großteil der Daten ist auch inhaltsadressierbar, wodurch auch die Zuordnung zu Datenbanken sehr mangelhaft ist.

Die Integrität der Daten ist nicht die einzige Sorge eines VCS, sie sind auch mit Version betroffen Geschichte Integrität, die Datenbanken sind nicht sehr gut. Mit anderen Worten, wenn Sie eine Version abrufen, müssen Sie nicht nur sicherstellen, dass die Version keine aktuellen Fehler aufweist, sondern auch, dass nichts in ihrer gesamten Historie verstohlen geändert wurde.

VCS sind neben einem Enterprise-Produkt auch ein Consumer-Produkt. Die Leute benutzen sie in kleinen Ein-Mann-Hobbyprojekten. Wenn Sie den Aufwand für die Installation und Konfiguration eines Datenbankservers erhöhen, entfremden Sie einen Großteil dieses Teils des Marktes. Vermutlich sehen Sie zu Hause nicht viele Vault- und TFS-Installationen. Aus dem gleichen Grund verwenden Tabellenkalkulationen und Textverarbeitungsprogramme keine Datenbanken.

Auch dies ist eher ein Grund für DVCS, aber die Nichtverwendung einer Datenbank macht es extrem portabel. Ich kann meinen Quellbaum auf ein USB-Stick kopieren und auf jedem Computer wiederverwenden, ohne einen Datenbankserverprozess konfigurieren zu müssen.

Soweit bei Commits korrumpieren verwendet VCS exakt die gleichen Techniken wie Datenbanken gleichzeitigen Zugriff zu verhindern, machen Transaktionen Atom usw. Verderbtheiten beide in sehr selten sind, aber sie tun passieren . Für alle Absichten und Zwecke, ein VCS - Datenspeicher ist eine Datenbank.

— Karl Bielefeldt
quelle

1

"ordnet Datenbanken sehr schlecht zu" Doch Vault und TFS tun genau dies. "Datenintegrität ist nicht das einzige Anliegen eines VCS, sondern auch die Integrität des Versionsverlaufs, in der Datenbanken nicht besonders gut sind." Ich verstehe nicht, wie sich das Speichern des Versionsverlaufs in Dateien über eine Datenbank eignet, zumal ich Produkte benannt habe, die genau das tun. ". Korruptionen sind in beiden Fällen sehr selten, aber sie kommen vor." Keines dieser Ergebnisse auf der ersten Seite spricht von einer Beschädigung der Vault-Serverdatenbank. Der einzige Link, der sogar über die Vault-Software spricht, ist, dass das WC beschädigt wurde.

— Andy

"Ein VCS-Datenspeicher ist in jeder Hinsicht eine Datenbank." Nun ... das ist mein Punkt. Warum nicht einfach die Daten in ein reales Datenbanksystem stecken, anstatt Ihre eigenen zu rollen?

— Andy

2

@Andy Ja, es ist eine Datenbank, aber nicht alle Datenbanken können untereinander ausgetauscht werden. Jede Datenbank hat eine bestimmte Sicht auf die Welt (zum Beispiel implementieren SQL-DBs im Grunde das relationale Modell). Da diese Antwort detailliert ist, passen die Daten, die ein VCS speichert, und die Art und Weise, wie Daten verwendet werden, nicht zum relationalen Modell. Ich bin nicht sicher, ob einige NoSQL-Datenbanken besser abschneiden, aber sie sind eher neu und müssen ihre Überlegenheit erst noch beweisen (ich erinnere mich an Berichte über schwerwiegende Integritätsprobleme bei einigen). Und dann gibt es noch all die anderen Fragen.

DAGs werden nur in DVCS verwendet (es sei denn, Sie betrachten eine lineare Historie als eine außergewöhnlich einfache DAG, die es ist, aber das ist keine wirklich hilfreiche Abstraktion.) Wenn Ihre Historie linear ist und die Changesets monoton zunehmen, ist eine SQL-Datenbank viel sinnvoller .

— Edward Thomson

Monoton ansteigende Versionsnummern machen für VCSes wenig Sinn. Ich habe eine ganze Reihe von ihnen verwendet, und diejenigen mit zentralisierten Versionsnummern (CVS & SVN sind die 2, mit denen ich am meisten vertraut bin) sind in der Regel ein Problem beim Zusammenführen. Und selbst diese verwenden DAGs, wenn sie versuchen, eine Zusammenführung durchzuführen. Nur weil ihre Speicherdarstellung nicht darauf basiert, heißt das nicht, dass sie nicht verwendet wird.

— Mike Larsen

2

Besseres Disaster Recovery (Worst-Case-Szenario: Wir analysieren es wie in alten Zeiten per Auge)
Das Nachverfolgen und Debuggen solcher Katastrophen, die möglicherweise durch Fehler im VCS-System verursacht wurden, wird vereinfacht.
Verringerung der Anzahl der Abhängigkeiten. (Vergessen wir nicht, dass eines dieser Systeme den Kernel handhabt und das andere sollte)
Ein Texteditor ist immer verfügbar. (MS SQL Server Lizenzen ... nicht so sehr)

— ZJR
quelle

Diese Antwort ist einfach schlecht. Der einzig wahre Punkt ist die Verringerung der Anzahl der Abhängigkeiten. Beide Backing-Systeme sollten auf dem gleichen Niveau sein, wie Sie es bei richtigen Backups tun sollten. Das Debuggen von DB-Anwendungen ist nicht schwieriger als das Debuggen von Anwendungen, die Dateien schreiben, und der Texteditor ist immer verfügbar. Ich weiß nicht einmal, wozu Sie da sind, da das VCS selbst keinen Texteditor verwenden wird und es andere DB-Server gibt (Sqlite, Postgre, MySql usw.) Das Fehlen eines Datenbankservers in einer von db unterstützten Lösung sollte kein Faktor sein.

— Andy

1

@Andy ... die Programmierer werden einen Texteditor verwenden. Sie wissen, dass die Textbearbeitung auch in Ihrer bevorzugten IDE noch als sekundäre Funktion verfügbar ist.

— ZJR

1

@Andy sqliteist die einzig mögliche Alternative zu Textdateien, angesichts der Vielzahl von verteilten Szenarien, die modernes DVCS bietet. (idk, vielleicht haben Sie den "verteilten" Teil von DVCS verpasst) Alles andere wäre zu umständlich (Konfiguration + Firewall + Lizenz) oder sogar albern, um verteilt zu werden . Andererseits könnte es sich als schwierig erweisen, ein Worst-Case-Szenario postmortem auf einem SQLite zu erstellen.

— ZJR

1

@ZJR: Ich glaube nicht, dass die ursprüngliche Frage jemals die verteilte Versionskontrolle spezifiziert hat, sondern Versionskontrollsysteme im Allgemeinen. Außerdem ist Ihr Texteditor-Argument etwas flach, da viele Systeme nicht nur flache Textdateien speichern. Sogar git hat viele Binärdateiformate (lose Objekte, Packdateien usw.), die Ihren Texteditor unbrauchbar machen.

— Edward Thomson

@ZJR Wie ist das Bearbeiten von Code in einem Texteditor für den Sicherungsspeicher eines VCS relevant? Schlagen Sie vor, die Datenbank von SVN manuell zu bearbeiten? Auch meine Frage ist nicht auf DVCS beschränkt, so dass ich nicht weiß, warum Sie darauf harpen.

— Andy

2

Fossil ist ein hervorragendes verteiltes Versionskontrollsystem (Distributed Version Control System, DVCS) und verwendet SQLite zum Speichern, keine Nur-Text-Dateien.

Ich mag es wirklich, dass es integriert hat: Bug Tracking, Wiki und dass es wirklich verteilt ist. Ich meine, Sie können wirklich offline arbeiten und Fehler beheben.

Fossil verwendet Sqlite als Anwendungsdateiformat. In der Keynote bei PgCon erklärt Dr. Richard Hipp, welche Vorteile die Verwendung von sqlite als Anwendungsdateisystem hat, und macht ein ziemlich überzeugendes Argument für die Vorteile der Verwendung einer Datenbank als Dateisystem.

Das zweite Hauptthema war, dass SQLite als Anwendungsdateiformat angesehen werden sollte - eine Alternative zum Erfinden eigener Dateiformate oder zur Verwendung von ZIP-XMLs. Die Aussage „SQLite ist kein Ersatz für PostgreSQL. SQLite ist ein Ersatz für fopen () “-Nägel (Folie 21). Schließlich legte Richard großen Wert darauf, dass SQLite sich um Ihre Daten kümmert (crash safe, ACID) use-the-index.com

Jetzt hat Dr. Hipp die Bedenken zum Speichern von Code in einer Datenbank angesprochen

Warum basiert Fossil auf SQLite anstelle einer verteilten NoSQL-Datenbank?

Fossil basiert nicht auf SQLite. Die aktuelle Implementierung von Fossil verwendet SQLite als lokalen Speicher für den Inhalt der verteilten Datenbank und als Cache für Metainformationen über die verteilte Datenbank, die für eine schnelle und einfache Präsentation vorberechnet werden. Die Verwendung von SQLite in dieser Rolle ist jedoch ein Implementierungsdetail und für den Entwurf nicht grundlegend. Einige zukünftige Versionen von Fossil könnten SQLite abschaffen und anstelle von SQLite einen Stapel von Dateien oder eine Schlüssel- / Wertedatenbank einsetzen. (Eigentlich ist das sehr unwahrscheinlich, da SQLite in seiner aktuellen Rolle erstaunlich gut funktioniert, aber der Punkt ist, dass das Weglassen von SQLite aus Fossil eine theoretische Möglichkeit ist.)

— elviejo79
quelle