svn - market - version control system comparison




Was sind die relativen Stärken und Schwächen von Git, Mercurial und Bazaar? (11)

Was sehen die Leute hier als die relativen Stärken und Schwächen von Git, Mercurial und Bazaar?

Git- Stärke ist meiner Meinung nach ein sauberes Design und sehr viele Features. Ich denke auch, dass es die beste Unterstützung für Multi-Branch-Repositories und die Verwaltung verzweigungsintensiver Workflows ist. Es ist sehr schnell und hat eine kleine Repository-Größe.

Es hat einige Funktionen, die nützlich sind, aber einige Mühe brauchen, um sie zu verwenden. Dazu gehören die sichtbare Zwischenstufe ara (Index) zwischen Arbeitsbereich und Repository-Datenbank, die eine bessere Zusammenführungsauflösung in komplizierteren Fällen, inkrementelles Commit und Commit mit Dirty Tree ermöglicht. Erkennen von Umbenennungen und Kopien unter Verwendung der Ähnlichkeitsheuristik, anstatt sie unter Verwendung irgendeiner Art von Datei-IDs zu verfolgen, was gut funktioniert und die Schuldzuweisungen (Anmerkungen) erlaubt, die der Code-Bewegung über Dateien und nicht nur Umbenennungen folgen können.

Einer der Nachteile ist, dass der MS Windows-Support hinterherhinkt und nicht voll ist. Ein weiterer wahrgenommener Nachteil ist, dass es nicht so gut dokumentiert ist wie zum Beispiel Mercurial und weniger benutzerfreundlich als der Wettbewerb ist, aber es ändert sich.

Meiner Meinung nach liegt Mercurials Stärke in der guten Performance und der kleinen Repository-Größe, in der guten MS Windows Unterstützung.

Der Hauptnachteil ist meines Erachtens die Tatsache, dass lokale Zweigstellen (mehrere Zweigstellen in einem einzigen Projektarchiv) immer noch Bürger zweiter Klasse sind und auf seltsame und komplizierte Weise Tags implementiert. Auch die Art und Weise, wie es mit Umbenennungen umgeht, war suboptimal (aber diese Migration hat sich geändert). Mercurial unterstützt keine Octopus-Merges (mit mehr als zwei Eltern).

Von dem, was ich gehört und gelesen habe, sind die Hauptvorteile von Bazaar die einfache Unterstützung des zentralisierten Arbeitsablaufs (was auch ein Nachteil ist, wenn zentralisierte Konzepte dort sichtbar sind, wo es nicht sollte), das Verfolgen von Umbenennungen von Dateien und Verzeichnissen.

Der Hauptnachteil ist die Performance und die Repository-Größe für große Repositories mit langer nichtlinearer Historie (die Performance verbessert zumindest für nicht zu große Repositories), die Tatsache, dass das Standardparadigma eine Ranch pro Repository ist (Sie können es jedoch einrichten, um Daten zu teilen) und zentralisierte Konzepte (aber auch das, was ich gehört habe, ändert sich).

Git wird in C, Shell-Skripten und Perl geschrieben und ist skriptfähig; Mercurial ist in C (Kern, für Leistung) und Python geschrieben und bietet API für Erweiterungen; Bazaar ist in Python geschrieben und bietet API für Erweiterungen.

Wenn Sie beide miteinander und gegen Versionskontrollsysteme wie SVN und Perforce abwägen, welche Probleme sollten berücksichtigt werden?

Versionskontrollsysteme wie Subversion (SVN), Perforce oder ClearCase sind zentralisierte Versionskontrollsysteme. Git, Mercurial, Bazaar (und auch Darcs, Monotone und BitKeeper) sind verteilte Versionskontrollsysteme. Verteilte Versionskontrollsysteme ermöglichen eine viel größere Auswahl an Arbeitsabläufen. Sie erlauben es, "publish when ready" zu verwenden. Sie unterstützen Branching und Merging sowie branchenübergreifende Workflows besser. Sie müssen Personen mit Commit-Zugriff nicht vertrauen, um auf einfache Weise Beiträge von ihnen erhalten zu können.

Welche Faktoren würden Sie bei der Planung einer Migration von SVN zu einem dieser verteilten Versionskontrollsysteme berücksichtigen?

Einer der Faktoren, die Sie in Betracht ziehen sollten, ist die Unterstützung für das Inaktivieren mit SVN. Git hat git-svn, Bazaar hat bzr-svn und Mercurial hat hgsubversion.

Haftungsausschluss: Ich bin Git Benutzer und kleine Zeit Mitarbeiter, und git Mailing-Liste zu beobachten (und daran teilnehmen). Ich kenne Mercurial und Bazaar nur aus ihrer Dokumentation, verschiedenen Diskussionen über IRC und Mailinglisten sowie Blogposts und Artikeln zum Vergleich verschiedener Versionskontrollsysteme (von denen einige auf der GitComparison Seite auf Git Wiki aufgelistet sind).

Was sehen die Leute hier als die relativen Stärken und Schwächen von Git, Mercurial und Bazaar?

Wenn Sie beide miteinander und gegen Versionskontrollsysteme wie SVN und Perforce abwägen, welche Probleme sollten berücksichtigt werden?

Welche Faktoren würden Sie bei der Planung einer Migration von SVN zu einem dieser verteilten Versionskontrollsysteme berücksichtigen?


Was sehen die Leute hier als die relativen Stärken und Schwächen von Git, Mercurial und Bazaar?

Dies ist eine sehr offene Frage, die an Flammenköder grenzt.

Git ist am schnellsten, aber alle drei sind schnell genug. Bazaar ist am flexibelsten (es hat transparente Lese-Schreib-Unterstützung für SVN-Repositories) und kümmert sich sehr um die Benutzererfahrung. Mercurial ist irgendwo in der Mitte.

Alle drei Systeme haben viele Fanboys. Ich bin persönlich ein Bazaar-Fanboy.

Wenn Sie beide miteinander und gegen Versionskontrollsysteme wie SVN und Perforce abwägen, welche Probleme sollten berücksichtigt werden?

Die ersteren sind verteilte Systeme. Letztere sind zentralisierte Systeme. Darüber hinaus ist Perforce proprietär, während alle anderen wie in der Rede frei sind .

Zentralisiert oder dezentralisiert ist eine viel wichtigere Wahl als jedes der Systeme, die Sie in seiner Kategorie erwähnt haben.

Welche Faktoren würden Sie bei der Planung einer Migration von SVN zu einem dieser verteilten Versionskontrollsysteme berücksichtigen?

Zunächst fehlte ein guter Ersatz für TortoiseSVN. Obwohl Bazaar an ihrer eigenen Tortoise-Variante arbeitet, ist sie seit September 2008 noch nicht da.

Dann wird das Training der Schlüsselpersonen hinsichtlich der Verwendung eines dezentralisierten Systems ihre Arbeit beeinflussen.

Schließlich, Integration mit dem Rest des Systems, wie Problem Tracker, das nächtliche Build-System, das automatisierte Testsystem, etc.


Dies ist eine große Frage, die sehr vom Kontext abhängt, der viel Zeit für das Eintippen in eines dieser kleinen Textfelder benötigt. Auch erscheinen alle drei im Wesentlichen ähnlich, wenn sie für die üblichen Dinge verwendet werden, die die meisten Programmierer tun, so dass selbst das Verständnis der Unterschiede ein ziemlich esoterisches Wissen erfordert.

Sie werden wahrscheinlich viel bessere Antworten erhalten, wenn Sie Ihre Analyse dieser Tools bis zu dem Punkt unterbrechen können, an dem Sie spezifischere Fragen haben.


Eine sehr wichtige fehlende Sache im Basar ist cp. Sie können nicht mehrere Dateien mit dem gleichen Verlauf haben, wie Sie in SVN haben, siehe here und here . Wenn Sie nicht vorhaben, cp zu verwenden, ist bzr ein großartiger (und sehr einfach zu benutzender) Ersatz für svn.


Git ist sehr schnell, skaliert sehr gut und ist sehr transparent hinsichtlich seiner Konzepte. Der Nachteil ist, dass es eine relativ steile Lernkurve hat. Ein Win32-Port ist verfügbar, aber nicht wirklich ein erstklassiger Bürger. Git macht Hashes als Versionsnummern für Benutzer verfügbar. Dies bietet Garantien (insofern als ein einzelner Hash immer auf den gleichen Inhalt verweist; ein Angreifer kann den Verlauf nicht ändern, ohne entdeckt zu werden), kann jedoch für den Benutzer umständlich sein. Git hat ein einzigartiges Konzept zum Verfolgen von Dateiinhalten, selbst wenn diese Inhalte sich zwischen Dateien bewegen und Dateien als Objekte der ersten Ebene anzeigen, aber Verzeichnisse nicht verfolgen. Ein weiteres Problem mit git ist, dass es viele Operationen (wie Rebase ) gibt, die es einfach machen, den Verlauf zu ändern (in gewisser Weise - der Inhalt, auf den sich ein Hash bezieht, wird sich niemals ändern, aber Verweise auf diesen Hash können verloren gehen); einige Puristen (mich eingeschlossen) mögen das nicht sehr.

Bazaar ist ziemlich schnell (sehr schnell für Bäume mit geringer Historie, skaliert aber momentan schlecht mit der History-Länge) und ist für diejenigen, die mit den Befehlszeilenschnittstellen traditioneller SCMs (CVS, SVN usw.) vertraut sind, leicht zu erlernen. Win32 wird von seinem Entwicklungsteam als erstklassiges Ziel angesehen. Es verfügt über eine steckbare Architektur für verschiedene Komponenten und ersetzt häufig das Speicherformat. Dadurch können sie neue Funktionen einführen (z. B. bessere Unterstützung für die Integration mit Revisionskontrollsystemen basierend auf verschiedenen Konzepten) und die Leistung verbessern. Das Bazaar-Team betrachtet Verzeichnis-Tracking und Umbenennung unterstützt erstklassige Funktionalität. Während global eindeutige Revisions-ID-Identifikatoren für alle Revisionen verfügbar sind, werden baumlokale revnos (Standardrevisionsnummern, die denen von svn oder anderen konventionelleren SCMs ähnlicher sind) anstelle von Inhalts-Hashes zum Identifizieren von Revisionen verwendet. Bazaar unterstützt "Lightweight Checkouts", bei denen der Verlauf auf einem Remote-Server aufbewahrt wird, anstatt auf das lokale System kopiert zu werden, und bei Bedarf automatisch über das Netzwerk abgerufen wird. Derzeit ist dies unter DSCMs einzigartig.

Beide haben eine Form der SVN-Integration zur Verfügung; bzr-svn ist jedoch wesentlich leistungsfähiger als git-svn, hauptsächlich aufgrund von zu diesem Zweck eingeführten Revisionen des Backend-Formats. [Update, Stand 2014: Das kommerzielle Produkt von Drittanbietern SubGit bietet eine bidirektionale Schnittstelle zwischen SVN und Git, die in Treue zu bzr-svn vergleichbar und wesentlich polierter ist; Ich empfehle dringend seine Verwendung gegenüber der von git-svn, wenn Budget- und Lizenzbeschränkungen dies zulassen.

Ich habe Mercurial nicht ausgiebig benutzt und kann es daher nicht im Detail kommentieren - außer zu bemerken, dass es, wie Git, Inhalts-Hash-Adressierung für Revisionen hat; Wie Git auch, behandelt es Verzeichnisse nicht als erstklassige Objekte (und kann kein leeres Verzeichnis speichern). Es ist jedoch schneller als jedes andere DSCM mit Ausnahme von Git und hat eine weitaus bessere IDE-Integration (insbesondere für Eclipse) als jeder seiner Mitbewerber. Angesichts seiner Leistungsmerkmale (die nur wenig hinter denen von Git zurückbleiben) und seiner überlegenen plattformübergreifenden und IDE-Unterstützung kann Mercurial für Teams mit einer erheblichen Anzahl von win32-zentrischen oder IDE-gebundenen Mitgliedern zwingend sein.

Ein Problem bei der Migration von SVN besteht darin, dass die GUI-Frontends und die IDE-Integration von SVN ausgereifter sind als die der verteilten SCMs. Wenn Sie die SVC-Skriptautomatik derzeit intensiv nutzen (dh, Unit-Tests müssen bestanden werden, bevor ein Commit fortgesetzt werden kann), möchten Sie wahrscheinlich ein Tool verwenden, das PQM ähnlich ist, um Zusammenführungsaufträge an Ihre gemeinsamen Zweige zu automatisieren.

SVK ist eine DSCM, die Subversion als Backing-Store verwendet und eine recht gute Integration mit SVN-zentrischen Tools hat. Es hat jedoch dramatisch schlechtere Leistungs- und Skalierbarkeitseigenschaften als jedes andere große DSCM (selbst Darcs) und sollte für Projekte vermieden werden, die entweder in Bezug auf die Länge des Verlaufs oder die Anzahl der Dateien wachsen können.

[Über den Autor: Ich benutze Git und Perforce für die Arbeit, und Bazaar für meine persönlichen Projekte und als eingebettete Bibliothek; andere Teile der Organisation meines Arbeitgebers verwenden Mercurial stark. In einem früheren Leben habe ich viel Automatisierung rund um SVN aufgebaut; Davor habe ich Erfahrung mit GNU Arch, BitKeeper, CVS und anderen. Git war anfangs ziemlich abschreckend - es fühlte sich an wie GNU Arch, da es eine konzeptionslastige Umgebung ist, im Gegensatz zu Toolkits, die so gebaut wurden, dass sie den Arbeitsabläufen des Benutzers entsprechen - aber ich habe mich seitdem ziemlich wohl damit verstanden es].


Ich habe Bazaar für eine Weile benutzt, was mir sehr gefallen hat, aber es waren nur kleinere Projekte und selbst dann war es ziemlich langsam. So einfach zu lernen, aber nicht super schnell. Es ist jedoch sehr x-Plattform.

Ich benutze derzeit Git, das ich sehr mag, da Version 1.6 es in Bezug auf die Befehle viel ähnlicher zu anderen VCS gemacht hat.

Ich denke, die Hauptunterschiede bei meiner Erfahrung mit DVCS sind:

  1. Git hat die lebendigste Community und es ist üblich, Artikel über Git zu sehen
  2. GitHub rockt wirklich. Launchpad.net ist in Ordnung, aber nichts wie das Vergnügen von Github
  3. Die Anzahl der Workflow-Tools für Git war großartig. Es ist überall integriert. Es gibt einige für Bzr, aber nicht annähernd so viele oder so gut gepflegt.

Zusammenfassend war Bzr großartig, als ich mir beim DVCS die Zähne zusammenbiss, aber jetzt bin ich sehr glücklich mit Git und Github.



Mercurial und Bazaar ähneln sich sehr an der Oberfläche. Beide bieten grundlegende verteilte Versionskontrolle, wie beim Offline-Commit und Zusammenführen mehrerer Zweige, sind beide in Python geschrieben und sind beide langsamer als git. Es gibt viele Unterschiede, wenn Sie sich erst einmal mit dem Code beschäftigt haben, aber für Ihre routinemäßigen alltäglichen Aufgaben sind sie tatsächlich die gleichen, obwohl Mercurial etwas mehr Dynamik zu haben scheint.

Git, naja, ist nichts für Uneingeweihte. Es ist viel schneller als Mercurial und Bazaar und wurde geschrieben, um den Linux-Kernel zu verwalten. Es ist das schnellste der drei und es ist auch das stärkste der drei, mit einem großen Vorsprung. Git's Log- und Commit-Manipulationstools sind unerreicht. Es ist jedoch auch die komplizierteste und am gefährlichsten zu verwenden. Es ist sehr einfach, ein Commit zu verlieren oder ein Repository zu ruinieren, besonders wenn Sie die inneren Abläufe von Git nicht verstehen.


Verteilte Versionskontrollsysteme (DVCS) lösen andere Probleme als zentralisierte VCSs. Vergleicht man sie, gleicht das einem Vergleich von Hämmern und Schraubenziehern.

Zentralisierte VCS- Systeme sind in der Absicht entworfen, dass es eine wahre Quelle gibt, die gesegnet ist und daher gut. Alle Entwickler arbeiten (checkout) von dieser Quelle und fügen dann ihre Änderungen hinzu (commit), die dann ähnlich Selig werden. Der einzige wirkliche Unterschied zwischen CVS, Subversion, ClearCase, Perforce, VisualSourceSafe und allen anderen CVCs besteht im Workflow, der Leistung und der Integration, die jedes Produkt bietet.

Verteilte VCS- Systeme sind so konzipiert, dass ein Repository so gut ist wie jedes andere und dass die Zusammenführung von einem Repository zu einem anderen nur eine andere Form der Kommunikation darstellt. Jeder semantische Wert, auf welches Repository vertraut werden soll, wird von außen durch den Prozess und nicht durch die Software selbst auferlegt.

Die richtige Wahl zwischen der Verwendung des einen oder des anderen Typs ist organisatorisch - wenn Ihr Projekt oder Ihre Organisation eine zentralisierte Kontrolle wünscht, dann ist ein DVCS ein Nicht-Starter. Wenn von Ihren Entwicklern erwartet wird, dass sie im ganzen Land / der Welt arbeiten, ohne sichere Breitbandverbindungen zu einem zentralen Repository, dann ist DVCS wahrscheinlich Ihre Rettung. Wenn du beides brauchst, bist du fsck'd.


Werfen Sie einen Blick auf den kürzlich von den Python-Entwicklern vorgenommenen Vergleich: http://wiki.python.org/moin/DvcsComparison . Sie wählten Mercurial aus drei wichtigen Gründen:

Die Entscheidung für Mercurial wurde aus drei wichtigen Gründen getroffen:

  • Laut einer kleinen Umfrage sind Python-Entwickler mehr daran interessiert, Mercurial zu verwenden als in Bazaar oder Git.
  • Mercurial ist in Python geschrieben, was mit der Python-Dev-Tendenz übereinstimmt, "ihr eigenes Hundefutter zu essen".
  • Mercurial ist deutlich schneller als bzr (es ist langsamer als git, allerdings um einen viel kleineren Unterschied).
  • Mercurial ist für SVN-Benutzer einfacher zu erlernen als Bazaar.

(von http://www.python.org/dev/peps/pep-0374/ )


Sun hat eine Evaluierung von git , Mercurial und Bazaar als Kandidaten durchgeführt, um das Sun Teamware VCS für die Solaris-Codebasis zu ersetzen. Ich fand es sehr interessant.







bazaar