Wie verwende ich Mercurial Subrepos für gemeinsam genutzte Komponenten und Abhängigkeiten?

Wir entwickeln .NET Enterprise Software in C #. Wir möchten unser Versionskontrollsystem verbessern. Ich habe schon einmal Quecksilber verwendet und bei uns experimentiert. Da wir jedoch Unternehmensprodukte entwickeln, konzentrieren wir uns auf wiederverwendbare Komponenten oder Module. Ich habe versucht, die Sub-Repos von mercurial zu verwenden, um Komponenten und Abhängigkeiten zu verwalten, habe aber einige Schwierigkeiten. Hier sind die grundlegenden Anforderungen für die Quellcodeverwaltung / das Abhängigkeitsmanagement:

Wiederverwendbare KomponentenGeteilt nach Quelle (zum Debuggen)Abhängigkeiten zu Binärdateien von Drittanbietern und anderen wiederverwendbaren KomponentenKann im Kontext eines konsumierenden Produkts entwickelt und zur Quellcodeverwaltung verpflichtet werdenAbhängigkeitenProdukte sind von Binärdateien von Drittanbietern und anderen wiederverwendbaren Komponenten abhängigAbhängigkeiten haben ihre eigenen AbhängigkeitenEntwickler sollten über Versionskonflikte in Abhängigkeiten informiert werden

Hier ist die Struktur in Quecksilber, die ich verwendet habe:

Eine wiederverwendbare Komponente:

SHARED1_SLN-+-docs
            |
            +-libs----NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED1-+-proj1
            |                 +-proj2
            |
            +-tools---NANT

Eine zweite wiederverwendbare Komponente, die die erste verbraucht:

SHARED2_SLN-+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED2-+-proj3
            |                 +-proj4
            |
            +-tools---NANT

Ein Produkt, das beide Komponenten verbraucht:

PROD_SLN----+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-SHARED2-+-proj3
            |       |         +-proj4
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----prod----+-proj5
            |                 +-proj6
            |
            +-tools---NANT

AnmerkungenRepos sind in CAPSEs wird davon ausgegangen, dass alle untergeordneten Repos Unterrepos sind(Binär-) Bibliotheken von Drittanbietern und interne (Quell-) Komponenten sind alle Subrepos, die sich im Ordner libs befindenBibliotheken von Drittanbietern werden in einzelnen Mercurial Repos aufbewahrt, sodass konsumierende Projekte auf bestimmte Versionen der Bibliotheken verweisen können (d. H. Ein altes Projekt verweist möglicherweise auf NLog v1.0, und ein neueres Projekt verweist möglicherweise auf NLog v2.0).Alle Visual Studio-CSPROJ-Dateien befinden sich auf der 4. Ebene (proj * -Ordner) und ermöglichen relative Verweise auf Abhängigkeiten (d. H. ../../../Libs/NLog/NLog.dll für alle Visual Studio-Projekte, die auf NLog verweisen).Alle .sln-Dateien von Visual Studio befinden sich auf der 2. Ebene (src-Ordner), sodass sie nicht enthalten sind, wenn eine Komponente für eine konsumierende Komponente oder ein konsumierendes Produkt freigegeben wirdEntwickler können ihre Quelldateien nach Belieben organisieren, sofern die Quellen untergeordnete Elemente des proj * -Ordners des konsumierenden Visual Studio-Projekts sind (d. H. Die proj * -Ordner können n untergeordnete Elemente enthalten, die verschiedene Quellen / Ressourcen enthalten).Wenn Bob eine SHARED2-Komponente und ein PROD1-Produkt entwickelt, ist es für ihn völlig legal, Änderungen an der SHARED2-Quelle (z. B. Quellen, die zu proj3 gehören) im PROD1_SLN-Repository vorzunehmen und diese Änderungen festzuschreiben. Es macht uns nichts aus, wenn jemand im Rahmen eines aufwendigen Projekts eine Bibliothek aufbaut.Intern entwickelte Komponenten (SHARED1 und SHARED2) werden im Allgemeinen nach Quelle in das konsumierende Projekt einbezogen (in Visual Studio wird ein Verweis auf ein Projekt hinzugefügt, anstatt zu einem DLL-Verweis zu navigieren). Dies ermöglicht ein erweitertes Debugging (Einstieg in den Bibliothekscode), ermöglicht es Visual Studio, zu verwalten, wann Projekte neu erstellt werden müssen (wenn Abhängigkeiten geändert werden), und ermöglicht das Ändern von Bibliotheken, wenn dies erforderlich ist (wie im obigen Hinweis beschrieben).Fragen

Wenn Bob an PROD1 und Alice an SHARED1 arbeitet, wie kann Bob wissen, wann Alice Änderungen an SHARED1 festschreibt? Derzeit ist Bob bei Mercurial gezwungen, jedes Subrepo manuell abzurufen und zu aktualisieren. Wenn er von PROD_SLN repo auf den Server pusht / zieht, weiß er nie etwas über Aktualisierungen von Subrepos. Dies ist beschrieben unterMercurial Wiki. Wie kann Bob über Aktualisierungen von Subrepos informiert werden, wenn er die neueste Version von PROD_SLN vom Server abruft? Im Idealfall sollte er benachrichtigt werden (vorzugsweise während des Pulls) und dann manuell entscheiden müssen, welche Subrepos aktualisiert werden sollen.

Angenommen, SHARED1 referenziert NLog v1.0 (Commit / Rev. abc in Mercurial) und SHARED2 referenziert Nlog v2.0 (Commit / Rev. xyz in Mercurial). Wenn Bob diese beiden Komponenten in PROD1 aufnimmt, sollte er auf diese Diskrepanz aufmerksam gemacht werden. Obwohl Visual Studio / .NET technisch 2 Assemblys erlauben würde, auf unterschiedliche Versionen von Abhängigkeiten zu verweisen, lässt meine Struktur dies nicht zu, da der Pfad zu NLog für alle .NET-Projekte, die von NLog abhängen, festgelegt ist. Woher weiß Bob, dass zwei seiner Abhängigkeiten Versionskonflikte aufweisen?

Wenn Bob die Repository-Struktur für PROD1 einrichtet und SHARED2 einbeziehen möchte, wie kann er wissen, welche Abhängigkeiten für SHARED2 erforderlich sind? Mit meiner Struktur müsste er das SHARED2_SLN-Repo manuell klonen (oder auf dem Server durchsuchen) und entweder in den libs-Ordner schauen oder in der .hgsub-Datei nachsehen, um zu bestimmen, welche Abhängigkeiten er einbeziehen muss. Im Idealfall wäre dies automatisiert. Wenn ich SHARED2 in mein Produkt einbinde, werden auch SHARED1 und NLog automatisch einbezogen, um mich zu benachrichtigen, wenn ein Versionskonflikt mit einer anderen Abhängigkeit vorliegt (siehe Frage 2 oben).

Größere Fragen

Ist Quecksilber die richtige Lösung?

Gibt es eine bessere Quecksilberstruktur?

Ist dies eine gültige Verwendung für Subrepos (d. H. Mercurial-Entwickler markiert)?Subrepos als Merkmal des letzten Auswegs)?

Ist es sinnvoll, Mercurial für das Abhängigkeitsmanagement zu verwenden? Wir könnten noch ein anderes Tool für das Abhängigkeitsmanagement verwenden (vielleicht einen internen NuGet-Feed?). Während dies für Abhängigkeiten von Drittanbietern gut funktionieren würde, würde es tatsächlich Ärger für intern entwickelte Komponenten verursachen (dh, wenn sie aktiv entwickelt werden, müssten Entwickler den Feed ständig aktualisieren, wir müssten sie intern bereitstellen, und es würde nicht zulassen) Komponenten, die durch ein aufwendiges Projekt modifiziert werden sollen (Anmerkung 8 und Frage 2).

Haben Sie eine bessere Lösung für Enterprise .NET-Softwareprojekte?

Verweise

Ich habe mehrere SO-Fragen gelesen und gefundendieses hilfreich zu sein, aber dieakzeptierte Antwort schlägt vor, ein spezielles Tool für Abhängigkeiten zu verwenden. Obwohl mir die Funktionen eines solchen Tools gefallen, ist es nicht gestattet, Abhängigkeiten von einem umfangreichen Projekt zu ändern und zu übernehmen (siehe größere Frage 4).