Übertragen der Legacy-Codebasis von cvs auf verteiltes Repository (zB git oder mercurial). Vorschläge, die für das anfängliche Repository-Design benötigt werden [closed]

Einführung und Hintergrund

Wir sind dabei, das Quellcodeverwaltungssystem zu ändern, und evaluieren derzeit Git und Mercurial. Die gesamte Codebasis umfasst etwa 6 Millionen Codezeilen, also nicht massiv und auch nicht wirklich klein.

Lassen Sie mich zunächst mit einer sehr kurzen Einführung in das aktuelle Repository-Design beginnen.

Wir haben einen Basisordner für die vollständige Codebasis, und unterhalb dieser Ebene befinden sich alle möglichen Module, die in verschiedenen Kontexten verwendet werden. Beispielsweise können „dllproject1“ und „dllproject2“ als vollständig getrennte Projekte betrachtet werden.

Die Software, die wir entwickeln, nennen wir einen Konfigurator, der endlos an unterschiedliche Kundenbedürfnisse angepasst werden kann. Insgesamt haben wir wahrscheinlich 50 verschiedene Versionen davon. Eines haben sie jedoch gemeinsam. Sie alle teilen sich ein paar obligatorische Module (mandatory_module1 ..). Diese Ordner enthalten im Wesentlichen Kernel-/Core-Code und gemeinsame Sprachressourcen usw. Alle Anpassungen können dann beliebig zwischen den anderen Modulen kombiniert werden (module1 ..).

Da wir derzeit cvs verwenden, haben wir Aliase in der Datei CVSROOT/modules hinzugefügt. Sie könnten etwa so aussehen:

core –a mandatory_module1 mandatory_module2 mandatory_module3
project_x –a module1 module3 module5 core

Wenn sich also jemand entscheidet, an project_x zu arbeiten, kann er/sie schnell die Module auschecken, die benötigt werden von:

base>cvs co project_x

Fragen

Intuitiv fühlt es sich einfach falsch an, den Basisordner als einzelnes Repository zu haben. Als Programmierer sollten Sie in der Lage sein, den genauen Code-Teilsatz zu überprüfen, der für das aktuelle Projekt, mit dem Sie arbeiten, benötigt wird. Was sind Ihre Gedanken dazu?

Andererseits fühlt es sich richtiger an, jedes dieser Module in separaten Repositories zu haben. Aber das erschwert es Programmierern, die benötigten Module auszuprobieren. Sie sollten dies mit einem einzigen Befehl tun können. Meine Frage lautet also: Gibt es ähnliche Möglichkeiten, Aliase in Git/Mercurial zu definieren?

Alle anderen Fragen, Anregungen, Hinweise sind sehr willkommen!

PS. Ich habe nach ähnlichen Fragen gesucht, aber nicht das Gefühl, dass eine davon zu 100 % auf meine Situation zutrifft.

Nur ein kurzer Kommentar, um Sie daran zu erinnern:

• Diese Migrationen bieten oft die Möglichkeit, die Quellen neu zu organisieren, nicht entlang von Modulen (jeweils mit einem Repository), sondern entlang einer funktionalen Domänenaufteilung (mehrere Module für dieselbe bestimmte funktionale Domäne werden in dasselbe Repository gestellt).

Dann Submodule verwendet werden sollen, um eine Konfiguration zu definieren.

• Git ist in Ordnung, aber von Linus’ Eingeständnis selbstalles in ein Repository zu packen, kann problematisch sein.

[…] CVS, dh es orientiert sich am Ende wirklich ziemlich stark an einem “Eine-Datei-zu-einer-Zeit”-Modell.

Was insofern schön ist, als Sie eine Million Dateien haben und dann nur ein paar davon auschecken können – Sie werden es nie tun sehen die Auswirkungen der anderen 999.995 Dateien.

Git betrachtet grundsätzlich nie weniger als das gesamte Repo. Selbst wenn Sie die Dinge ein wenig einschränken (dh nur einen Teil auschecken oder die Historie nur ein wenig zurückgehen lassen), kümmert sich Git am Ende immer noch um die ganze Sache und trägt das Wissen herum.

Git skaliert also wirklich schlecht, wenn Sie es zwingen, alles als eins zu betrachten
enorm Repository. Ich glaube nicht, dass dieser Teil wirklich reparabel ist, obwohl wir ihn wahrscheinlich verbessern können.

Und ja, dann gibt es da noch die „Big File“-Probleme. Ich weiß wirklich nicht, was ich mit großen Dateien machen soll. Wir saugen an ihnen, ich weiß.

Diese beiden oben genannten Punkte sprechen für einen stärker komponentenorientierten Ansatz für große Systeme (und große Legacy-Repositorys).

Mit Git-Submodul, können Sie sie in Ihrem Projekt auschecken (auch wenn es sich um einen zweistufigen Prozess handelt). Sie haben jedoch Tools, die die Verwaltung der Submodule vereinfachen können (git.rake zum Beispiel).

Wenn ich daran denke, einen Fehler in einem Modul zu beheben, das von mehreren Projekten gemeinsam genutzt wird, behebe ich einfach den Fehler und übertrage ihn, und alle führen einfach ihre Aktualisierungen durch

Das ist es, was ich im Beitrag Vendor Branch als “Systemansatz” beschreibe: Jeder arbeitet am neuesten (HEAD) von allem, und es ist effektiv für eine kleine Anzahl von Projekten.
Für eine große Anzahl von Modulen ist der Begriff “Modul” jedoch immer noch sehr nützlich, aber seine Verwaltung ist nicht die gleiche wie bei DVCS:

• Für eng verwandte Module (auch bekannt als “in derselben Funktionsdomäne”, wie “alle Module im Zusammenhang mit PNL – Gewinn und Verlust – oder “Risikoanalyse” in einer Finanzdomäne) müssen Sie mit dem neuesten (HEAD) von arbeiten alle beteiligten Komponenten.
  Dies würde mit der Verwendung von a erreicht werden Teilbaum-Strategienicht damit Sie Korrekturen an diesen anderen Untermodulen veröffentlichen (pushen), sondern um die von anderen Teams durchgeführten Arbeiten zu verfolgen.
  Git ermöglicht das mit dem Extra-Bonus, dass dieses „Tracking“ nicht zwischen Ihrem Repository und einem „zentralen“ Repository stattfinden muss, sondern auch zwischen Ihnen und dem lokalen Repository des anderen Teams stattfinden kann, was ein sehr schnelles ermöglicht Hin- und Her-Integration und Testen zwischen Projekten ähnlicher Art.

• Für Module, die sich nicht direkt in Ihrer Funktionsdomäne befinden, sind Submodule jedoch eine bessere Option, da sie sich auf eine feste Version eines Moduls (ein Commit) beziehen:
  Wenn sich ein Low-Level-Framework ändert, möchten Sie nicht, dass es weitergegeben wird sofortda dies Auswirkungen auf alle anderen Teams hätte, die dann aufgeben müssten, was sie tun, um ihren Code an diese neue Version anzupassen (Sie möchten jedoch, dass alle anderen Teams über diese neue Version Bescheid wissen, damit sie dies tun können Vergessen Sie nicht, diese Low-Level-Komponente oder dieses “Modul” zu aktualisieren).
  Dadurch können Sie nur mit offiziell stabil identifizierten Versionen anderer Module arbeiten und nicht mit potenziell instabilen oder nicht vollständig getesteten HEADs.

Was die Mercurial-Seite betrifft, lautet die Empfehlung auch, große alte CVS/SVN-Repositories in kleinere Komponenten umzugestalten. Gemeinsamer Code sollte in seine eigenen Bibliotheken gestellt werden, und der Anwendungscode hängt dann von diesen Bibliotheken auf ähnliche Weise ab wie von anderen Bibliotheken.

Mercurial hat die Walderweiterung mit dem Sie einen “Wald” von “Quellbäumen” verwalten können. Bei diesem Ansatz kombinieren Sie mehrere kleinere Repositories zu einem größeren. Mit CVS machen Sie das Gegenteil: Sie checken einen kleineren Teil eines großen Repositorys aus.

Ich habe die Forest-Erweiterung nicht persönlich verwendet und ihre Seite sagt, dass man eine aktualisierte Version im Vergleich zu der mit Mercurial gebündelten verwenden sollte. Wie auch immer, es ist von einer großen Organisation wie Sun in seinem verwendet OpenJDK-Projekt.

Es wird derzeit auch daran gearbeitet, Sub-Repository-Berichte gemäß dem Design direkt zum Kern von Mercurial hinzuzufügen verschachtelte Repositories-Seite im Mercurial-Wiki.