Was sind die relativen Stärken und Schwächen von Git, Mercurial und Bazaar? [geschlossen]
137
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?
Übrigens würde ich gerne einen Prozentsatz der Nutzung verschiedener DVCS-Systeme sehen.
Sergiol
Antworten:
145
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].
Heya. Ich möchte Sie nur wissen lassen, dass cscvs immer noch zum Ausführen von Launchpad-Codeimporten verwendet wird, und ich hatte die Canonical-Version veröffentlicht, als ich dort arbeitete.
ddaa
19
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.
@ Gavenkoa, Basar ist intuitiv für Leute, die von SVN kommen. Wenn Sie von git kommen, dann haben Sie ein mentales Modell, das näher an den Grundlagen des Basars liegt, aber sehr, sehr weit von seiner Schnittstelle entfernt ist. (... eine so dicke Abstraktionsschicht zwischen den Grundlagen und der Schnittstelle zu haben, die es bzr ermöglicht, freundlich zu Leuten zu sein, die mit dem SVN-Modell vertraut sind).
Charles Duffy
2
@CharlesDuffy Mercurial hat auch intuitive Namen für Befehle und nicht tot (Bazaar-Entwicklung wurde vor 2 Jahren gestoppt und Canonical lehnt es ab, ja Git + Github gewinnt DVCS-Spiel ). Ich verstehe das Git-Namensschema nie, also persönlich bevorzuge ich HG. Es ist zu schwer, mit Git-Liebhabern zu kämpfen ((
Gavenkoa
@gavenkoa, die Kernbefehlsnamen von bzr stimmen mit SVNs überein, daher sehe ich auch hier nicht, was an ihnen möglicherweise nicht intuitiv sein könnte (für einen SVN-Benutzer). Ja, natürlich ist die Entwicklung tot. Ich behaupte nicht, dass bzr praktisch ist - nur, dass die spezifische Kritik außerhalb der Basis lag.
Charles Duffy
1
@gavenkoa, ... Ich habe auch bekannte Aspekte von BitKeeper zu verteidigen, obwohl sie einen ziemlich großen Groll gegen den Entwicklern des Software / Besitzer (seine Basis öffentlich dokumentiert ... obwohl Larry hat mich anrufen, sobald ihr Ende zu beschreiben , was passiert ist, und ich gebe zu, dass ich jetzt beide Seiten verstehe). Nur weil ich ein SCM verteidige, heißt das nicht, dass ich den Leuten tatsächlich empfehle, es zu benutzen. :)
Charles Duffy
15
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).
Zu Ihrer Information - bzr-svn ist weitaus leistungsfähiger als git-svn, da es bidirektional ist: Ich kann "bzr branch svn: // ..." ausführen und meine Änderungen später wieder auf dem svn-Server zusammenführen - wo sie sich befinden wird mit Metadaten gespeichert, die andere bzr-Clients erkennen.
Charles Duffy
2
Ich bin ein hg-Entwickler und habe mir ein bisschen das Git-Design angesehen. Ich bin froh zu sehen, dass beide die Geschichte auf die einzig sinnvolle Weise für eine verteilte Umgebung behandeln: Auf einer hohen Ebene sind sie beide ein azyklisches Diagramm von Commits und auf einer niedrigeren Ebene lassen sie Commits Referenzmanifeste, die Dateien referenzieren (Blobs in Git) ). Mercurial hat anonyme Zweige (die AFAIK in Git nicht gibt), es hat Zweige mit Lesezeichen versehen (sehr ähnlich wie Git-Zweige, aber kein Push / Pull) und es hat Zweige benannt (Zweigname wird in Commit aufgezeichnet - diese sind es auch nicht in Git).
Diese Antwort würde durch eine Zusammenfassung dieses Vergleichs verbessert.
Lindes
7
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.
Mercurial ist Git wirklich ebenbürtig. Die Leistung ist kein großer Unterschied. Aber Basar ist waaaay langsamer als Mercurial und Git.
Joshua Partogi
@jpartogi - Die Leistungszahlen von Bazaar haben sich viel schneller verbessert als die der Konkurrenz. Daher wäre ich vorsichtig, wenn ich diese Art von Behauptung aufstellen würde - insbesondere mit dem Speicher-Refactoring, das in aktuellen Versionen als Vorschau verfügbar ist und in 2.0 standardmäßig verfügbar sein soll.
Charles Duffy
6
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.
Mozilla und Sun verwenden aus dem gleichen Grund auch Mercurial.
Joshua Partogi
2
bzr ist ebenfalls in Python geschrieben, zwar langsamer als hg, aber mit einem sich schnell verengenden Spielraum - und als Benutzer von Bazaar und Mercurial bin ich / stark / nicht einverstanden mit der Behauptung "leichter zu lernen".
Charles Duffy
1
Sie entwickeln sich alle noch weiter. Ich entschied mich für Bazaar für ein DCVS, weil ich dachte, es sei am einfachsten (aber nicht viel drin) und für Launchpad.net. Es war ziemlich langsam. Git unter OSX scheint in Ordnung zu sein, aber die Windows-Unterstützung ist schlecht. Da Python- und Google-Projekte es jetzt übernommen haben und aufgrund von TortoiseHg, wechsle ich zu Mercurial. Ich denke, Mercurial gewinnt eine kritische Masse über Bazaar und wird es dort tun. Und Git wird sein eigenes Ding machen, immer auf Posix fokussiert, also niemals wirklich dominant sein.
Nick
5
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.
Diese Bewertungen sind etwas veraltet, neuere Versionen haben einige der dort genannten Nachteile geändert.
Hayalci
2
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.
Dies fehlt aufgrund des Designs - cp kann nicht hinzugefügt werden, ohne eine Reihe von Fällen zu erstellen, in denen es schwierig oder unmöglich ist, beim Zusammenführen zwischen einem Zweig, in dem eine Kopie und Änderungen vorgenommen wurden, und einem anderen Zweig mit Änderungen, aber ohne Kopie, das Richtige zu tun .
Charles Duffy
Sicher, aber es ist etwas, das Sie beachten sollten - und es wäre eine sehr nützliche Funktion für viele Anwendungsfälle (z. B. das Aufteilen einer Datei in zwei verschiedene und das Beibehalten des Verlaufs für beide). Eigentlich ist es der einzige Grund, warum ich für bestimmte Projekte immer noch Subversion verwende - wo das Zusammenführen irrelevant ist, das Kopieren jedoch nicht
Davide
2
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:
Git hat die lebendigste Community und es ist üblich, Artikel über Git zu lesen
GitHub rockt wirklich. Launchpad.net ist in Ordnung, aber nichts wie das Vergnügen von Github
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.
Du meinst "jetzt" sehr glücklich, im Gegensatz zu "nicht" sehr glücklich, oder?
Charles Duffy
Danke Charles!
Habe
1
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.
Mercurial ist so einfach wie Bazaar, im Vergleich zu Git relativ schnell und hat eine gute Unterstützung für Bitbucket. Was könnten Sie sonst noch fragen?
Joshua Partogi
1
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.
Auf der aktuellen Seite heißt es: "Seit Bazaar Version 1.6 ist TortoiseBZR im offiziellen Installationsprogramm enthalten", also scheint es gereift zu sein.
PhiLho
1
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.
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.
Es gibt sehr signifikante Unterschiede zwischen CVS, SVN und VisualSourceSafe (um nur 3 zu nennen), die schwerwiegende Auswirkungen auf ihre Nützlichkeit haben - und dies sind nicht nur Workflow- und / oder Integrationsprobleme.
Murph
Ich habe alle drei verwendet, und technisch gesehen sind Sie richtig, aber aus einer hochrangigen Perspektive ist meine Antwort auch gültig. Die Versionskontrolle für mehr als einen Entwickler ist ein organisatorisches Werkzeug. Solange das Tool die Anforderungen des Unternehmens erfüllt, ist dies auf lange Sicht alles, was zählt.
Antworten:
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].
quelle
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.
quelle
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.
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.
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).
quelle
InfoQ hat einen schönen Vergleich .
quelle
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.
quelle
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:
quelle
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.
quelle
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.
quelle
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:
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.
quelle
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.
quelle
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.
quelle
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.
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.
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.
quelle
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.
quelle
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.quelle
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
quelle
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.
quelle