Wir sind Subversion Geeks und möchten die Vorteile von Mercurial kennenlernen [closed]

Nachdem ich gelesen habe, dass ich ein Subversion-Freak bin, warum sollte ich Mercurial oder Git oder ein anderes DVCS in Betracht ziehen oder nicht .

Ich habe eine verwandte Folgefrage. Ich habe diese Frage gelesen und die empfohlenen Links und Videos gelesen. Ich sehe die Vorteile, aber ich sehe nicht, dass die Leute über die allgemeine Bewusstseinsveränderung sprechen.

Unser Team besteht aus 8-10 Entwicklern, die an einer großen Codebasis aus 60 Projekten arbeiten. Wir benutzen Subversion und haben einen Hauptstamm. Wenn ein Entwickler einen neuen Fogbugz-Fall startet, erstellt er eine SVN-Verzweigung, bearbeitet die Verzweigung und führt sie anschließend zum Stamm zurück. Gelegentlich bleiben sie längere Zeit auf dem Zweig und führen den Stamm mit dem Zweig zusammen, um die Änderungen zu übernehmen.

Als ich sah, wie Linus über Leute sprach, die einen Zweig gründeten und ihn nie wieder machten, waren wir das überhaupt nicht. Wir erstellen wahrscheinlich 50-100 Filialen pro Woche ohne Ausgabe. Die größte Herausforderung ist das Zusammenführen, aber wir sind auch ziemlich gut darin geworden. Ich neige dazu, durch fogbugz case & checkin statt der gesamten Wurzel des Zweigs zusammenzuführen.

Wir arbeiten niemals remote und machen niemals Zweige aus Zweigen. Wenn Sie der einzige sind, der in diesem Abschnitt der Codebasis arbeitet, verläuft die Zusammenführung zum Trunk reibungslos. Wenn eine andere Person denselben Codeabschnitt geändert hat, kann die Zusammenführung problematisch werden, und Sie müssen möglicherweise eine Operation durchführen. Konflikte sind Konflikte. Ich verstehe nicht, wie ein System es die meiste Zeit richtig machen könnte, wenn es nicht schlau genug wäre, den Code zu verstehen.

Nach dem Erstellen einer Verzweigung dauert das Auschecken von mehr als 60.000 Dateien einige Zeit. Dies ist jedoch ein Problem bei allen Versionsverwaltungssystemen, die wir verwenden würden.

Gibt es einen Vorteil von DVCS, den wir nicht sehen, der uns sehr helfen würde?

Um Ihre Frage zu formulieren: "Welche Vorteile hat DVCS, wenn wir nur die zentrale Verwendung von DVCS planen?" Wenn Sie es so fragen, tut es nicht. Ein Zweig pro Task ist in VCS sehr verbreitet. Wenn Sie darüber nachdenken, ist es ein Zweig, eine lokale Arbeitskopie des Quellcodes auf dem Computer eines Entwicklers zu haben, die sich für einen Tag unabhängig vom Trunk ändert, obwohl niemand dies so nennt. Der einzige Unterschied zu Ihrem Workflow besteht darin, dass Sie diesen Zweigen auch auf dem zentralen Server einen dauerhaften Namen geben. Das ist nicht die Art von Verzweigung, von der Linus und andere reden.

Um DVCS zu verstehen, ist ein grundlegendes Umdenken erforderlich. Sie müssen sich fragen, was Sie mit so vielen Zweigen tun würden, wie Sie möchten, die mit jedem geteilt werden, und nur mit ihnen. Dazu gehören auch Zweige, die nur von Ihnen selbst gesehen werden.

Die Möglichkeiten sind endlos. Wie wäre es zum Beispiel mit zwei Personen, die an gegenüberliegenden Seiten einer Benutzeroberfläche arbeiten? Sie müssen regelmäßig Code miteinander teilen, aber es ist noch nicht stabil genug, um ihn mit allen zu teilen. Sie können einen Zweig erstellen, um ihn untereinander zu teilen, und ihn dann wieder in das zentrale Repository einfügen, wenn er fertig ist.

Die Fähigkeit, lokale Commits zu tätigen, lohnt sich für sich. Das muss man einfach selbst erleben.

Die Geschwindigkeit, die Sie mit Ihrem Repo-Lokal erzielen, ist auch für sich allein wert. Ja, der anfängliche Klon wird in jedem VCS für ein 60k-Datei-Repo unvermeidlich langsam sein, aber sobald Sie das haben, ist das Auschecken eines neuen Zweigs mit einem DVCS um Größenordnungen schneller.

Für Ihren speziellen Fall ist der Wechsel zu einem DVCS nicht vorteilhaft. Sie sind mit Ihrem vorhandenen System zufrieden, es bietet alles, was Sie benötigen. Warum also wechseln? SVN ist immer noch ein aktives Open Source-Projekt und verfügt über bessere, ausgereiftere Integrationen mit allen wichtigen IDEs und Entwicklungswerkzeugen als hg oder git. Möchten Sie sich angesichts der Größe Ihres Teams und der Anzahl der Projekte wirklich die Zeit nehmen, um auf ein neues Tool umzusteigen, wenn das vorhandene gut funktioniert?

Wenn Sie Entwickler haben, die ohne DVCS einfach nicht funktionieren können, verweisen Sie sie auf die svn-Gateways für hg oder git. Machen Sie ihnen deutlich, dass ihre Eincheckvorgänge in das SVN-Repository den Verfahren und Prozessen entsprechen müssen, die der Rest des Teams verwendet. Ein weiterer Vorteil dieses Ansatzes ist, dass die wahren DVCS-Fanatiker, die die Gateways bereits nutzen, ohne es Ihnen mitzuteilen, jetzt aus dem Schrank kommen können :-).

Es scheint mir, dass Sie bereits einen Workflow verwenden, der dem Workflow sehr ähnlich ist, den viele Menschen nach dem Start eines DVCS anwenden.

Aus Ihrer Sicht bietet ein DVCS die folgenden wesentlichen Vorteile gegenüber SVN:

• Sobald Sie Ihre Repos geklont haben, können viele Operationen lokal ausgeführt werden.
  • Wenn Sie sich das Repository-Protokoll ansehen, müssen Sie den svn-Server nicht berühren. Dies kann unglaublich schnell sein.
  • Ebenso erfordert das Wechseln von Zweigen keinen Zugriff auf den Server und keine lokalen Klone.
• Da Zweige nur verschiedene Wege durch die Geschichte sind, wird das Repository nicht vollgestopft mit jedem Zweig jemand jeden erstellt (wir nur wirklich haben hat Release Niederlassungen in SVN, aber das branchesVerzeichnis hat noch viele Unterverzeichnisse , die nicht mehr relevant sind).
  • Wenn in git ein Zweig wieder zusammengeführt und der Verweis gelöscht wurde, kann es sein, dass Sie nie wissen, dass er überhaupt vorhanden ist.
  • In Mercurial haben Sie die Wahl, entweder eine Niederlassung Benennung (in diesem Fall ist es in jedem changeset in Permanenz codiert wird ) oder nur eine unbenannte (topologischen) Zweig zu schaffen, die ruhig wird verschmelzen in die Geschichte , wenn es merged zurück in default( trunk)
• In SVN sind Zweige von Zweigen viel zu dunkel, um nützlich zu sein. In gitund hgsie sind für den Kurs gerade üblich.
• DVCS hat verstanden, dass Softwareentwicklung eine DAG ist , dh wenn Sie zusammenführen, erhalten Sie ein Änderungsset mit mehreren Eltern. SVN (zumindest die Version, die ich verwendet habe) versteht das nicht wirklich.

Zu diesem letzten Punkt sagen Sie

Konflikte sind Konflikte. Ich verstehe nicht, wie ein System es die meiste Zeit richtig machen kann, wenn es nicht schlau genug ist, den Code zu verstehen.

Beim Umschalten von der Verwendung von hgausschließlich zur Verwendung von svnallein und dann gitsvnhat es meine Erfahrung, dass Verschmelzungen sind viel einfacher und störungsfrei mit hgund gitsvnals sie mit svn. Zusammenführungen mit svn(zumindest der von uns verwendeten Version) führen zu erheblich mehr Konflikten, die manuell gelöst werden müssen.

Einer der Gründe, warum Zusammenführungen in SVN schwieriger sind, besteht darin, dass Sie nur zwei Optionen für jede Zeile haben, die unterschiedlich ist.

• Der Text aus dem Zweig, in dem Sie zusammenführen
• Der Text aus dem Zweig, in dem Sie zusammenführen

Beim Zusammenführen von einem DVCS haben Sie in der Regel eine dritte Option:

• Der Text des gemeinsamen Vorfahren beider Zweige, die Sie zusammenführen

Unterschätzen Sie nicht, wie nützlich dies ist, denn es bietet Ihnen einen viel besseren Kontext für die Änderungen als ein einfacher Zwei-Wege-Diff.

Alles in allem würde ich vorschlagen, dass Sie es versuchen. Mit Tools wie gitsvnund hgsubversionkönnen Sie sie sogar mit Ihren aktuellen SVN-Repos ausprobieren .

^{Beachten Sie, dass das Erstellen des Klons an erster Stelle eine königliche PItA ist. Sobald Sie dies jedoch getan haben, erhalten Sie die größte Leistung eines DVCS mit Ihrem vorhandenen CVCS.}

Es gibt eine wichtige Änderung, die ich nach einem solchen Übergang bemerkt habe: Ich wechsle viel häufiger die Filiale, und ich verpflichte mich häufiger, als ich es mir jemals mit Subversion leisten konnte. Zum Beispiel gibt es eine Reihe winziger Funktionszweige, die in einer Abfolge angeordnet sind, und ich kann Monate damit verbringen, Bits zu jedem von ihnen hinzuzufügen, um sie alle nacheinander einem sich ständig ändernden Stamm zuzuordnen. Es ist trivial, die Reihenfolge der Zusammenführung von Funktionszweigen zu ändern.

Tatsächlich bin ich jedoch nicht von Subversion abgewichen. Ich benutze nur Git als mein lokaler SVN-Client.