Es gibt viele Dateiversionskontrollsysteme. Welches ist besser? Was soll man wählen – GIT oder Subversion?
Jeder Entwickler steht früher oder später vor der Notwendigkeit, Änderungen in Softwareprojektdateien zu verfolgen und entscheidet sich für ein Versionskontrollsystem.
Versionskontrollsysteme werden nicht nur von Programmierern verwendet. Tatsächlich werden sie für jeden nützlich sein, der gerne noch einmal zurückgehen und weitere Rezensionen lesen möchte frühere Version Dokument oder Datei, die geändert wurde. Im Wesentlichen handelt es sich bei der beliebten Dropbox um ein Dateiversionskontrollsystem.
Versionsverlauf und Änderungsinformationen anzeigen
Alle Versionskontrollsysteme bieten Menüoptionen zur Unterscheidung der aktuellen Datei oder des aktuellen Projekts: Vergleichen Sie sie mit der neuesten im Repository gespeicherten Version und zeigen Sie die Unterschiede an. Zeigen Sie den Versionsverlauf einer Datei an, indem Sie Verlauf oder Datei auswählen. Normalerweise enthält die Protokollausgabe das Datum, die Commit-Nachricht und die Änderungs- oder Revisions-ID.
Auf Anmerkungsansichten kann durch Auswahl von „Anmerken“ oder „Schuld“ zugegriffen werden. Wenn Sie eine Anmerkung oder Schuld auswählen, werden die Zeilen der Datei angezeigt, an die die Änderungs-ID angehängt ist, aus der sie stammen. Dadurch können Sie durch den Verlauf einer Datei navigieren und frühere Versionen abrufen.
In diesem Artikel werde ich die Hauptunterschiede zwischen dem GIT-Versionskontrollsystem und dem konservativeren und vielen vertrauten Subversion auflisten.
GIT speichert eine vollständige Kopie des Repositorys lokal. Subversion führt einen Verlauf der Änderungen auf dem Server
IN Subversion-Repository auf dem Server gespeichert – nur die neuesten Versionen der Dateien werden auf dem Computer gespeichert. GIT speichert auf Ihrem Computer Vollversion die gesamte Geschichte der Veränderungen.
Alle unterstützten Versionskontrollsysteme unterstützen das Zurücksetzen Ihres Projekts in bekannte Zustände. Diese Funktionalität wird üblicherweise als Umkehrung bezeichnet. Änderungen, die verworfen werden, hängen vom Versionskontrollsystem ab. Das Versionskontrollsystem ersetzt möglicherweise die Menüoption „Rückgängig“ durch andere Optionen.
Sie können den Status auswählen, um den Status eines Projekts oder Repositorys anzuzeigen. Sie können „Aktualisieren“ auswählen, um den Arbeitsbaum zu aktualisieren Letzte Änderungen im Thread. Bei einigen Versionskontrollsystemen können Sie zwischen der Aktualisierung des aktuellen Projekts oder der Aktualisierung aller Projekte wählen.
Dieser Unterschied verändert grundlegend die Fähigkeit, mit Dokumenten zu arbeiten.
Sie benötigen keinen Zugriff auf den Server, um eine geänderte Datei in der Versionskontrolle zu speichern
Mit einem Versionskontrollsystem können Sie nur die darin gespeicherten Änderungen vergleichen und wiederherstellen. Subversion erfordert Netzwerkzugriff auf den Server, um eine geänderte Datei im Repository zu speichern (festzuschreiben). GIT kann jederzeit eine neue Version einer Datei speichern.
Sie können „Löschen“ auswählen, um veraltete Dateien aus dem Repository zu entfernen. Die derzeit enthaltenen Dokumentationsanhänge unterliegen dem Urheberrecht ihrer jeweiligen Eigentümer. Alle anderen Warenzeichen sind Eigentum ihrer Besitzer.
Wenn Dateien lokal vorhanden sind, wird GIT schneller
Wenn dies aus irgendeinem Grund nicht funktioniert, versuchen Sie es mit einer der anderen Optionen. Es gibt verschiedene Möglichkeiten, zum Projekt beizutragen. Fehlt etwas? Schlagen Sie es gerne vor! . Wenn Sie vorhaben, hier Code einzureichen, müssen Sie einige Dinge wissen.
Wenn Dateien lokal vorhanden sind, wird GIT schneller
Das stimmt – für die meisten Dinge, die Sie tun werden, ist GIT schneller, da alles lokal auf Ihrem Computer geschieht. Natürlich, wenn Sie Änderungen am Repository weiterleiten Remote-Server, das wird einige Zeit dauern. (Und ein Versionskontrollsystem nur auf Ihrem Computer zu belassen, ist nicht sehr klug – vor allem, wenn Sie es haben kostenloses Hosting für Versionskontrollsysteme). Das Übertragen neuer Dateiversionen sowie das Vergleichen und Anzeigen von Änderungen erfolgt jedoch fast sofort.
Ihr Name und Ihre Adresse Email werden in jedes neu erstellte Commit geschrieben. Daher sollten sie nicht so willkürlich und unseriös sein. Obwohl der erste Port nahezu beliebig gewählt werden kann, wird der zweite Port vom Repository-Server festgelegt. Bitte stellen Sie sicher, dass Sie einen Tunnel-Eingangsport verwenden, der nicht bereits von einem anderen Benutzer verwendet wird.
Bitte beachten Sie die Workaround-Möglichkeit, diese ist wichtig! . Diese Anleitung funktioniert! Versionskontrolle ist ein großes Thema, und dieser Leitfaden ist alles andere als umfassend – er soll ein Ausgangspunkt und ein Hinweis auf andere, tiefer gehende Ressourcen sein. Wir werden es aktualisieren, sobald es verfügbar ist. Beginnen wir vor diesem Hintergrund mit einigen Grundlagen.
GIT speichert „Nuggets“ von Dateien in komprimierter Form. Subversion speichert Änderungen in Dateien
Für den Anwender ist dies ein grundlegender Unterschied, da das erhaltene Ergebnis identisch ist.
GIT gewährleistet die Dateiintegrität
Für alle Dateien, die zur Versionskontrolle gespeichert werden, verwendet GIT den SHA1-Hash. In der Praxis wird dadurch die Möglichkeit ausgeschlossen, eine Datei zu ändern, ohne dass das Versionskontrollsystem dies bemerkt.
Zeigen Sie die Unterschiede zwischen zwei beliebigen Punkten im Projektverlauf an. Behalten Sie mehrere parallele Zweige des Projekts mit unterschiedlichen Änderungen bei.
- Was war die neueste stabile, bekannte Version?
- Welche Version wird auf der Hardware in diesem Bereich eingesetzt?
- Wann war, grob gesagt, die letzte Änderung.
- Speichern Sie den gesamten Projektverlauf in einem Verzeichnis.
- Verfolgen Sie, wie und wann sich einzelne Dateien geändert haben.
- Verfolgen Sie, wer sie geändert hat.
- Schreiben Sie für Menschen lesbare Beschreibungen der Änderungen auf.
- Änderungssätze verschiedener Personen zusammenführen.
Es ist sehr schwierig, mit GIT Daten zu verlieren
Da alle Änderungen tatsächlich auf Ihrem Computer gespeichert werden und alle Änderungen, die GIT tatsächlich nur zum Repository hinzufügt, ist es sehr schwierig, etwas zu verlieren. Wenn Sie die geänderte Datei im Repository gespeichert haben, können Sie sie jederzeit wiederherstellen aktuellen Zustand. Und wenn Sie das Repository mit dem Befehl git push auf einem Remote-Server gespeichert haben, geht die Wahrscheinlichkeit, die Datei zu verlieren, gegen Null.
Machen Sie sich darüber keine allzu großen Sorgen. Es bleibt jedoch ein äußerst einschränkender Nachteil bestehen: Es erfordert einen zentralen Server, um Änderungen zu speichern und sie mit anderen zu teilen. Es funktioniert wie eine Nabe und Speichen. Und da jede Kopie des Projekts ein erstklassiger Bürger mit der gesamten Projekthistorie ist, ist es nicht einmal notwendig, eine zentrale Kopie des Projekts zu haben.
Wenn es aus hergestellt ist Textdateien, das ist wahrscheinlich nützlich, um es in Git zu behalten. Es scheitert sowohl als Referenz als auch als Tutorial. Es ist in einem wortreichen, beispielorientierten Stil geschrieben, was seinen Nutzen als Referenz beeinträchtigt; und die Autoren des lächerlichen Tempos zerstören es wie ein Lehrbuch. Die darin behandelten allgemeinen Themen werden in der Regel sehr, sehr schnell behandelt und dienen eher als Vorgeschmack auf eine umfassendere Berichterstattung später im Buch. Das sind die grundlegenden Dinge, Jungs: Decken Sie zuerst die High-Level-Schnittstelle ab, schließen Sie dann die Befehle und interne Teams niedriges Niveau.
Ehrlich gesagt hat mir GIT wirklich gut gefallen. Durch die Verwendung dieses Systems werden einige Einschränkungen beseitigt, die mit Subversion nur schwer zu implementieren sind. Beispielsweise ist die Speicherung eines Repositorys auf verschiedenen Servern möglich, aber schwierig zu implementieren, und in GIT gehört dies zur Standardfunktionalität. Andererseits kann die Verwendung von Subverison in manchen Situationen einfacher sein. Und jedes Versionskontrollsystem ist eine ganz erhebliche Verbesserung gegenüber keinem Versionskontrollsystem.
Dieses Bild zieht sich durch das ganze Buch. Die Tag-Abdeckung ist überraschend schlecht. Und die späteren Kapitel über fortgeschrittene Manipulationen sowie Tipps und Tricks sind gut. Ich bin mit anderen Rezensenten einer Meinung, dass dieses Buch als Nachschlagewerk oder als Lehrbuch übersehen wird. In Kapitel 6 geht es beispielsweise ausführlich darum, wie das Commit-Diagramm die Verzweigungen und Zusammenführungen widerspiegelt, die im Repository stattgefunden haben, und wie Sie Commits für bestimmte Branches referenzieren können. Verzweigungen und Zusammenführungen werden jedoch erst in den Kapiteln sieben bzw. 9 besprochen.
Bei der Erörterung von Tags beschreibt der Autor, wie man ein Tag erstellt und nach einem Tag sucht, zeigt jedoch nie, wie einfach es ist, eine einfache Liste der zuvor erstellten Tags zu erhalten. Nicht sehr zufrieden mit diesem Buch. Er verbringt weniger als 15 Seiten damit, einen grundlegenden Anwendungsfall darzustellen und geht dann auf die Kernkonzepte ein. Einführendes Material finden Sie an anderer Stelle. Es gab drei Generationen Software zur Versionskontrolle. Die erste Generation war sehr einfach. Die Entwickler arbeiteten auf einem physischen System und „überprüften“ jeweils eine Datei.
VCS-Grundlagen
Einführung
Bevor Sie über ein bestimmtes Versionskontrollsystem sprechen, müssen Sie verstehen, was es ist, was es ist und warum es überhaupt aufgetaucht ist. Dieser Vortrag soll eine erste Einführung in die Versionskontrolle und Versionskontrollsysteme geben. Zunächst werde ich über die Ursprünge von Versionskontrolltools sprechen, welche Versionskontrollsysteme derzeit beliebt sind und worin die wesentlichen Unterschiede zwischen ihnen bestehen.
Diese Generation von Versionskontrollsoftware verwendete eine Technik namens Dateisperre. Als der Entwickler die Datei auscheckte, war sie gesperrt und kein anderer Entwickler konnte die Datei bearbeiten. veranschaulicht das Konzept dieser Art der Versionskontrolle.
Hauptsächlich lokale Operationen
Versionskontrollsoftware der ersten Generation. Beispiele für Versionskontrollsoftware der ersten Generation sind ein Versionskontrollsystem und ein Verwaltungssystem Quellcode. Zu den Problemen mit der ersten Generation gehörten die folgenden.
Über Versionskontrolle
Was ist Versionskontrolle und warum benötigen Sie sie?
Es lohnt sich wahrscheinlich, mit der Definition eines Versionskontrollsystems (VCS) zu beginnen – dabei handelt es sich um ein System, das Änderungen in einer oder mehreren Dateien aufzeichnet, sodass in Zukunft auf bestimmte alte Versionen dieser Dateien zurückgegriffen werden kann.
IN In letzter Zeit Dateien sind das Endergebnis vieler Berufe (z. B. Schreiben, wissenschaftliches Arbeiten und natürlich Softwareentwicklung). Es wird viel Zeit und Mühe in die Entwicklung und Pflege dieser Dateien investiert, und niemand möchte noch mehr Zeit und Mühe in die Wiederherstellung von Daten investieren, die aufgrund von Änderungen verloren gegangen sind.
Warum werden verteilte Systeme benötigt?
Entwickler müssen sich direkt bei dem System anmelden, das die Versionskontrollsoftware enthält.
- Es kann immer nur ein Entwickler gleichzeitig arbeiten.
- Dies führt zu einem Engpass im Entwicklungsprozess.
Stellen wir uns vor, dass ein Programmierer ein Projekt entwickelt, das aus einer kleinen Datei besteht (das Beispiel ist übrigens ganz real, nicht synthetisch und wurde im wirklichen Leben gefunden). Nach der Veröffentlichung der ersten Version des Projekts steht er vor einer schwierigen Entscheidung: Es gilt, die von Benutzern der ersten Version gemeldeten Probleme zu beheben und gleichzeitig etwas Neues für die zweite Version zu entwickeln. Selbst wenn Sie nur auftretende Probleme beheben müssen, besteht eine hohe Wahrscheinlichkeit, dass das Projekt nach einer Änderung nicht mehr funktioniert, und Sie müssen ermitteln, was geändert wurde, um das Problem leichter lokalisieren zu können. Es ist außerdem ratsam, eine Art Protokoll über die vorgenommenen Änderungen und Korrekturen zu führen, um die gleiche Arbeit nicht mehrmals durchzuführen.
GIT speichert „Nuggets“ von Dateien in komprimierter Form. Subversion speichert Änderungen in Dateien
Versionskontrollsoftware der zweiten Generation. Wenn zwei Entwickler dieselbe Version einer Datei überprüfen, besteht die Möglichkeit, dass Probleme auftreten. Dies wird durch einen Prozess namens Zusammenführen erledigt. Nachdem Bob seine Arbeit beendet hat, überprüft er die Datei erneut.
Git von der Quelle installieren
Typischerweise führt dies dazu neue Version Datei, Version. Nach einer Weile überprüft Sue ihre Akte. Diese neue Datei sollte Bobs Änderungen und Modifikationen enthalten. Dies wird durch einen Zusammenführungsprozess erreicht. Abhängig von der Versionskontrollsoftware, die Sie verwenden, kann dies der Fall sein verschiedene Wege Verarbeitung dieser Zusammenführung. In manchen Fällen, beispielsweise wenn Bob und Sue an völlig unterschiedlichen Teilen einer Datei arbeiteten, ist der Zusammenführungsprozess sehr einfach. In Fällen, in denen Sue und Bob jedoch an denselben Codezeilen in einer Datei arbeiteten, kann der Zusammenführungsprozess komplexer sein.
Im einfachsten Fall kann das obige Problem dadurch gelöst werden, dass mehrere Kopien der Dateien gespeichert werden, beispielsweise eine für die Behebung von Fehlern in der ersten Version des Projekts und eine zweite für neue Änderungen. Da die Änderungen im Vergleich zur Dateigröße normalerweise nicht sehr groß sind, ist es möglich, nur die geänderten Zeilen mit dem Diff-Dienstprogramm zu speichern und sie später mit dem Patch-Dienstprogramm zusammenzuführen. Was aber, wenn das Projekt aus mehreren tausend Dateien besteht und hundert Personen daran arbeiten? Wenn Sie in diesem Fall die Methode verwenden, separate Kopien von Dateien (oder auch nur Änderungen) zu speichern, gerät das Projekt sehr schnell ins Stocken. In den folgenden Vorlesungen werde ich als Beispiele Programmquellcodes verwenden, aber tatsächlich kann fast jede Art von Datei unter Versionskontrolle gestellt werden.
In diesen Fällen muss Sue Entscheidungen treffen, beispielsweise ob Bobs Code oder ihr Code in der neuen Version der Datei enthalten sein wird. Sobald der Zusammenführungsprozess abgeschlossen ist, erfolgt die Übertragung der Datei in das Repository. Eine Datei festzuschreiben bedeutet im Wesentlichen, eine neue Version im Repository zu erstellen; in diesem Fall Version 7 der Datei.
Über Versionskontrolle
Die dritte Generation wird als verteilte Versionskontrollsysteme bezeichnet. Wie in der zweiten Generation enthält der zentrale Repository-Server alle Dateien für das Projekt. Allerdings prüfen Entwickler nicht einzelne Dateien aus dem Repository. Stattdessen wird das gesamte Projekt überprüft, sodass der Entwickler damit arbeiten kann vollständiger Satz Dateien, nicht nur einzelne Dateien. veranschaulicht das Konzept dieser Art der Versionskontrolle.
Wenn Sie Grafik- oder Webdesigner sind und jede Version eines Bildes oder Layouts speichern möchten – was Sie wahrscheinlich auch tun würden –, dann ist die Verwendung eines Versionskontrollsystems eine sehr kluge Entscheidung. VCS ermöglicht es, einzelne Dateien in ihre vorherige Form zurückzusetzen, das gesamte Projekt in seinen vorherigen Zustand zurückzusetzen, Änderungen anzuzeigen, die im Laufe der Zeit aufgetreten sind, festzustellen, wer als letzter Änderungen an einem Modul vorgenommen hat, das plötzlich nicht mehr funktionierte, und wer und wann etwas eingeführt hat von Fehlern im Code und vieles mehr. Wenn Sie bei der Verwendung von VCS alles ruinieren oder Dateien verlieren, kann im Allgemeinen alles problemlos wiederhergestellt werden. Außerdem ist der Overhead für alles, was Sie erhalten, sehr gering.
Verzweigung von Entwicklungsprozessen
Versionskontrollsoftware der dritten Generation. Ein weiterer Unterschied zwischen Versionskontrollsoftware der zweiten und dritten Generation hängt mit der Funktionsweise des Merge- und Commit-Prozesses zusammen. Wie bereits erwähnt, bestehen die Schritte der zweiten Generation darin, eine Zusammenführung durchzuführen und dann die neue Version im Repository festzuschreiben.
Am häufigsten werden Daten hinzugefügt
Mit Versionskontrollsoftware der dritten Generation werden Dateien überprüft und dann zusammengeführt. Um den Unterschied zwischen diesen beiden Methoden zu verstehen, werfen Sie zunächst einen Blick auf. Zweite Generation von Merge und Commit. Im ersten Schritt prüfen zwei Entwickler die Datei anhand der dritten Version. In Phase 2 überprüft ein Entwickler diese Datei, was zu Version 4 der Datei führt.
Lokale Versionskontrollsysteme
Wie bereits erwähnt, ist ein Beispiel für ein lokales VCS äußerst einfach: Viele Leute ziehen es vor, Versionen zu kontrollieren, indem sie Dateien einfach in ein anderes Verzeichnis kopieren (in der Regel fügen sie dem Verzeichnisnamen das aktuelle Datum hinzu). Dieser Ansatz ist sehr verbreitet, weil er einfach ist, scheitert aber auch häufiger. Man vergisst sehr leicht, dass man sich im falschen Verzeichnis befindet und ändert versehentlich die falsche Datei oder kopiert Dateien an den falschen Ort und überschreibt die benötigten Dateien. Um dieses Problem zu lösen, haben Programmierer seit langem ein lokales VCS mit einer einfachen Datenbank entwickelt, die alle Änderungen an den erforderlichen Dateien speichert
In Phase 3 muss der zweite Entwickler zunächst die Änderungen seiner ausgecheckten Kopie mit den Änderungen der Version 4 zusammenführen. Sobald die Zusammenführung abgeschlossen ist, kann die neue Version als Version mit dem Repository verknüpft werden. Wenn Sie sich auf den Inhalt des Repositorys konzentrieren, werden Sie feststellen, dass die Entwicklung sehr geradlinig verläuft. Dieser einfache Ansatz zur Softwareentwicklung führt zu einigen potenziellen Problemen.
Wenn vom Entwickler ein Commit vor dem Commit verlangt wird, führt dies oft dazu, dass Entwickler zögern, ihre Änderungen regelmäßig zu committen. Der Zusammenführungsprozess kann mühsam sein, und Entwickler entscheiden sich möglicherweise dafür, länger zu warten und eine Zusammenführung statt einer Reihe regulärer Zusammenführungen durchzuführen. Dies wirkt sich negativ auf die Softwareentwicklung aus, da der Datei plötzlich große Codeblöcke hinzugefügt werden. Darüber hinaus möchten Sie, dass Entwickler Änderungen am Repository vorschlagen, genau wie Sie jemanden möchten, der regelmäßig ein Sicherungsdokument schreibt. Ganz wichtig: Version 5 in diesem Beispiel ist nicht unbedingt die Arbeit, die der Entwickler ursprünglich abgeschlossen hat. Während des Zusammenführungsprozesses kann es sein, dass der Entwickler einen Teil seiner Arbeit aufgibt, um den Zusammenführungsprozess abzuschließen. Dies ist nicht ideal, da dadurch potenziell guter Code verschwendet wird. Es kann eine bessere, wenn auch möglicherweise komplexere Methode verwendet werden.
Eines der beliebtesten VCS dieser Art ist RCS (Revision Control System), das immer noch auf vielen Computern installiert ist. Auch in der Moderne Betriebssystem Das Mac OS X-RCS-Dienstprogramm wird mit den Entwicklertools installiert. RCS wurde in den frühen 1980er Jahren von Walter F. Tichy entwickelt. Das System ermöglicht es Ihnen, Versionen nur einer Datei zu speichern, sodass Sie mehrere Dateien manuell verwalten müssen. Für jede vom System gesteuerte Datei werden Versionsinformationen in einer speziellen Datei mit dem Namen der Originaldatei gespeichert, an der am Ende die Zeichen „,v“ angehängt werden. Beispielsweise werden für die Datei file.txt die Versionen in der Datei file.txt,v gespeichert. Dieses Dienstprogramm basiert auf der Arbeit mit Patchsätzen zwischen Versionspaaren (ein Patch ist eine Datei, die den Unterschied zwischen den Dateien beschreibt). Dadurch können Sie jede Datei zu jedem Zeitpunkt neu erstellen und Patches nacheinander anwenden. Das System verwendet das Diff-Dienstprogramm zum Speichern von Versionen. Obwohl RCS den Anforderungen entspricht Mindestanforderungen gegenüber dem Versionskontrollsystem weist es folgende Hauptnachteile auf, die auch als Anreiz zur Schaffung des folgenden betrachteten Systems dienten:
- Arbeiten Sie mit nur einer Datei, jede Datei muss separat gesteuert werden;
- Ein umständlicher Mechanismus, wenn mehrere Benutzer gleichzeitig mit dem System arbeiten möchten. Der Speicher wird einfach blockiert, bis der Benutzer, der ihn blockiert hat, ihn entsperrt.
- Niemand befreit Sie von Backups; Sie riskieren, alles zu verlieren.
Zentralisierte Versionskontrollsysteme
Die nächste große Herausforderung war die Notwendigkeit, mit Entwicklern auf anderen Computern zusammenzuarbeiten. Um dieses Problem zu lösen, wurden zentralisierte Versionskontrollsysteme (CVCS) erstellt. Solche Systeme wie CVS, Subversion und Perforce verfügen über einen zentralen Server, der alle Dateien unter Versionskontrolle speichert, und über eine Reihe von Clients, die von ihm Kopien der Dateien erhalten. Dies ist seit vielen Jahren der Standard für Versionskontrollsysteme.
Dieser Ansatz hat viele Vorteile, insbesondere gegenüber lokalem SLE. So weiß beispielsweise jeder, wer was im Projekt macht. Administratoren haben klare Kontrolle darüber, wer was tun kann, und natürlich ist CSKB viel einfacher zu verwalten als lokale Datenbanken auf jedem Client. Dieser Ansatz weist jedoch mehrere gravierende Nachteile auf. Am offensichtlichsten ist, dass der zentralisierte Server die Schwachstelle des gesamten Systems darstellt. Wenn der Server eine Stunde lang ausfällt, können Entwickler eine Stunde lang nicht interagieren und niemand kann eine neue Version ihrer Arbeit speichern. Wenn die Festplatte mit der zentralen Datenbank beschädigt ist und keine vorhanden ist Sicherheitskopie, verlieren Sie absolut alles – den gesamten Verlauf des Projekts, mit der möglichen Ausnahme mehrerer Arbeitsversionen, die auf den Arbeitsmaschinen der Benutzer gespeichert sind.
CVS
CVS (Concurrent Versions System) ist immer noch das am weitesten verbreitete System, verliert jedoch aufgrund von Mängeln, auf die ich weiter unten eingehen werde, schnell an Popularität. Dick Grune entwickelte CVS Mitte der 1980er Jahre. Um einzelne Dateien zu speichern, verwendet CVS (wie auch RCS) Dateien im RCS-Format, ermöglicht Ihnen jedoch die Verwaltung von Dateigruppen, die sich in Verzeichnissen befinden. CVS verwendet außerdem eine Client-Server-Architektur, bei der alle Versionsinformationen auf dem Server gespeichert werden. Durch die Verwendung einer Client-Server-Architektur kann CVS auch von geografisch verteilten Benutzerteams verwendet werden, wobei jeder Benutzer über ein eigenes Arbeitsverzeichnis mit einer Kopie des Projekts verfügt. Wie der Name schon sagt, können Benutzer das System teilen.
Mögliche Konflikte beim Ändern derselben Datei werden dadurch gelöst, dass das System Änderungen nur an den meisten zulässt letzte Version Datei. Daher wird immer empfohlen, Ihre Arbeitskopie der Dateien zu aktualisieren, bevor Sie Ihre Änderungen hochladen, falls möglicherweise widersprüchliche Änderungen auftreten. Bei der Aktualisierung nimmt das System automatisch Änderungen an der Arbeitskopie vor und nur bei widersprüchlichen Änderungen an einem der Dateispeicherorte ist eine manuelle Korrektur des Konfliktspeicherorts erforderlich.
Mit CVS können Sie mithilfe von Entwicklungszweigen auch mehrere Entwicklungslinien für ein Projekt verwalten. So können Sie, wie oben erwähnt, Fehler in der ersten Version des Projekts korrigieren und gleichzeitig neue Funktionalitäten entwickeln.
CVS wurde von einer Vielzahl von Projekten verwendet, war aber natürlich nicht ohne Mängel, die später zum Erscheinen des nächsten in Betracht gezogenen Systems führten. Schauen wir uns die Hauptnachteile an:
- Da Versionen in RCS-Dateien gespeichert werden, ist es nicht möglich, Verzeichnisversionen zu speichern. Standardmethode Um dieses Hindernis zu umgehen, müssen Sie eine Datei (z. B. README.txt) in einem Verzeichnis speichern.
- Das Verschieben oder Umbenennen von Dateien unterliegt nicht der Versionskontrolle. Die Standardmethode hierzu besteht darin, zunächst die Datei zu kopieren, die alte mit dem Befehl „cvs remove“ zu entfernen und sie dann mit dem Befehl „cvs add“ unter ihrem neuen Namen hinzuzufügen.
Subversion
Subversion (SVN) wurde im Jahr 2000 auf Initiative von CollabNet entwickelt. SVN wurde ursprünglich als „besseres CVS“ entwickelt und das Hauptziel der Entwickler bestand darin, im CVS-Design gemachte Fehler zu korrigieren und gleichzeitig eine ähnliche Schnittstelle beizubehalten. SVN verwendet wie CVS eine Client-Server-Architektur. Zu den bedeutendsten Änderungen im Vergleich zu CVS gehören:
- Atomare Änderungen (Commit). Wenn die Commit-Verarbeitung unterbrochen wird, werden keine Änderungen vorgenommen.
- Beim Umbenennen, Kopieren und Verschieben von Dateien bleibt der gesamte Änderungsverlauf erhalten.
- Verzeichnisse, symbolische Links und Metadaten unterliegen der Versionskontrolle.
- Effiziente Änderungsspeicherung für Binärdateien.
Verteilte Versionskontrollsysteme
Und in dieser Situation kommen verteilte Versionskontrollsysteme (DVCS) ins Spiel. In Systemen wie Git, Mercurial, Bazaar oder Darcs checken Clients nicht einfach die neuesten Versionen von Dateien aus, sondern kopieren das gesamte Repository. Daher kann für den Fall, dass der Server, über den die Arbeit lief, „stirbt“, jedes Client-Repository zurück auf den Server kopiert werden, um die Datenbank wiederherzustellen. Jedes Mal, wenn ein Kunde eine neue Version von Dateien in die Hand nimmt, erstellt er diese für sich selbst vollständige Kopie alle Daten.
Darüber hinaus ermöglichen Ihnen die meisten dieser Systeme die Arbeit mit mehreren Remote-Repositorys, sodass Sie gleichzeitig auf unterschiedliche Weise damit arbeiten können verschiedene Gruppen Personen innerhalb eines Projekts. So können Sie in einem Projekt mehrere Arten von Arbeitsabläufen gleichzeitig durchführen, was in zentralisierten Systemen nicht möglich ist.
Warum werden verteilte Systeme benötigt?
Wie der Name schon sagt, ist eine der Hauptideen verteilter Systeme das Fehlen eines klar definierten zentralen Versionsspeichers – eines Repositorys. Bei verteilten Systemen kann eine Reihe von Versionen ganz oder teilweise auf verschiedene Repositories, auch Remote-Repositories, verteilt werden. Dieses Modell passt perfekt in die Arbeit verteilter Teams, beispielsweise eines über die ganze Welt verteilten Entwicklerteams, das an demselben Open-Source-Projekt arbeitet. Der Entwickler eines solchen Teams kann alle Versionsinformationen herunterladen und dann nur auf dem lokalen Rechner arbeiten. Sobald das Ergebnis eines der Arbeitsschritte erreicht ist, können die Änderungen in eines der zentralen Repositories hochgeladen oder zur Ansicht auf der Website des Entwicklers oder in veröffentlicht werden Mailingliste. Andere Projektteilnehmer wiederum können ihre Kopie des Versions-Repositorys mit neuen Änderungen aktualisieren oder die veröffentlichten Änderungen in einem separaten Testentwicklungszweig ausprobieren. Ohne eine gute Projektorganisation kann das Fehlen eines zentralen Repositorys leider ein Nachteil verteilter Systeme sein. Wenn es bei zentralisierten Systemen immer ein gemeinsames Repository gibt, aus dem Sie die neueste Version des Projekts beziehen können, müssen Sie bei verteilten Systemen organisatorisch entscheiden, welcher der Projektzweige der Hauptzweig sein soll. Warum sollte ein verteiltes Versionskontrollsystem für jemanden interessant sein, der bereits ein zentralisiertes System – wie Subversion – verwendet? Bei jeder Arbeit müssen Entscheidungen getroffen werden, und in den meisten Fällen ist es notwendig, verschiedene Optionen auszuprobieren: Wenn Sie mit Versionskontrollsystemen arbeiten, sollten Sie diese in Betracht ziehen Verschiedene Optionen und die Arbeit an großen Veränderungen sind Entwicklungszweige. Obwohl dies ein recht natürliches Konzept ist, ist es in Subversion nicht einfach anzuwenden. Darüber hinaus wird alles bei mehreren aufeinanderfolgenden Zusammenführungen von einem Zweig zum anderen komplizierter – in diesem Fall müssen Sie die Anfangs- und Endversionen jeder Änderung genau angeben, um Konflikte und Fehler zu vermeiden. Für verteilte Versionskontrollsysteme sind Entwicklungszweige eines der grundlegenden Konzepte – in den meisten Fällen ist jede Kopie eines Versionsspeichers ein Entwicklungszweig. Daher ist der Mechanismus zum Zusammenführen von Änderungen von einem Zweig zum anderen bei verteilten Systemen einer der Hauptmechanismen, der es Benutzern ermöglicht, bei der Verwendung des Systems weniger Aufwand zu betreiben.
Kurze Beschreibung beliebter verteilter SUVs
- Git ist ein verteiltes Versionskontrollsystem, das von Linus Torvalds entwickelt wurde. Ursprünglich war Git für den Einsatz im Linux-Kernel-Entwicklungsprozess gedacht, später wurde es jedoch auch in vielen anderen Projekten eingesetzt, wie zum Beispiel X.org und Ruby on Rails, Drupal. An dieser Moment Git ist das schnellste verteilte System mit dem kleinsten Revisionsspeicher. Gleichzeitig kann die Git-Schnittstelle für Benutzer, die beispielsweise von Subversion migrieren, kompliziert erscheinen.
- Mercurial ist ein geschriebenes verteiltes System Python-Sprache mit mehreren Erweiterungen in C. Zu den Projekten, die Mercurial verwenden, gehören Mozilla und MoinMoin.
- Bazaar ist ein von Canonical entwickeltes System, das für seine bekannt ist Ubuntu-Distribution und die Website https://launchpad.net/. Das System ist hauptsächlich in Python geschrieben und wird von Projekten wie MySQL verwendet.
- Codeville ist ein in Python geschriebenes verteiltes System, das einen innovativen Algorithmus zum Zusammenführen von Änderungen (Merge) verwendet. Das System wird beispielsweise bei der Entwicklung des ursprünglichen BitTorrent-Clients verwendet.
- Darcs ist ein in Haskell geschriebenes verteiltes Versionskontrollsystem, das beispielsweise vom Buildbot-Projekt verwendet wird.
- Monotone ist ein in C++ geschriebenes System, das SQLite als Revisionsspeicher verwendet.
