Was sind die relativen Stärken und Schwächen von Git, Mercurial und Bazaar? [geschlossen]

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

Welche Probleme sollten bei der Betrachtung der einzelnen Elemente untereinander und gegen Versionskontrollsysteme wie SVN und Perforce berücksichtigt werden?

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

Git ist sehr schnell, skaliert sehr gut und ist sehr transparent über seine Konzepte. Der Nachteil dabei ist, dass es eine relativ steile Lernkurve gibt. Ein Win32-Port ist verfügbar, aber kein erstklassiger Bürger. Git stellt Benutzern Hashes als Versionsnummern zur Verfügung. Dies bietet Garantien (da sich ein einzelner Hash immer auf genau denselben Inhalt bezieht; ein Angreifer kann den Verlauf nicht ändern, ohne erkannt zu werden), kann jedoch für den Benutzer umständlich sein. Git hat ein einzigartiges Konzept zum Verfolgen von Dateiinhalten, selbst wenn diese Inhalte zwischen Dateien verschoben werden, und zeigt Dateien als Objekte der ersten Ebene an, verfolgt jedoch keine Verzeichnisse. Ein weiteres Problem mit git ist, dass es viele Operationen gibt (z. B. Rebase)) die es einfach machen, den Verlauf zu ändern (in gewissem Sinne - der Inhalt, auf den ein Hash verweist, wird sich nie ändern, aber Verweise auf diesen Hash können verloren gehen); Einige Puristen (ich eingeschlossen) mögen das nicht sehr.

Bazaar ist relativ schnell (sehr schnell für Bäume mit geringer Historie, skaliert derzeit jedoch schlecht mit der Länge der Historie) 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. Auf diese Weise können sie neue Funktionen einführen (z. B. eine bessere Unterstützung für die Integration in Revisionskontrollsysteme, die auf unterschiedlichen Konzepten basieren) und die Leistung verbessern. Das Bazaar-Team prüft die Verzeichnisverfolgung und die Umbenennung unterstützt erstklassige Funktionen. Während global eindeutige Revisions-ID-IDs für alle Revisionen verfügbar sind, sind baumlokale Revnos (Standard-Revisionsnummern, ähnlicher wie die von svn oder anderen konventionelleren SCMs verwendeten) werden anstelle von Inhalts-Hashes zur Identifizierung von Revisionen verwendet. Bazaar unterstützt "Lightweight Checkout", bei dem der Verlauf auf einem Remote-Server gespeichert 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 irgendeine Form der SVN-Integration zur Verfügung; bzr-svn ist jedoch wesentlich leistungsfähiger als git-svn, was hauptsächlich auf die zu diesem Zweck eingeführten Revisionen des Backend-Formats zurückzuführen ist. [Update ab 2014: Das kommerzielle Drittanbieterprodukt SubGit bietet eine bidirektionale Schnittstelle zwischen SVN und Git, die in ihrer Wiedergabetreue mit bzr-svn vergleichbar und wesentlich ausgefeilter ist. Ich empfehle dringend die Verwendung gegenüber git-svn, wenn Budget- und Lizenzbeschränkungen dies zulassen.

Ich habe Mercurial nicht ausgiebig verwendet und kann es daher nicht im Detail kommentieren - außer zu beachten, dass es wie Git eine Content-Hash-Adressierung für Revisionen hat; Ebenso wie Git werden Verzeichnisse nicht als erstklassige Objekte behandelt (und es kann kein leeres Verzeichnis gespeichert werden). Es ist jedoch schneller als jedes andere DSCM außer Git und hat eine weitaus bessere IDE-Integration (insbesondere für Eclipse) als jedes seiner Konkurrenten. Aufgrund seiner Leistungsmerkmale (die nur geringfügig 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-zentrierten oder IDE-gebundenen Mitgliedern überzeugend sein.

Ein Problem bei der Migration von SVN ist, dass die GUI-Frontends und die IDE-Integration von SVN ausgereifter sind als die der verteilten SCMs. Wenn Sie derzeit die Pre-Commit-Skriptautomatisierung mit SVN intensiv nutzen (dh Unit-Tests müssen bestanden werden, bevor ein Commit fortgesetzt werden kann), sollten Sie wahrscheinlich ein PQM- ähnliches Tool verwenden, um Zusammenführungsanforderungen an Ihre freigegebenen Zweige zu automatisieren.

SVK ist ein DSCM, das Subversion als Hintergrundspeicher verwendet und sich recht gut in SVN-zentrierte Tools integrieren lässt. Es weist jedoch dramatisch schlechtere Leistungs- und Skalierbarkeitseigenschaften auf als jedes andere große DSCM (sogar Darcs) und sollte bei Projekten vermieden werden, die entweder in Bezug auf die Länge des Verlaufs oder die Anzahl der Dateien stark zunehmen können.

[Über den Autor: Ich verwende 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 um SVN herum aufgebaut. Davor habe ich Erfahrung mit GNU Arch, BitKeeper, CVS und anderen. Git war anfangs ziemlich abstoßend - es fühlte sich wie GNU Arch an, da es eine konzeptlastige Umgebung war, im Gegensatz zu Toolkits, die so gebaut wurden, dass sie der Auswahl der Workflows des Benutzers entsprechen -, aber seitdem bin ich ziemlich zufrieden damit es].

Steve Streeting vom Ogre 3D-Projekt hat gerade (28.09.2009) einen Blogeintrag zu diesem Thema veröffentlicht, in dem er einen großartigen und gleichmäßigen Vergleich von Git, Mercurial und Bazaar anstellt .

Am Ende findet er mit allen drei Stärken und Schwächen und keinen klaren Sieger. Auf der positiven Seite gibt er einen großartigen Tisch, an dem Sie sich entscheiden können, zu welchem ​​Tisch Sie gehen möchten.

Es ist eine kurze Lektüre und ich kann es nur empfehlen.

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

Meiner Meinung nach ist die Stärke von Git das saubere Design und die sehr umfangreichen Funktionen. Ich denke auch, dass dies die beste Unterstützung für Repositorys mit mehreren Filialen und die Verwaltung von Workflows mit vielen Filialen bietet. Es ist sehr schnell und hat eine kleine Repository-Größe.

Es hat einige Funktionen, die nützlich sind, aber einige Anstrengungen erfordern, um an sie gewöhnt zu sein. Dazu gehören sichtbare Zwischen-Staging-Ara (Index) zwischen Arbeitsbereich und Repository-Datenbank, die eine bessere Zusammenführungsauflösung in komplizierteren Fällen, inkrementelles Festschreiben und Festlegen mit schmutzigem Baum ermöglichen. Erkennen von Umbenennungen und Kopien mithilfe von Ähnlichkeitsheuristiken, anstatt sie mithilfe von Datei-IDs zu verfolgen, was gut funktioniert und Schuldzuweisungen (Anmerkungen) zulässt, die der Codebewegung über Dateien hinweg folgen können und nicht nur Umbenennungen im Großhandel.

Einer der Nachteile ist, dass die MS Windows-Unterstützung hinterherhinkt und nicht voll ist. Ein weiterer wahrgenommener Nachteil ist, dass es nicht so gut dokumentiert ist wie beispielsweise Mercurial und weniger benutzerfreundlich als die Konkurrenz ist, sich jedoch ändert.

Meiner Meinung nach liegt die Stärke von Mercurial in der guten Leistung und der geringen Größe des Repositorys sowie in der guten Unterstützung von MS Windows.

Der Hauptnachteil ist meiner Meinung nach die Tatsache, dass lokale Zweigstellen (mehrere Zweigstellen in einem einzigen Repository) immer noch Bürger zweiter Klasse sind und auf seltsame und komplizierte Weise Tags implementieren. Auch die Art und Weise, wie mit Dateiumbenennungen umgegangen wird, war nicht optimal (aber diese Größe hat sich geändert). Mercurial unterstützt keine Octopus-Zusammenführungen (mit mehr als zwei Elternteilen).

Was ich von den wichtigsten Vorteilen von Bazaar gehört und gelesen habe, ist die einfache Unterstützung des zentralisierten Workflows (was auch ein Nachteil ist, da zentralisierte Konzepte dort sichtbar sind, wo sie nicht angezeigt werden sollten) sowie die Verfolgung der Umbenennung von Dateien und Verzeichnissen.

Der Hauptnachteil ist die Leistung und die Repository-Größe für große Repositorys mit langem nichtlinearem Verlauf (die Leistung wurde zumindest für nicht zu große Repositorys verbessert). Die Tatsache, dass das Standardparadigma eine Ranch pro Repository ist (Sie können es jedoch so einrichten, dass Daten gemeinsam genutzt werden). und zentralisierte Konzepte (aber auch das, was ich gehört habe, ändert sich).

Git ist in C, Shell-Skripten und Perl geschrieben und kann geschrieben werden. 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.

Welche Probleme sollten bei der Betrachtung der einzelnen Elemente untereinander und gegen Versionskontrollsysteme wie SVN und Perforce 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 ein viel breiteres Spektrum an Workflows. Sie erlauben die Verwendung von "Veröffentlichen, wenn fertig". Sie bieten eine bessere Unterstützung für das Verzweigen und Zusammenführen sowie für verzweigungsintensive Workflows. 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 berücksichtigen sollten, ist die Unterstützung für das Abziehen mit SVN. Git hat git-svn, Bazaar hat bzr-svn und Mercurial hat die Erweiterung hgsubversion.

Haftungsausschluss: Ich bin Git-Benutzer und kleiner Zeitspender und schaue mir die Git-Mailingliste an (und nehme daran teil). Ich kenne Mercurial und Bazaar nur aus ihrer Dokumentation, verschiedenen Diskussionen über IRC und Mailinglisten sowie Blog-Posts und Artikeln, in denen verschiedene Versionskontrollsysteme verglichen werden (von denen einige auf der GitComparison- Seite im Git-Wiki aufgeführt sind).

InfoQ hat einen schönen Vergleich .

Mercurial und Bazaar ähneln sich an der Oberfläche sehr. Beide bieten eine grundlegende verteilte Versionskontrolle, wie beim Offline-Festschreiben und Zusammenführen mehrerer Zweige, sind beide in Python geschrieben und langsamer als Git. Sobald Sie sich mit dem Code befasst haben, gibt es viele Unterschiede, aber für Ihre täglichen Routineaufgaben sind sie praktisch gleich, obwohl Mercurial etwas mehr Schwung zu haben scheint.

Git ist nichts für Uneingeweihte. Es ist viel schneller als Mercurial und Bazaar und wurde für die Verwaltung des Linux-Kernels geschrieben. Es ist das schnellste der drei und mit Abstand auch das mächtigste der drei. Die Protokoll- und Commit-Manipulationstools von Git sind unübertroffen. Es ist jedoch auch das komplizierteste und gefährlichste zu verwenden. Es ist sehr leicht, ein Commit zu verlieren oder ein Repository zu ruinieren, besonders wenn Sie das Innenleben von Git nicht verstehen.

Schauen Sie sich den kürzlich von den Python-Entwicklern durchgeführten Vergleich an: http://wiki.python.org/moin/DvcsComparison . Sie entschieden sich aus drei wichtigen Gründen für Mercurial:

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

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

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

Sun hat eine Bewertung 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.

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

Ich habe Bazaar eine Weile benutzt, was mir sehr gut 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, was mir sehr gefällt, da Version 1.6 es in Bezug auf die zu verwendenden Befehle anderen VCS viel ähnlicher gemacht hat.

Ich denke, die Hauptunterschiede für meine Erfahrung mit DVCS sind folgende:

1. Git hat die lebendigste Community und es ist üblich, Artikel über Git zu lesen
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 bei weitem nicht so viele oder so gut gepflegt.

Zusammenfassend war Bzr großartig, als ich mir auf DVCS die Zähne geschnitten habe, aber jetzt bin ich sehr zufrieden mit Git und Github.

Dies ist eine große Frage, die stark vom Kontext abhängt, für dessen Eingabe Sie viel Zeit benötigen würden. Außerdem scheinen alle drei im Wesentlichen ähnlich zu sein, wenn sie für die üblichen Aufgaben der meisten Programmierer verwendet werden. Selbst um die Unterschiede zu verstehen, sind einige ziemlich esoterische Kenntnisse erforderlich.

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

Basar ist meiner Meinung nach leichter zu lernen als Git. Git hat eine nette Unterstützung in github.com.

Ich denke, Sie sollten versuchen, beide zu verwenden und entscheiden, welche am besten zu Ihnen passt.

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 bietet transparente Lese- und Schreibunterstützung für SVN-Repositorys) und legt großen Wert auf die Benutzererfahrung. Mercurial ist irgendwo in der Mitte.

Alle drei Systeme haben viele Fanboys. Ich persönlich bin ein Basar-Fan.

Welche Probleme sollten bei der Betrachtung der einzelnen Elemente untereinander und gegen Versionskontrollsysteme wie SVN und Perforce berücksichtigt werden?

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

Zentralisiert oder dezentral ist eine viel bedeutendere 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?

Erstens fehlt ein guter Ersatz für TortoiseSVN. Bazaar arbeitet zwar an einer eigenen Tortoise-Variante , ist aber seit September 2008 noch nicht da.

Anschließend werden die Schlüsselpersonen darüber geschult, wie sich die Verwendung eines dezentralen Systems auf ihre Arbeit auswirkt.

Schließlich die Integration mit dem Rest des Systems, wie z. B. Issue-Trackern, dem nächtlichen Build-System, dem automatisierten Testsystem usw.

Ihr Hauptproblem wird sein, dass es sich um verteilte SCMs handelt, die eine gewisse Änderung der Denkweise des Benutzers erfordern. Sobald sich die Leute an die Idee gewöhnt haben, werden die technischen Details und Verwendungsmuster übereinstimmen, aber unterschätzen Sie diese anfängliche Hürde nicht, insbesondere in einem Unternehmen. Denken Sie daran, alle Probleme sind Probleme der Menschen.

ddaa.myopenid.com hat es nebenbei erwähnt, aber ich denke, es ist noch einmal erwähnenswert: Bazaar kann in Remote-SVN-Repositorys lesen und schreiben. Das bedeutet, dass Sie Bazaar lokal als Proof-of-Concept verwenden können, während der Rest des Teams noch Subversion verwendet.

EDIT: So ziemlich alle das Werkzeug jetzt hat etwas Art und Weise mit SVN in Wechselwirkung zu treten, aber ich habe jetzt persönliche Erfahrung , die git svnfunktioniert sehr gut. Ich benutze es seit Monaten mit minimalem Schluckauf.

Es gibt ein gutes Video von Linus Torvalds auf Git. Er ist der Schöpfer von Git, also fördert er dies, aber im Video erklärt er, was verteilte SCMs sind und warum sie besser sind als zentralisierte. Es gibt viele Vergleiche zwischen git (Quecksilber wird als OK angesehen) und cvs / svn / perforce. Es gibt auch Fragen des Publikums zur Migration auf verteiltes SCM.

Ich fand dieses Material aufschlussreich und werde an verteiltes SCM verkauft. Aber trotz Linus 'Bemühungen ist meine Wahl quecksilberhaltig. Der Grund ist bitbucket.org, ich fand es besser (großzügiger) als Github.

Ich muss hier ein Wort der Warnung sagen: Linus hat einen ziemlich aggressiven Stil, ich denke, er möchte lustig sein, aber ich habe nicht gelacht. Abgesehen davon ist das Video großartig, wenn Sie neu in verteilten SCMs sind und über einen Wechsel von SVN nachdenken.

http://www.youtube.com/watch?v=4XpnKHJAok8

Verteilte Versionskontrollsysteme (DVCS) lösen andere Probleme als zentralisierte VCS. Der Vergleich ist wie der Vergleich von Hämmern und Schraubendrehern.

Zentralisierte VCS- Systeme wurden mit der Absicht entwickelt, dass es eine wahre Quelle gibt, die gesegnet und daher gut ist. Alle Entwickler arbeiten (Checkout) von dieser Quelle aus und fügen dann ihre Änderungen hinzu (festschreiben), die dann ähnlich gesegnet 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 wurden mit der Absicht entwickelt, dass ein Repository so gut wie jedes andere ist und dass das Zusammenführen von einem Repository zu einem anderen nur eine andere Form der Kommunikation darstellt. Jeder semantische Wert, welchem ​​Repository vertraut werden soll, wird von außen durch den Prozess und nicht durch die Software selbst auferlegt.

Die wirkliche Wahl zwischen der Verwendung des einen oder des anderen Typs ist organisatorisch - wenn Ihr Projekt oder Ihre Organisation eine zentralisierte Steuerung wünscht, ist ein DVCS ein Nichtstarter. Wenn von Ihren Entwicklern erwartet wird, dass sie im ganzen Land / auf der ganzen Welt ohne sichere Breitbandverbindungen zu einem zentralen Repository arbeiten, ist DVCS wahrscheinlich Ihre Rettung. Wenn Sie beides brauchen, sind Sie fsck'd.