Ich bin ein Subversion-Freak. Warum sollte ich Mercurial oder Git oder ein anderes DVCS in Betracht ziehen oder nicht?

300

Ich versuche die Vorteile des verteilten Versionskontrollsystems (DVCS) zu verstehen.

Ich fand Subversion Umerziehung und diesen Artikel von Martin Fowler sehr nützlich.

Mercurial und andere DVCS fördern eine neue Art der Code-Bearbeitung mit Changesets und lokalen Commits. Es verhindert, dass die Hölle und andere Probleme der Zusammenarbeit verschmelzen

Wir sind davon nicht betroffen, da ich die kontinuierliche Integration praktiziere und es keine Option ist, allein in einer privaten Branche zu arbeiten, es sei denn, wir experimentieren. Wir verwenden für jede Hauptversion einen Zweig, in dem wir Fehler beheben, die aus dem Stamm zusammengeführt wurden.

Mercurial ermöglicht es Ihnen, Leutnants zu haben

Ich verstehe, dass dies für sehr große Projekte wie Linux nützlich sein kann, aber ich sehe den Wert in kleinen und sehr kollaborativen Teams (5 bis 7 Personen) nicht.

Mercurial ist schneller, benötigt weniger Speicherplatz und die vollständige lokale Kopie ermöglicht schnellere Protokoll- und Diff-Vorgänge.

Ich bin auch nicht darüber besorgt, da ich selbst bei sehr großen Projekten, an denen ich arbeite, keine Geschwindigkeits- oder Platzprobleme mit SVN bemerkt habe.

Ich suche nach Ihren persönlichen Erfahrungen und / oder Meinungen von ehemaligen SVN-Freaks. Vor allem in Bezug auf die Differenzmengen Konzept und die allgemeine Performance - Boost Sie gemessen.

UPDATE (12. Jan.) : Ich bin jetzt überzeugt, dass es einen Versuch wert ist.

UPDATE (12. Juni) : Ich habe Mercurial geküsst und es hat mir gefallen. Der Geschmack seiner Kirsche vor Ort verpflichtet. Ich habe Mercurial geküsst, nur um es zu versuchen. Ich hoffe mein SVN Server hat nichts dagegen. Es fühlte sich so falsch an. Es fühlte sich so richtig an. Bedeutet nicht, dass ich heute Nacht verliebt bin .

FINAL UPDATE (29. Juli) : Ich hatte das Privileg, Eric Sinks nächstes Buch mit dem Titel " Version Control by Example" zu lesen . Er beendete mich zu überzeugen. Ich werde Mercurial gehen.

Robin Maben
quelle
8
Das interessiert mich auch sehr. Subversion entspricht der Art und Weise, wie mir das Denken über die Versionskontrolle beigebracht wurde (da es aus CVS und dergleichen stammt). Obwohl ich Mercurial und Git verwenden musste, um einige Fehlerbehebungen für Open Source-Projekte vorzunehmen, wurde ich noch nicht konvertiert.
Berin Loritsch
29
+1 für die Frage. Heutzutage ist es ein Frachtkult geworden , der einfach besser, schneller, einfacher, natürlicher und störungsfreier verteilt und um 90% glänzender als zentralisiert ist. Außer, dass es nicht unbedingt ist. Es handelt sich um unterschiedliche Tools, von denen jedes in bestimmten Kontexten Vorteile und in anderen Kontexten Nachteile haben kann.
Joonas Pulakka
17
@Sharpie: beide Nachdem verwendet svn, gitund hgseit Jahren, ich bin ziemlich gut kennen ihre Vor- und Nachteile. Obwohl gites mit Sicherheit das mächtigste davon ist, ist es wichtig anzuerkennen, dass stärker nicht automatisch besser bedeutet . Emacs ist sicherlich leistungsfähiger als jeder Javascript-Texteditor, der im Webbrowser ausgeführt wird, aber seltsamerweise schreibe ich diesen Kommentar gerade in einen Javascript-Browser-Texteditor! Einfachheit , auch Dummheit, hat in vielen Zusammenhängen einen Wert. Zentral nutzen svnund so etwas wie git-svnlokal bietet das Beste aus beiden Welten.
Joonas Pulakka
9
@Sharpie: Es ist gut für dich, dass es dir gefällt. Aber der Pro eines Mannes ist der Con eines anderen Mannes. Einige Leute halten die Klarheit eines einzelnen zentralen Repositorys mit einem einzelnen kanonischen Trunk für unglaublich wertvoll. Hier ist eine Präsentation darüber, wie Google den Quellcode aller seiner Projekte über 2000 in einem einzigen Code-Trunk mit Hunderten von Millionen Codezeilen verwaltet, wobei mehr als 5000 Entwickler auf dasselbe Repository zugreifen. Möchten Sie lieber 5000 Server und die Geschichte von 2000 Projekten auf jedermanns Schreibtisch? -)
Joonas Pulakka
21
-1 für die Katy Perry Referenz. ;)
Amadiere

Antworten:

331

Hinweis: Die Antwort auf die aktuelle Frage finden Sie unter "BEARBEITEN"


Lesen Sie zunächst Subversion Re-education von Joel Spolsky. Ich denke, die meisten Ihrer Fragen werden dort beantwortet.

Eine weitere Empfehlung, Linus Torvalds 'Vortrag auf Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Dieser andere könnte auch die meisten Ihrer Fragen beantworten, und es ist ziemlich unterhaltsam.

Übrigens finde ich das ziemlich lustig: Sogar Brian Fitzpatrick & Ben Collins-Sussman, zwei der ursprünglichen Erfinder von Subversion, sagten in einem Google-Vortrag "Entschuldigung", dass Subversion gegenüber Mercurial (und DVCSs im Allgemeinen) unterlegen sei.

Nun, IMO und im Allgemeinen, entwickelt sich die Teamdynamik mit jedem DVCS auf natürlichere Weise. Ein herausragender Vorteil ist, dass Sie ein Commit offline durchführen können, da dies die folgenden Dinge impliziert:

  • Sie sind nicht auf einen Server und eine Verbindung angewiesen, was schnellere Zeiten bedeutet.
  • Nicht als Sklave an Orte gehen, an denen Sie einen Internetzugang (oder ein VPN) haben, nur um ein Commit durchführen zu können.
  • Jeder hat ein Backup von allem (Dateien, Verlauf), nicht nur vom Server. Das heißt, jeder kann zum Server werden .
  • Sie können zwanghaft ein Commit ausführen , ohne den Code anderer zu verfälschen . Commits sind lokal. Sie treten einander beim Festschreiben nicht auf die Zehen. Sie können Builds oder Umgebungen anderer nicht einfach durch Festschreiben beschädigen.
  • Personen ohne "Commit-Zugriff" können ein Commit durchführen (da das Commit in einem DVCS nicht das Hochladen von Code impliziert), wodurch die Sperre für Beiträge gesenkt wird. Sie können entscheiden, ob Sie die Änderungen übernehmen oder nicht als Integrator.
  • Es kann die natürliche Kommunikation verstärken, da ein DVCS dies unerlässlich macht. In Subversion haben Sie stattdessen Commit-Rassen, die die Kommunikation erzwingen, aber Ihre Arbeit behindern.
  • Die Mitwirkenden können sich zusammenschließen und ihre eigene Zusammenführung durchführen, was letztendlich weniger Arbeit für die Integratoren bedeutet.
  • Mitwirkende können ihre eigenen Zweige haben, ohne die der anderen zu beeinträchtigen (können diese aber bei Bedarf teilen).

Über Ihre Punkte:

  • In DVCSland gibt es keine Möglichkeit, die Hölle zu verschmelzen. muss nicht behandelt werden. Siehe nächster Punkt .
  • In DVCSs stellt jeder eine "Verzweigung" dar, was bedeutet, dass bei jedem Abruf von Änderungen Zusammenführungen stattfinden. Benannte Zweige sind eine andere Sache.
  • Sie können die kontinuierliche Integration fortsetzen, wenn Sie möchten. IMHO nicht notwendig, warum Komplexität hinzufügen? Bewahren Sie Ihre Tests einfach als Teil Ihrer Kultur / Richtlinie auf.
  • Mercurial ist in einigen Dingen schneller, Git ist in anderen Dingen schneller. Nicht wirklich bis zu DVCSs im Allgemeinen, aber zu ihren speziellen Implementierungen AFAIK.
  • Jeder wird immer das volle Projekt haben, nicht nur Sie. Die verteilte Sache hat damit zu tun, dass Sie lokal ein Commit / Update durchführen können. Das Freigeben / Abnehmen von außerhalb Ihres Computers wird als Push / Pull bezeichnet.
  • Lesen Sie erneut Subversion Umerziehung. DVCSs sind einfacher und natürlicher, aber sie unterscheiden sich. Denken Sie nicht, dass cvs / svn die Basis aller Versionsverwaltung ist.

Ich habe einige Dokumentationen zum Joomla-Projekt beigesteuert, um eine Migration auf DVCS zu predigen, und hier habe ich einige Diagramme erstellt, um zentralisierte vs. verteilte zu veranschaulichen.

Zentralisiert

Alt-Text

In der allgemeinen Praxis verteilt

Alt-Text

In vollen Zügen verteilt

Alt-Text

Sie sehen in dem Diagramm, dass es immer noch ein "zentralisiertes Repository" gibt, und dies ist eines der Lieblingsargumente der Fans der zentralen Versionierung: "Sie werden immer noch zentralisiert", und nein, Sie sind es nicht, da das "zentralisierte" Repository nur Ihr Repository ist Alle sind sich einig (z. B. ein offizielles Github-Repo), dies kann sich jedoch jederzeit ändern.

Dies ist der typische Workflow für Open-Source-Projekte (z. B. ein Projekt mit massiver Zusammenarbeit) unter Verwendung von DVCSs:

Alt-Text

Bitbucket.org ist so etwas wie ein Github-Äquivalent für Quecksilber. Wenn Ihr Team kleiner als fünf ist, können Sie es kostenlos verwenden.

Der beste Weg, sich von der Verwendung eines DVCS zu überzeugen, ist das Ausprobieren eines DVCS. Jeder erfahrene DVCS-Entwickler, der svn / cvs verwendet hat, wird Ihnen sagen, dass es sich lohnt und dass er nicht weiß, wie er die ganze Zeit ohne DVCS überlebt hat.


BEARBEITEN : Zur Beantwortung Ihrer zweiten Bearbeitung kann ich nur wiederholen, dass Sie bei einem DVCS einen anderen Workflow haben. Ich rate Ihnen, nicht nach Gründen zu suchen, um es nicht aufgrund von Best Practices zu versuchen. Es fühlt sich an, als würden die Leute argumentieren, dass OOP nicht ist notwendig, weil sie komplexe Entwurfsmuster mit dem umgehen können, was sie immer mit dem Paradigma XYZ tun; Sie können sowieso profitieren.

Probieren Sie es aus, Sie werden sehen, wie besser es ist, in "einer privaten Filiale" zu arbeiten. Ein Grund, warum ich sagen kann, warum das Letzte wahr ist, ist, dass Sie die Angst verlieren, sich zu verpflichten , so dass Sie sich jederzeit verpflichten können, wenn Sie es für richtig halten und auf natürlichere Weise arbeiten.

In Bezug auf "Hölle verschmelzen" sagen Sie "es sei denn, wir experimentieren", ich sage "auch wenn Sie gleichzeitig experimentieren, warten und in der überarbeiteten Version 2.0 arbeiten ". Wie ich bereits sagte, gibt es keine Verschmelzung der Hölle, weil:

  • Jedes Mal, wenn Sie sich verpflichten, einen unbenannten Zweig zu generieren, und wenn Ihre Änderungen den Änderungen anderer Personen entsprechen, erfolgt eine natürliche Zusammenführung.
  • Da DVCSs für jedes Commit mehr Metadaten erfassen, treten beim Zusammenführen weniger Konflikte auf, sodass Sie es sogar als "intelligentes Zusammenführen" bezeichnen können.
  • Wenn Sie auf Zusammenführungskonflikte stoßen, können Sie Folgendes verwenden:

Alt-Text

Auch die Projektgröße spielt keine Rolle, als ich von Subversion wechselte, sah ich die Vorteile bereits, als ich alleine arbeitete. Alles fühlte sich einfach richtig an. Mit den Changesets (nicht genau eine Revision, sondern ein bestimmter Satz von Änderungen für bestimmte Dateien, die Sie mit einem Commit versehen und vom Status der Codebasis isoliert haben) können Sie genau veranschaulichen, was Sie damit gemeint haben, was Sie mit einer bestimmten Gruppe von Dateien gemacht haben. nicht die ganze Codebasis.

In Bezug auf die Funktionsweise von Changesets und die Leistungssteigerung. Ich werde versuchen, es mit einem Beispiel zu veranschaulichen, das ich gerne gebe: Das Mootools-Projekt wechselt von svn, das in der Grafik ihres Github-Netzwerks dargestellt ist .

Vor

Alt-Text

Nach

Alt-Text

Was Sie sehen, ist, dass Entwickler sich auf ihre eigene Arbeit konzentrieren können, ohne Angst davor zu haben, den Code anderer zu brechen. Sie sorgen sich darum, den Code anderer nach dem Drücken / Ziehen zu brechen ), aber da das Zusammenführen hier intelligenter ist, geschieht dies oft nie ... selbst wenn es einen Zusammenführungskonflikt gibt (was selten vorkommt), verbringen Sie nur 5 Minuten oder weniger damit, ihn zu beheben.

Meine Empfehlung an Sie ist, jemanden zu suchen, der weiß, wie man Quecksilber verwendet, und ihn / sie zu bitten, es Ihnen praktisch zu erklären. Indem ich ungefähr eine halbe Stunde mit ein paar Freunden in der Kommandozeile verbrachte, während ich mercurial mit unseren Desktops und Bitbucket-Konten verwendete, um ihnen zu zeigen, wie man Konflikte fabriziert, um sie in einer lächerlichen Menge Zeit zu beheben, konnte ich zeigen ihnen die wahre Kraft eines DVCS.

Schließlich würde ich Ihnen empfehlen, mercurial + bitbucket anstelle von git + github zu verwenden, wenn Sie mit Windows-Leuten arbeiten. Mercurial ist auch ein bisschen einfacher, aber Git ist leistungsfähiger für eine komplexere Repository-Verwaltung (z . B. Git-Rebase ).

Einige zusätzliche empfohlene Lesungen:

dukeofgaming
quelle
18
Tolle Antwort, aber nur eine Frage für diejenigen von uns, die sich im selben Boot wie OP befinden: Können Sie erklären, warum es keine Höllenverschmelzung gibt? Müssen ein Integrator oder ein Mitwirkender nicht dieselben Aktionen ausführen, wenn ihre Abspaltung veraltet ist?
Nicole
17
Gute Antwort. Nur eine Randnotiz: Während Spolsky einige nette Punkte haben mag, bedenke, dass er auch versucht, ein Produkt zu verkaufen, indem er diese Punkte als Verkaufsmaterial verwendet, was sie ein bisschen voreingenommen macht.
Martin Wickman
5
Ich habe diese Umerziehungsseite gelesen und fand sie aus vielen Gründen nicht relevant. Ich bearbeite meine Frage mit meiner persönlichen Sicht auf das Thema.
15
Es ist auch erwähnenswert, dass Git als Subversion-Client fungieren kann, was bedeutet, dass Sie nicht jeden auf einmal in Git konvertieren müssen. Einige Teammitglieder können einfach Git verwenden, wenn sie möchten, und ihr individueller Workflow verbessert sich (insbesondere, weil das Zusammenführen viel einfacher ist).
greyfade
6
@Pierre, DVCS kümmert sich darum , die Softwareänderungen der einzelnen Programmierer zusammenzuführen, aber nicht darum , die Software tatsächlich kompilieren zu lassen oder die vorhandenen Komponententests zu bestehen. Sie benötigen immer noch andere Software, um dies zu tun, wenn sich die Quelle ändert, und die beste Wette, die wir heutzutage haben, ist die Verwendung einer CI-Engine (und die ordnungsgemäße
59

Sie sagen unter anderem, dass Sie keine verteilte Versionskontrolle benötigen, wenn Sie im Wesentlichen auf einem Zweig bleiben.

Das ist wahr, aber ist es nicht eine unnötig starke Einschränkung Ihrer Arbeitsweise und eine, die sich nicht gut auf mehrere Standorte in mehreren Zeitzonen skalieren lässt? Wo sollte sich der zentrale Subversion-Server befinden und sollten alle nach Hause gehen, wenn dieser Server aus irgendeinem Grund ausfällt?

DVCSes sind zu Subversion, was Bittorrent zu ftp ist

(technisch nicht legal). Wenn Sie darüber nachdenken, werden Sie vielleicht verstehen, warum es ein so großer Sprung nach vorne ist?

Für mich führte unser Wechsel zu git sofort zu

  • Unsere Backups sind einfacher zu machen (nur "git remote update" und Sie sind fertig)
  • Es ist einfacher, kleine Schritte auszuführen, wenn Sie ohne Zugriff auf das zentrale Repository arbeiten. Sie arbeiten nur und synchronisieren, wenn Sie wieder zu dem Netzwerk zurückkehren, in dem sich das zentrale Repository befindet.
  • Schneller Hudson baut. Viel, viel schneller als das Aktualisieren.

Überlege also, warum Bittorrent besser ist als FTP, und überdenke deine Position :)


Hinweis: Es wurde erwähnt, dass es Anwendungsfälle gibt, in denen FTP schneller und als BitTorrent ist. Dies gilt genauso wie die Sicherungsdatei, die Ihr bevorzugter Editor verwaltet, schneller zu verwenden ist als ein Versionskontrollsystem.


quelle
Ich bin fast entschlossen, es mit einem echten Projekt zu versuchen.
Gute Idee. Denken Sie daran, mit der Einstellung "Ich mag das wirklich!" anstelle von "Ich will das nicht tun!". Es gibt viel zu lernen. Wenn Sie sich für git entscheiden, bietet github eine Menge guter Online-Hilfe. Wenn Sie sich für hg entscheiden, hat Joel gutes Online-Material geschrieben. Wenn Sie sich für bzr entscheiden, hat Canonical höchstwahrscheinlich eine Menge gutes Online-Material. Andere?
3
Hmm, das setzt voraus, dass Sie denken, dass Bittorrent besser als FTP ist ...
Murph
2
@Murph, das tue ich und Blizzard auch. wowwiki.com/Blizzard_Downloader
2
@Murph, Sie starten einen Torrent-Server auf dem Server und einen Torrent-Client auf dem Client. Nicht schwer. Es sollte Ihnen sofort einfallen, dass nur die Dateien aktualisiert werden müssen, die sich geändert haben. Haben Sie sich auch überlegt, was Sie mit rsync anstelle von ftp für inkrementelle Updates kaufen könnten?
46

Das Killer-Feature von verteilten Versionskontrollsystemen ist der verteilte Teil. Sie checken keine "Arbeitskopie" aus dem Repository aus, sondern klonen eine vollständige Kopie des Repositorys. Dies ist enorm, da es leistungsstarke Vorteile bietet:

  • Sie können die Vorteile der Versionskontrolle genießen, auch wenn Sie keinen Internetzugang haben wie ... Dieser ist leider überlastet und überzeichnet, da DVCS fantastisch ist - es ist einfach kein starkes Verkaufsargument für so viele Wir stellen fest, dass wir ohne Internetzugang ungefähr so ​​oft codieren, wie es anfängt, Frösche zu regnen.

  • Der wahre Grund für ein lokales Repository ist, dass Sie die vollständige Kontrolle über Ihr Commit-Protokoll haben, bevor es in das Master-Repository übertragen wird .

Habe schon einmal einen Fehler behoben und hatte am Ende so etwas wie:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Und so weiter. So ein Verlauf ist chaotisch - es gab wirklich nur einen Fix, aber jetzt verteilt sich die Implementierung auf viele Commits, die unerwünschte Artefakte enthalten, z. B. das Hinzufügen und Entfernen von Debugging-Anweisungen. Bei einem System wie SVN besteht die Alternative darin, erst dann ein Commit (!!!) durchzuführen, wenn alles funktioniert, um den Verlauf sauber zu halten. Trotzdem bleiben Fehler aus und Murphy's Law wartet darauf, Sie zu brutalisieren, wenn erhebliche Arbeitsmengen nicht durch die Versionskontrolle geschützt sind.

Ein lokaler Klon des Repositorys, dessen Eigentümer Sie sind , behebt dies, da Sie den Verlauf neu schreiben können, indem Sie kontinuierlich die Commits "fix it" und "oops" in den Commit "bug fix" rollen. Am Ende des Tages wird ein sauberes Commit an das Master-Repository gesendet, das wie folgt aussieht:

r321 Fixed annoying bug.

Wie soll es sein?

In Kombination mit dem Verzweigungsmodell ist die Möglichkeit, die Historie neu zu schreiben, noch leistungsfähiger. Ein Entwickler kann Arbeiten ausführen, die völlig isoliert in einer Zweigstelle ausgeführt werden. Wenn diese Zweigstelle dann in den Stamm verschoben werden soll, stehen Ihnen alle möglichen interessanten Optionen zur Verfügung:

  • Führe eine einfache Vanille- Fusion durch . Bringt alles in Warzen und alles.

  • Mach einen Rebase . Ermöglicht es Ihnen, die Filialhistorie zu sortieren, die Reihenfolge der Commits neu zu ordnen, Commits auszuschließen, Commits zusammenzufassen, Commit-Nachrichten neu zu schreiben - sogar Commits zu bearbeiten oder neue hinzuzufügen! Ein verteiltes Versionskontrollsystem bietet umfassende Unterstützung für die Codeüberprüfung.

Als ich erfuhr, wie lokale Repositories es mir ermöglichten, meine Geschichte im Interesse der Vernunft meiner Programmierkollegen und meines zukünftigen Ichs zu bearbeiten, legte ich SVN endgültig auf. Mein Subversion-Client ist jetzt git svn.

Wenn Entwickler und Manager die redaktionelle Kontrolle über den Festschreibungsverlauf ausüben können, führt dies zu einem besseren Projektverlauf und einem sauberen Verlauf, mit dem sie arbeiten können. Dies hilft meiner Produktivität als Programmierer. Wenn Sie all das Gerede über das "Umschreiben von Geschichte" erschreckt, machen Sie sich keine Sorgen, denn dafür sind zentrale, öffentliche oder Master-Repositories gedacht. Die Geschichte kann (und sollte!) Bis zu dem Punkt neu geschrieben werden, an dem jemand sie in einen Zweig in einem Repository bringt, aus dem andere Personen ziehen. An diesem Punkt sollte die Geschichte so behandelt werden, als ob sie auf einer Steintafel geschnitzt wäre.

Sharpie
quelle
6
Umschreiben der Geschichte: Ist das nur eine Sache für Git? Oder ist es auch in Mercurial einfach? (Wenn ja, muss ich wirklich anfangen.)
Paul D. Waite
3
Man sollte sich dabei der Disziplin des Linux-Kernels bewusst sein - nämlich niemals einen Zweig, den Sie öffentlich veröffentlicht haben, umbauen (oder den Verlauf umschreiben). Wenn Sie Zweigstellen haben, die für den kurzfristigen Gebrauch öffentlich sind (zum Zusammenführen in Zweigstellen, die häufig wie linux-next weggeworfen werden, oder zum Überprüfen und anschließenden Wegwerfen ihrer lokalen Kopien), können Sie diese Zweigstellen umbasieren - aber Ihre anderen Benutzern sollte klar sein, dass die Konvention für diesen Zweig darin besteht, dass er umbasiert werden kann und nicht mit den langfristigen Zweigen anderer Völker zusammengeführt werden darf.
Ken Bloom
4
Möglicherweise verfügen Sie über einen Internetzugang, ohne über einen vollständigen internen Netzwerkzugriff zu verfügen. Das passiert mir häufig auf Reisen.
5
Es ist eine große Sache, keinen Internetzugang zu benötigen, denn von dort kommt die Geschwindigkeit von DVCS. Sobald Sie Pakete über ein Netzwerk senden müssen, verlangsamen Sie den Vorgang um eine Größenordnung, unabhängig davon, wie gut Ihre Verbindung ist.
Adam Lassek
6
@Paul, ich verstehe, dass es in Mercurial möglich ist , aber es ist nicht die Basisfunktionalität oder -philosophie.
Benjol
18

dukofgamings Antwort ist wahrscheinlich so gut wie es nur geht, aber ich möchte dies aus einer anderen Richtung angehen.

Nehmen wir an, dass das, was Sie sagen, absolut wahr ist und dass Sie durch die Anwendung bewährter Verfahren die Probleme vermeiden können, für deren Behebung DVCS entwickelt wurde. Bedeutet dies, dass ein DVCS Ihnen keinen Vorteil bieten würde? Die Leute stinken danach, Best Practices zu befolgen . Die Leute gehen in Unordnung zu bringen. Warum sollten Sie also die Software vermeiden, die zur Behebung einer Reihe von Problemen entwickelt wurde, und sich stattdessen darauf verlassen, dass die Leute etwas tun, das Sie im Voraus vorhersagen können, dass sie nicht tun werden?

philosodad
quelle
2
Eigentlich würde ich dieses Argument gegen DCVS vorschlagen. Meine Firma ist kürzlich von CVS zu Mercurial gewechselt. Menschen löschen Veränderungen anderer Völker während der Zusammenführung viel häufiger, wenn sie CVS nutzen.
Juozas Kontvainis
@JuozasKontvainis: Ich kenne mercurial nicht sehr gut, aber in git können Sie Pushs, die Merges enthalten, die HEAD nicht als übergeordnetes Element haben, nicht zulassen, wodurch Benutzer daran gehindert werden, Änderungen zu übertragen, die nicht die neuesten Änderungen vom Master enthalten. Ich bin sicher, es gibt etwas Ähnliches in Mercurial.
Naught101
@ naught101: In meinem Unternehmen ist diese Einstellung aktiviert. Was passiert, ist, dass der Programmierer seine Änderungen lokal festschreibt und dann Push versucht. Er erhält eine Antwort vom Server, die er zusammenführen muss, bevor er pushen kann. Er erhält Updates vom Server und versucht, einen Merge-Commit durchzuführen. An diesem Punkt weiß ich nicht genau, wie diese Personen ein Merge-Commit durchgeführt haben, aber bei mehreren Gelegenheiten, bei denen das Merge-Commit durchgeführt wurde, wurden die Änderungen, die sie vom Server erhalten haben, im Wesentlichen gelöscht.
Juozas Kontvainis
1
Es hört sich so an, als hätten die Leute die Änderungen abgerufen und dann tatsächlich die Änderungen gelöscht, die sie beim Zusammenführen vom Server erhalten haben (was möglich ist). Natürlich ist das Änderungsset vom Server immer noch vorhanden, sodass Sie das Repository auf den Status zurücksetzen können, in dem es sich vor den Änderungen befand.
Philosodad
1
Eigentlich klingt es so: randyfay.com/content/avoiding-git-disasters-gory-story Schöner , unkritischer Artikel darüber, was mit einem Git-Repo schief gehen kann, wenn Sie nicht wissen, was Sie tun.
gbjbaanb
9

Ja, es tut weh, wenn Sie große Commits in Subversion zusammenführen müssen. Dies ist aber auch eine großartige Lernerfahrung, die es Ihnen ermöglicht, Konflikte zu vermeiden. Mit anderen Worten, Sie lernen, häufig einzuchecken . Eine frühzeitige Integration ist eine sehr gute Sache für ein Projekt am selben Ort. Solange alle das tun, sollte die Verwendung von Subversion kein großes Problem sein.

Git, zum Beispiel wurde entworfen für verteilte Arbeit und ermutigt die Menschen auf ihre eigenen Projekte zu arbeiten und schaffen eigene Gabeln für eine (eventuelle) fusionieren später. Es war nicht speziell für die kontinuierliche Integration in "kleine und sehr kollaborative Teams" konzipiert, was vom OP gefordert wird. Es ist eher das Gegenteil, wenn man darüber nachdenkt. Sie können die ausgefallenen verteilten Funktionen nicht nutzen, wenn Sie nur im selben Raum sitzen und gemeinsam am selben Code arbeiten.

Für ein CI-benutzendes Team am selben Standort ist es meiner Meinung nach nicht wichtig, ob Sie ein verteiltes System verwenden oder nicht. Es kommt auf Geschmack und Erfahrung an.

Martin Wickman
quelle
2
Git wurde für verteilte Arbeit auf der ganzen Welt entwickelt und ermutigt die Leute, an ihren eigenen Projekten zu arbeiten und eigene Gabeln zu erstellen. Es war nicht speziell für die kontinuierliche Integration in "kleine und sehr kollaborative Teams" konzipiert, was das OP fordert.
Martin Wickman
4
Ratet mal, du bekommst kleinere / leichtere Konflikte zu lösen. Aber wenn zwei Personen die gleichen Teile des Codes ändern, haben Sie ein Planungsproblem in Ihrem Team, das von keinem VCS gelöst werden kann. Verteilt oder nicht.
Martin Wickman
4
Das OP befindet sich in einem Team, das CI verwendet. Dies bedeutet, dass sie häufig (mehrmals täglich) viele kleine Check-ins durchführen. Angesichts dessen sehe ich keinen Grund, warum die Verwendung eines dvcs einen besonderen Vorteil bringen sollte, und ich sehe keinen Grund, warum es zu großen Verschmelzungen und damit zu keiner Hölle der Verschmelzung kommen sollte. Ich würde svn nicht für ein verteiltes Team empfehlen, aber das ist hier nicht der Fall.
Martin Wickman
2
@MartinWickman - Mercurial wurde zum Festschreiben, Verzweigen und Zusammenführen schnell und kostengünstig entwickelt. Das klingt perfekt für eine kontinuierliche Integration. Persönlich denke ich, dass die Möglichkeit für Alice, ihre Änderungen zu verzweigen und Bob vorzuschlagen, sie zu ziehen und seine Änderungen auf diesen Zweig zu verschmelzen, um nach Problemen zu suchen, ohne den zentralen Server zu berühren oder Änderungen irgendwo hin zu verschieben, eine großartige Möglichkeit ist damit kleine und sehr kollaborative Teams arbeiten.
Philosodad
2
Meine $ 0,02. Ich habe Subversion, Mercurial und Git jetzt für verschiedene Projekte verwendet. Subversion scheint wirklich die beste Wahl für eine sehr eng integrierte Gruppe zu sein, die eine kontinuierliche Integration durchführt. Mercurial ist besser für Gruppen geeignet, die möglicherweise nur einen Build pro Tag mit viel mehr Codeänderungen durchführen (was zu Problemen beim Zusammenführen in SVN führen würde). Git scheint der richtige Weg für Leute zu sein, die Teams haben, die Tage / Wochen durchhalten können, ohne tatsächlich Code zusammenzuschieben, um einen Build zu erstellen.
Brian Knoblauch
8

Weil Sie Ihr eigenes Wissen ständig herausfordern sollten. Sie lieben Subversion, und ich kann verstehen, dass ich sie viele Jahre lang verwendet habe und mich sehr darüber gefreut habe, aber das heißt nicht, dass es immer noch das Werkzeug ist, das Ihnen am besten zusagt.

Ich glaube, als ich damit anfing, war es die beste Wahl zu dieser Zeit. Aber mit der Zeit tauchen andere Tools auf, und jetzt bevorzuge ich Git, auch für meine eigenen Freizeitprojekte.

Und Subversion hat einige Mängel. Wenn Sie beispielsweise ein Verzeichnis auf der Disc umbenennen, wird es im Repository nicht umbenannt. Das Verschieben von Dateien wird nicht unterstützt. Dadurch wird das Verschieben von Dateien zu einem Kopier- / Löschvorgang und das Zusammenführen von Änderungen, wenn Dateien verschoben / umbenannt wurden, wird erschwert. Und Merge-Tracking ist nicht wirklich in das System integriert, sondern wird in Form einer Problemumgehung implementiert.

Git behebt diese Probleme (einschließlich der automatischen Erkennung, ob eine Datei verschoben wurde, Sie müssen nicht einmal sagen, dass es sich um eine Tatsache handelt).

Andererseits erlaubt es git nicht, auf einzelne Verzeichnisebenen zu verzweigen, wie es Subversion tut.

Meine Antwort lautet also: Sie sollten nach Alternativen suchen, prüfen, ob sie Ihren Bedürfnissen besser entsprechen, als Sie es kennen, und dann entscheiden.

Pete
quelle
Es ist sehr richtig, dass das Experimentieren mit Alternativen automatisch erfolgen sollte.
git verwendet eine bestimmte Heuristik, um festzustellen, ob eine Datei verschoben wurde. Sie ist gut, aber nicht perfekt.
Gbjbaanb
Stimmen Sie dem zu, auch wenn Sie das neue Werkzeug, das die verdammten Kinder benutzen, hassen. Ich denke, es ist wichtig, sich dazu zu zwingen, zumindest neue Dinge auszuprobieren, besonders wenn diese Dinge massive Wellen schlagen.
Tjaart
7

In Bezug auf die Leistung hat Git oder ein anderes DVCS einen großen Vorteil gegenüber SVN, wenn Sie von einem Zweig zu einem anderen wechseln oder von einer Revision zu einer anderen springen müssen. Da alles lokal gespeichert ist, geht es viel schneller als bei SVN.

Das allein könnte mich zum Wechseln bringen!

Xavier Nodet
quelle
Stimmen Sie zu, der Kaufvorgang ist extrem schnell.
+1 um darauf hinzuweisen, dass das Springen zwischen Zweigen / Änderungssätzen ziemlich schnell ist
dukeofgaming
3

Anstatt an der Idee festzuhalten, dass "durch Anwenden von Best Practices kein DVCS erforderlich ist", sollten Sie bedenken, dass der SVN-Workflow ein Workflow mit einer Reihe von Best Practices ist und der GIT / Hg-Workflow ein anderer Workflow ist. mit einer anderen Reihe von Best Practices.

git bisect (und alle Auswirkungen auf Ihr Haupt-Repository)

Ein sehr wichtiges Prinzip in Git ist, dass Sie Fehler mit finden können git bisect. Dazu verwenden Sie die letzte Version, von der Sie ausgeführt haben, dass sie funktioniert, und die erste Version, von der Sie ausgeführt haben, dass sie fehlgeschlagen ist, und führen (mit Gits Hilfe) eine binäre Suche durch, um herauszufinden, welches Commit den Fehler verursacht hat. Zu diesem Zweck muss Ihr gesamter Revisionsverlauf relativ frei von anderen Fehlern sein, die Ihre Fehlersuche beeinträchtigen können (ob Sie es glauben oder nicht, dies funktioniert in der Praxis ziemlich gut, und Linux-Kernel-Entwickler tun dies die ganze Zeit).

Um git bisectFunktionen zu erhalten, entwickeln Sie ein neues Feature in einem eigenen Feature-Zweig , führen einen Rebase durch und bereinigen den Verlauf (sodass Sie keine bekannten, nicht funktionierenden Revisionen in Ihrem Verlauf haben - nur eine Reihe von Änderungen, die Sie jeweils auf einen Schlag erledigen Wenn das Feature fertig ist, fügen Sie es in den Hauptzweig mit dem Arbeitsverlauf ein.

Damit dies funktioniert, müssen Sie darüber informiert sein, von welcher Version des Hauptzweigs aus Sie den Feature-Zweig starten. Sie können nicht einfach vom aktuellen Stand des masterZweigs aus starten, da dies möglicherweise nicht verwandte Fehler enthält. Daher empfiehlt es sich in der Kernel-Community, die Arbeit mit der neuesten stabilen Version des Kernels (für große Funktionen) oder mit der Arbeit zu beginnen vom neuesten getaggten Release Candidate.

Sie können Ihren Zwischenstand auch sichern, indem Sie den Feature-Zweig in der Zwischenzeit auf einen Server übertragen. Sie können den Feature-Zweig auch auf einen Server übertragen, um ihn für andere Personen freizugeben und Feedback zu erhalten, bevor die Funktion abgeschlossen ist, bevor Sie dies tun müssen Verwandeln Sie Code in eine dauerhafte Funktion der Codebasis, mit der sich alle * in Ihrem Projekt befassen müssen.

Die gitworkflows- Manpage ist eine gute Einführung in die Workflows, für die Git entwickelt wurde. Auch, warum Git besser als X ist, wird auf Git-Workflows eingegangen.

Große, verteilte Projekte

Warum brauchen wir Leutnants in einem eng zusammenarbeitenden Team mit guten Praktiken und guten Designgewohnheiten?

Weil in Projekten wie Linux so viele Leute involviert sind, die so geografisch verteilt sind, dass es schwierig ist, so gut zusammenzuarbeiten wie ein kleines Team, das sich einen Konferenzraum teilt. (Ich vermute, dass für die Entwicklung eines großen Produkts wie Microsoft Windows das Team einfach zu groß ist, um die Zusammenarbeit aufrechtzuerhalten, mit der ein zentrales VCS ohne Stellvertreter funktioniert, auch wenn sich alle Mitarbeiter im selben Gebäude befinden.)

Ken Bloom
quelle
Ich verstehe deinen ersten Punkt nicht. Haben Sie Referenzen? In Bezug auf die letzte würde ich das Projekt stattdessen in separate Komponenten aufteilen. Ich habe nie auf einem so großen projet gearbeitet, die maximale Anzahl der Entwickler ich auf dem bekam gleiche Projekt zwei Dutzend.
@Pierre. Es ist durchaus sinnvoll, das Projekt in einzelne Komponenten zu unterteilen. Da Linux ein monolithischer Kernel ist, bedeutet dies (im Wesentlichen), dass alle Gerätetreiber im selben Repository entwickelt werden müssen, auch wenn es sich im Wesentlichen um ein separates Projekt handelt. Gleichzeitig möchten sie die Flexibilität erfahrener Architekten nutzen, um weitreichende Änderungen vorzunehmen, die alle diese Treiber betreffen. Daher wird es schwierig sein, sie in verschiedene Repositorys aufzuteilen. Daher eignen sich Git (und Leutnants) gut für die Bewältigung dieser unterschiedlichen Anliegen.
Ken Bloom
Es könnte Sie auch interessieren, was Martin Fowler über SVN versus Git- und Mercurial-Workflows zu sagen hat. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom
2
Ich mache regelmäßig Halbierungen auf SVN, um Fehler zu finden. Der einzige Unterschied zu Git ist, dass nicht alles automatisch abläuft. Dies allein würde jedoch nicht ausreichen, um zu wechseln.
Xavier Nodet
1
Die Relevanz von Git-Bisect für kleine Teams ist nahezu gleich Null. Ich verstehe es für den Kernel, in dem Hunderte von Änderungen von verschiedenen Leuten auf einmal zusammengeführt werden und Dinge brechen, aber wenn Sie ein 5-köpfiges Team haben, können Sie normalerweise alle bis auf 2-3 potenzielle Täter-Patches mit einem kurzen Blick auf das beseitigen Log.
blucz
2

Warum man sie nicht im Tandem benutzt? Bei meinem aktuellen Projekt sind wir gezwungen, CVS zu verwenden. Wir behalten jedoch auch lokale Git-Repositories bei, um die Entwicklung von Features zu ermöglichen. Dies ist das Beste aus beiden Welten, da Sie verschiedene Lösungen ausprobieren und Versionen Ihrer Arbeit auf Ihrem eigenen Computer behalten können. Auf diese Weise können Sie ein Rollback auf frühere Versionen Ihrer Funktion durchführen oder verschiedene Ansätze ausprobieren, ohne Probleme zu bekommen, wenn Sie Ihren Code durcheinander bringen. Ein zentrales Repository bietet Ihnen dann die Vorteile eines zentralen Repositorys.

Vadim
quelle
Aber Sie können einfach ein zentrales Repository mit einem DVCS einrichten (und Berechtigungen genauso genau steuern wie mit einem CVCS. Was sind die Vorteile?
naught101
Richtig, aber die Einrichtung zentraler Git-Repositorys ist möglicherweise schwierig, wenn Sie sich in einer Windows-Umgebung befinden. Ich denke, das ist so ziemlich das Einzige, an das ich denken konnte. Wir waren gezwungen, CVS auf Unternehmensebene zu verwenden, sodass wir nicht wirklich die Wahl hatten.
Vadim
1

Ich habe keine persönlichen Erfahrungen mit DVCS, aber nach den hier gegebenen Antworten und einigen verknüpften Dokumenten ist der grundlegendste Unterschied zwischen DVCS und CVCS das verwendete Arbeitsmodell

DVCS

Das Arbeitsmodell von DVCS ist, dass Sie eine isolierte Entwicklung durchführen . Sie entwickeln Ihre neue Funktion / Ihren neuen Bugfix isoliert von allen anderen Änderungen, bis Sie beschließen, ihn für den Rest des Teams freizugeben. Bis dahin können Sie nach Belieben einchecken, da sich sonst niemand darum kümmert.

CVCS

Das Arbeitsmodell von CVCS (insbesondere Subversion) besteht darin, dass Sie eine kollaborative Entwicklung durchführen . Sie entwickeln Ihr neues Feature / Bugfix in direkter Zusammenarbeit mit allen anderen Teammitgliedern und alle Änderungen sind sofort für alle verfügbar.

Andere Unterschiede

Andere Unterschiede zwischen svnund git/ hg, wie z. B. Revisionen gegenüber Änderungssätzen, sind zufällig. Es ist sehr gut möglich, ein DVCS basierend auf Revisionen (wie Subversion sie hat) oder ein CVCS basierend auf Changesets (wie Git / Mercurial sie haben) zu erstellen.

Ich werde kein bestimmtes Tool empfehlen, da es hauptsächlich vom Arbeitsmodell abhängt, mit dem Sie (und Ihr Team) am besten vertraut sind.
Persönlich habe ich keine Probleme mit der Arbeit mit einem CVCS.

  • Ich habe keine Angst, Sachen einzuchecken, da ich keine Probleme habe, sie in einen unvollständigen, aber kompilierbaren Zustand zu bringen.
  • Als ich merge-hell erlebte, war es in Situationen, in denen es in beiden svnund git/ oder vorgekommen wäre hg. Zum Beispiel wurde V2 einiger Software von einem anderen Team unter Verwendung eines anderen VCS gewartet, während wir V3 entwickelten. Gelegentlich mussten Bugfixes aus dem V2-VCS in das V3-VCS importiert werden, was im Grunde ein sehr umfangreiches Einchecken in das V3-VCS bedeutete (mit allen Bugfixes in einem einzigen Änderungssatz). Ich weiß, es war nicht ideal, aber es war eine Entscheidung des Managements, verschiedene VCS-Systeme zu verwenden.
Bart van Ingen Schenau
quelle
Ich denke nicht, dass die isolierte Entwicklung tatsächlich das Arbeitsmodell von DVCS ist. Ein wichtiges Merkmal eines DVCS ist, dass andere Mitglieder des Teams Ihre lokalen Änderungen abrufen oder Ihr lokales Repository klonen können. Sie verpflichten sich, wann immer Sie möchten, Ihre Änderungen sind immer verfügbar, und Ihre Fehler können keine Massenverwüstung verursachen.
Philosodad
@philosodad: Wenn andere Code aus meinem Repository abrufen, ohne den Status dieses Codes zu kennen, kann dies dennoch zu Chaos führen. Der einzige Unterschied ist, in wessen Verantwortung es liegt. Und mein Code ist nicht immer verfügbar. Das hängt immer noch davon ab, ob meine Systeme für den Zugriff von außen konfiguriert sind.
Bart van Ingen Schenau
Wenn Benutzer Code aus Ihrem Repository abrufen und mit ihrem eigenen zusammenführen, können sie unabhängig und ohne größere Probleme einen Rollback durchführen . Zweitens können Sie sich selbst die Isolation aufzwingen, wenn Sie den Zugriff auf Ihre Codebasis verweigern und eine wichtige Funktion des Systems lähmen . Dies unterscheidet sich stark von einem System, das für die isolierte Entwicklung modelliert wird . DVCS geht nicht. Ihr Verständnis des DVCS-Arbeitsmodells ist einfach falsch.
philosodad
1
@philosodad: Ich glaube, ich fange an, es besser und besser zu verstehen: Jeder kann dein Durcheinander bekommen, genau wie in einem CVCS, aber es ist nicht länger deine Schuld, weil du es ihnen nicht aufgedrängt hast. :-)
Bart van Ingen Schenau
Naja, so ungefähr. In der Regel klont oder verzweigt Alice jedoch zuerst und führt dann Ihre Änderungen zusammen. Dadurch wird es einfacher, so zu tun, als hätte sie Ihren Buggy-Code überhaupt nicht gesehen.
Philosodad