In meiner Organisation möchten wir aus verschiedenen Gründen von CVS zu Mercurial wechseln. Wir haben viele Nachforschungen angestellt, um herauszufinden, wie wir unsere Hg-Repositories organisieren sollten, basierend auf dem, was wir in unserer Codebasis haben und wie wir dazu neigen, zu arbeiten. Wir haben zufriedenstellende Antworten auf die meisten unserer Fragen gefunden, aber es gibt einen Punkt, der uns ein wenig stört, und es macht mich wahnsinnig, weil die bequemste Art, das Repo für unseren Workflow zu organisieren, einfach der falsche Weg ist ein konzeptioneller Standpunkt. Ich versuche herauszufinden, ob unsere Wahrnehmung davon, wie dies "funktionieren" soll, falsch ist oder ob wir nur mit einer legitimen Merkmalslücke in den verfügbaren Werkzeugen kollidieren.
In erster Linie unterhalten wir eine mittelgroße Codebasis, die aus einer Reihe von Anwendungen besteht, die alle im selben Paket veröffentlicht werden. Konzeptionell können Sie unseren Code in drei Kategorien einteilen:
Das scheint mir nicht ungewöhnlich, aber ich möchte betonen, dass wir den Anwendungscode und den gemeinsamen Code gleichzeitig pflegen und immer im Einklang mit einander stehen sollen. Das heißt, wir möchten, dass alle unsere Anwendungs-Builds immer die neueste Version und die gleiche Version des gemeinsamen Codes verwenden. Wir fügen häufig Anwendungscode und gemeinsam genutzten Code hinzu oder ändern ihn gleichzeitig. Gegenwärtig befindet sich der gemeinsame Code in einem CVS-Modul und die Anwendungen sind alle in ihren eigenen separaten Modulen. Die gemeinsam genutzten Code- und Anwendungsmodule werden ausgecheckt, so dass der gemeinsam genutzte Code einmal erstellt und dann in jede Anwendung eingebunden wird. Wir machen häufig cvs-Commits, die Änderungen zwischen gemeinsam genutzten Modulen und Anwendungsmodulen gleichzeitig beinhalten. Wir möchten diese Fähigkeit wirklich behalten.
Ich verstehe, dass Commits in Hg atomar innerhalb von Repositories sind - das ist in Ordnung, aber ich würde gerne in der Lage sein, zu einer Applikation und einer gemeinsam genutzten Bibliothek zu "derselben Zeit" zu differentieren (dh es ist mir egal es ist wirklich atomar, aber ich möchte nicht manuell zwei separate Diffs und zwei separate Commit-Aktionen machen müssen.)
Vom Konzept her scheint es richtig zu sein, ein oder mehrere Repos für den gemeinsamen Code und ein separates Repo für jede Anwendung und jedes kleine Hilfsprogramm zu haben. Das bedeutet, dass Sie für jeden Build mehrere Repos auschecken müssen, aber das ist kein Problem für uns. Das Problem ist, dass es keine Tools gibt, mit denen Sie Updates oder Änderungen für mehrere Repos gleichzeitig anzeigen oder mehrere Repos auf einmal synchronisieren und dann sequenziell für Sie speichern können. Dies wäre einfach zu schreiben, aber das würde Entwicklern, die verschiedene GUI-Frontends zur Ergänzung der Befehlszeile verwenden möchten, nicht helfen.
Es scheint so zu sein, dass, um in der Lage zu sein, sich über mehrere Codebasen gleichzeitig (aus der Sicht eines Benutzers) zu verpflichten und alles auf dem neuesten Stand zu halten, die einzigen beiden Lösungen sind:
Es kann nicht so ungewöhnlich sein, mit mehreren "gleichaltrigen" Repositories gleichzeitig arbeiten zu wollen, auch wenn die Aktionen nicht wirklich atomar sind - und trotzdem finde ich nicht viele Artikel oder posts, die nach dieser Fähigkeit verlangen.
Zusammenfassend:
Was fehlt mir hier?
In meinem Geschäft haben wir viele Projekte, die einfach in separaten Repos sind, aber das Repo der Hauptanwendung enthält zwei weitere Projekte. Eines ist ein Modul, das eine große Menge Code mit der Hauptanwendung teilt, und das andere ist für Datenbankmigrationen für die Anwendung (es ist sogar in einer anderen Sprache). Ich wollte damit zusammenhängende Änderungen sowohl in der Anwendung als auch im Migrator untrennbar miteinander verbinden. Insgesamt liegen alle Quelldateien in diesem Repo zwischen 10 und 11 MB.
Wenn also alles in ein Repository passt, ist es sinnvoll, weil Sie nicht mit Unterlagern arbeiten wollen, dann ist nichts falsch daran, alles in ein Repository zu stellen. Der eine von mir ist meiner Meinung nach auf der kleinen Seite des Mediums. TortoiseHgs Quelle ist ungefähr 20 MB, OGRE ist über 100 MB.
Ohne mehr über Ihre Projekte und deren Beziehungen zu wissen, ist der Eindruck, dass ein einzelnes Repository gut funktionieren würde und Sie es nicht falsch sehen.
Wenn Sie Ihre Meinung ändern, kann hg convert Ihnen dabei helfen, Projekte in ihr eigenes Repository zu extrahieren und den Verlauf von diese Dateien.
Wenn der One-Repository-Ansatz nicht für Sie ist, dann denke ich subrepos sollte eine Chance erhalten, da dies die einzige andere Methode ist, die ich kenne, um mehrere Repos kohäsiv zu behandeln, die in TortoiseHg unterstützt wird (siehe Empfehlungen Abschnitt).
Allerdings bin ich mir nicht sicher, wie Sie mit dem abteilungsübergreifenden Zugriff umgehen würden, da es nicht scheint, dass es bereits eine etablierte Teilmenge gibt, die mit anderen geteilt wird.
Tags und Links mercurial