Best Practices für Projekt-Feature-Submodule mit Mercurial und Eclipse?

Question

Ich habe ein paar ANT-Projekte für verschiedene Kunden; die Verzeichnisstruktur ich für meine Projekte habe wie folgt aussieht:

L___standard_workspace 
    L___.hg 
    L___validation_commons-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___old_stuff 
    | L___src 
    | | L___css 
    | | L___js 
    | |  L___validation_commons 
    | L___src-test 
    |  L___js 
    L___v_file_attachment-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    | | L___css 
    | | L___js 
    | L___src-test 
    |  L___js 
    L___z_business_logic-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    |  L___css 
    |  L___js 
    L____master-proj    <- Master web-deployment module where js libraries are compiled to. 
     L___docs 
     L___java 
     | L___jar 
     | L___src 
     |  L___AntTasks 
     |   L___build 
     |   | L___classes 
     |   |  L___com 
     |   |   L___company 
     |   L___dist 
     |   L___nbproject 
     |   | L___private 
     |   L___src 
     |    L___com 
     |     L___company 
     L___remoteConfig 
     L___src 
     | L___css 
     | | L___blueprint 
     | | | L___plugins 
     | | | | L___buttons 
     | | | | | L___icons 
     | | | | L___fancy-type 
     | | | | L___link-icons 
     | | | | | L___icons 
     | | | | L___rtl 
     | | | L___src 
     | | L___jsmvc 
     | L___img 
     | | L___background-shadows 
     | | L___banners 
     | | L___menu 
     | L___js 
     | | L___approve 
     | | L___cart 
     | | L___confirm 
     | | L___history 
     | | L___jsmvc 
     | | L___mixed 
     | | L___office 
     | L___stylesheets 
     | L___swf 
     L___src-standard 

Innerhalb der Arbeitskopie der Module das Teilprojekt in eine einzige Javascript-Datei erstellen, die in dem Javascript-Verzeichnis des Master-Projektes gelegt wird.

Zum Beispiel, die Verzeichnisse:

• validation_commons-sub-proj
• v_file_attachment-sub-proj
• z_business_logic-sub-proj

... alle werden kombiniert und minimierte (Art wie kompiliert) in eine andere Javascript-Dateiname im Verzeichnis _master-proj/js; und im letzten Schritt wird die _master-proj kompiliert, um auf dem Server bereitgestellt zu werden.

Jetzt in Bezug auf die Art, wie ich dies mit hg einrichten möchte, was ich gerne in der Lage wäre zu klonen das Master-Projekt und seine Unterprojekte von ihren eigenen Baseline-Repositories in ein Arbeitskopie des Clients, so dass Module (mit hg) der Arbeitskopie eines bestimmten Kunden hinzugefügt werden können.

Wenn ich jedoch einige Änderungen an der Arbeitskopie eines Kunden vorgenommen habe, würde ich gerne in der Lage sein, die Änderungen/Fehlerkorrekturen zurück ins Stammprojekt des Hauptprojekts/Unterprojekts zu schieben , um schließlich die Änderungen/Fixes in Arbeitskopien anderer Kunden zu übernehmen, die dieselben Fehler enthalten könnten, die behoben werden müssen.

Auf diese Weise kann ich die gleichen Fehlerbehebungen über verschiedene Clients hinweg verwenden.

Allerdings ... Ich bin mir nicht sicher über die beste Möglichkeit, dies mit HG und Eclipse zu tun.

I , dass Sie hgs Convert Extension verwenden können, um ein Unterverzeichnis in ein separates Projekt unter Verwendung der Option aufzuteilen.

Allerdings bin ich immer noch ein wenig verwirrt darüber, ob es besser wäre, die Convert Extension zu verwenden, oder ob es besser wäre, jedes der Module in seinem eigenen Repository zu speichern und sie in einem einzigen Arbeitsbereich auszuchecken für jeden Kunden.

Answer 1

Ja, es sieht aus wie subrepos sind, was Sie suchen, aber ich denke, vielleicht, dass die richtige Antwort für die falsche Frage ist, und ich vermute stark, dass Sie ähnlich laufen würden in issues that occur when using svn:externals

Stattdessen würde ich empfehlen, dass Sie Ihre kombinierten und minimierten JS-Dateien an eine artefact repository "veröffentlichen" und einen Abhängigkeitsmanager wie Ivy verwenden, um bestimmte Versionen Ihrer Artefakte in Ihr Master-Projekt zu übernehmen. Dieser Ansatz ermöglicht Ihnen eine bessere Kontrolle über die Teilprojektversionen, die Ihr Master-Projekt verwendet.

Wenn Sie für einen bestimmten Client Fehlerkorrekturen an einem Unterprojekt vornehmen müssen, können Sie einfach die Fehlerkorrekturen in der Hauptleitung für dieses Unterprojekt vornehmen, eine neue Version veröffentlichen (idealerweise über automated build pipeline) und ihren Master aktualisieren Projekt, um die neue Version zu verwenden. Oh, du wolltest die neue Version mit dem Master-Projekt testen bevor du veröffentlichst?In diesem Fall, bevor Sie Ihren Fix verschieben, kombinieren und minimieren Sie Ihr Unterprojekt lokal, veröffentlichen Sie es in einem local repository und lassen Sie das Master-Projekt des Clients diese Version für Ihre Tests abholen.