Jak korzystać z subpunktów rtęciowych dla współużytkowanych komponentów i zależności?

Tworzymy oprogramowanie .NET Enterprise w języku C #. Staramy się ulepszyć nasz system kontroli wersji. Używałem już mercurialu i eksperymentowałem z nim w naszej firmie. Ponieważ jednak rozwijamy produkty dla przedsiębiorstw, koncentrujemy się na komponentach lub modułach wielokrotnego użytku. Próbowałem użyć repozytoriów mercurialu do zarządzania komponentami i zależnościami, ale mam pewne trudności. Oto podstawowe wymagania dotyczące kontroli źródła / zarządzania zależnością:

Komponenty wielokrotnego użytkuWspółdzielone przez źródło (do debugowania)Mieć zależności od plików binarnych innych firm i innych komponentów wielokrotnego użytkuMożna je rozwijać i angażować do kontroli źródeł w kontekście zużywającego się produktuZależnościProdukty mają zależności od plików binarnych innych firm i innych komponentów wielokrotnego użytkuZależności mają swoje własne zależnościProgramiści powinni być powiadamiani o konfliktach wersji w zależnościach

Oto struktura rtęciowa, której używałem:

Element wielokrotnego użytku:

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

Drugi komponent wielokrotnego użytku, zużywający pierwszy:

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

Produkt, który zużywa oba składniki:

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

UwagiRepos są w CAPSPrzyjmuje się, że wszystkie repozytoria dziecięce są subreposBiblioteki innych firm (binarne) i komponenty wewnętrzne (źródłowe) są wszystkimi pod-obiektami znajdującymi się w folderze libsBiblioteki innych firm są przechowywane w indywidualnych repozycjach rtęciowych, dzięki czemu konsumujące projekty mogą odwoływać się do konkretnych wersji bibliotek (tj. Stary projekt może odwoływać się do NLog v1.0, a nowszy może odwoływać się do NLog v2.0).Wszystkie pliki Visual Studio .csproj znajdują się na czwartym poziomie (foldery proj *), co pozwala na względne odniesienia do zależności (np. ../../../Libs/NLog/NLog.dll dla wszystkich projektów Visual Studio, które odwołują się do NLog)Wszystkie pliki Visual Studio .sln znajdują się na drugim poziomie (foldery src), więc nie są uwzględniane podczas „udostępniania” komponentu w konsumującym komponencie lub produkcieDeweloperzy mogą dowolnie organizować swoje pliki źródłowe, jeśli uznają to za stosowne, o ile źródłami są dzieci z folderu proj * konsumującego programu Visual Studio (tzn. Może być n dzieci w folderach proj * zawierających różne źródła / zasoby)Jeśli Bob rozwija komponent SHARED2 i produkt PROD1, to całkowicie legalne jest, aby wprowadzał zmiany w źródle SHARED2 (powiedzmy źródła należące do proj3) w repozytorium PROD1_SLN i zatwierdził te zmiany. Nie mamy nic przeciwko, jeśli ktoś opracuje bibliotekę w kontekście konsumpcyjnego projektu.Komponenty opracowane wewnętrznie (SHARED1 i SHARED2) są zazwyczaj uwzględniane przez źródło w projekcie konsumującym (w Visual Studio dodanie odwołania do projektu zamiast przeglądania do dll). Pozwala to na ulepszone debugowanie (przejście do kodu biblioteki), pozwala Visual Studio zarządzać, gdy trzeba przebudować projekty (gdy modyfikacje są modyfikowane), i pozwala na modyfikację bibliotek, gdy jest to wymagane (jak opisano w powyższej uwadze).pytania

Jeśli Bob pracuje nad PROD1 i Alice pracuje nad SHARED1, jak Bob może wiedzieć, kiedy Alicja zatwierdza zmiany w SHARED1. Obecnie z Mercurialem Bob jest zmuszony do ręcznego pobierania i aktualizowania w ramach każdego podporządkowania. Jeśli pcha / ściąga na serwer z repozytorium PROD_SLN, nigdy nie wie o aktualizacjach subrepos. Jest to opisane wMercurial wiki. W jaki sposób Bob może być powiadamiany o aktualizacjach subrepos, gdy pobiera z serwera najnowszą wersję PROD_SLN? W idealnej sytuacji powinien on zostać powiadomiony (najlepiej podczas ściągania), a następnie musi ręcznie zdecydować, które subpunkty chce zaktualizować.

Załóżmy, że SHARED1 odwołuje się do NLog v1.0 (commit / rev abc w mercurial) i SHARED2 odwołań do Nlog v2.0 (commit / rev xyz in mercurial). Jeśli Bob pochłania te dwa składniki w PROD1, powinien zostać poinformowany o tej rozbieżności. Chociaż technicznie Visual Studio / .NET pozwalałby 2 zestawom odwoływać się do różnych wersji zależności, moja struktura nie pozwala na to, ponieważ ścieżka do NLog jest poprawiona dla wszystkich projektów .NET zależnych od NLog. Jak Bob może wiedzieć, że dwie jego zależności mają konflikty wersji?

Jeśli Bob konfiguruje strukturę repozytorium dla PROD1 i chce dołączyć SHARED2, jak może wiedzieć, jakie zależności są wymagane dla SHARED2? W mojej strukturze musiałby ręcznie klonować (lub przeglądać na serwerze) repozytorium SHARED2_SLN i albo przeglądać folder libs, albo szczyt w pliku .hgsub, aby określić, jakie zależności powinien uwzględnić. Idealnie byłoby to zautomatyzowane. Jeśli dołączę SHARED2 do mojego produktu, SHARED1 i NLog są również automatycznie magicznie uwzględniane, powiadamiając mnie, jeśli występuje konflikt wersji z inną zależnością (patrz pytanie 2 powyżej).

Większe pytania

Czy rtęć jest właściwym rozwiązaniem?

Czy istnieje lepsza struktura rtęciowa?

Czy jest to poprawne użycie dla subpunktów (tj. Oznaczonych programistów Mercurial)subrepos jako cecha ostatniej szansy)?

Czy warto używać mercuriala do zarządzania zależnością? Moglibyśmy użyć jeszcze jednego narzędzia do zarządzania zależnością (być może wewnętrznego kanału NuGet?). Chociaż działałoby to dobrze w przypadku zależności od firm trzecich, naprawdę spowodowałoby to kłopoty z wewnętrznie opracowanymi komponentami (tzn. Jeśli są aktywnie rozwijane, programiści musieliby stale aktualizować kanał, musielibyśmy je obsługiwać wewnętrznie, a to nie pozwoliłoby komponenty, które mają być modyfikowane przez konsumpcyjny projekt (Uwaga 8 i Pytanie 2).

Czy masz lepsze rozwiązanie dla projektów oprogramowania Enterprise .NET?

Referencje

Przeczytałem kilka pytań dotyczących SO i znalazłemten być pomocnym, alezaakceptowana odpowiedź sugeruje użycie dedykowanego narzędzia do zależności. Chociaż podoba mi się cechy takiego narzędzia, nie pozwala na modyfikowanie i zatwierdzanie zależności z konsumującego projektu (patrz Większe pytanie 4).