Jak radzić sobie z Submodules Git w Visual Studio rozwiązań o innym układzie?

Question

Opracowujemy Visual Studio 2010 (w języku C#) i migrujemy jakiś czas temu z SVN do GIT. Teraz próbujemy podzielić nasze repozytorium (które jest dość duże - ~ 30 000 plików) na wiele repozytoriów git - po jednym dla każdego rozwiązania. Rozwiązania dzielą niektóre projekty, głównie biblioteki, które tworzymy w firmie i lubimy dodawać do nich wszystkie rozwiązania.

Nowe repozytoria mają płaski układ. Jeden podkatalog dla każdego projektu (wspólne projekty to podmoduły). W dużym starym repo, projekty są w strukturze drzewa.

Problem występuje z odniesieniami zewnętrznymi w submodułach. W nowych reposach ścieżką do odniesienia może być "...... libs \ someproject", podczas gdy w nowym layoucie właściwą ścieżką będzie ".. \ someproject".

Mieliśmy już kilka wojen edycyjnych w tej sprawie i nie chcemy więcej.

połowiczne rozwiązania mogłem pomyśleć:

• użytku „Reference” Ścieżki w ... csproj.user i uwzględniają ten plik z kontroli wersji (musi być przerobione dla każdego dewelopera i po każdym porządki reopsitory)

• użytku oddziałów dla każdej sytuacji i starają się uczyć wszyscy, gdzie „prawdziwe” commity powinien iść i gdzie „zmiana środowiska” commity powinien iść (submoduły nie są już najprostsze pojęcia ...)

• osadzonych binariów zamiast submodułów (ale co z rozwojem zmian w submodułach? co z różnymi wersjami log4net?)

Czy ktoś wie o rozsądnym rozwiązaniu?

Answer 1

Ponieważ jesteś z prośbą o rozsądnego rozwiązania, mogę tylko doradzić, aby zajrzeć do uruchomienia własnej usługi Nuget (patrzeć na http://www.MyGet.org inspiracji)

http://nuget.codeplex.com/

Answer 2

Użyj jednego submodułu do przechowywania wszystkich "popularnych bibliotek". Tylko jeden poziom. Ale powinieneś przenieść wspólne biblioteki jako usługi z dobrze zdefiniowanymi umowami. W ten sposób możesz stopniowo wprowadzać nowe wersje bez przestojów. W ten sposób masz tylko submoduł w każdym z nich, który zawiera umowy. Mogą to być interfejsy lub wiadomości.

Answer 3

Więc jeśli ja rozumiem poprawnie, problem polega na Visual Studio, a nie na Git? W takim przypadku użyj starej struktury drzewa, która działała w Visual Studio. Uczyń także strukturę podmodulkową strukturą drzewa. Zatem szczyt drzewa byłby jednym superpowodzeniem, którego sub-moduły (gałęzie) miałyby własne submikle, dopóki nie zejdziesz do liści twojego drzewa. Początkowo byłoby to trudne, ale powinno po prostu działać.

Answer 4

JEŚLI idziesz dalej drogą zarządzania paczkami, rozważ OpenWrap. Jednak osadzanie artefaktów zarządzania pakietami w kodzie źródłowym jest złym pomysłem. Możesz użyć takich narzędzi, aby zaktualizować to, co faktycznie jest przechowywane w submodułach, ale nie polegaj na nich w czasie kompilacji. Oczekuj, że pliki binarne będą tam z punktu widzenia twoich skryptów budujących.

Answer 5

Mam podobny problem z wykorzystaniem VS 2013.

Chcę użyć bezpośrednio git-svn zamiast SVN. SVN ma gigantyczny zestaw katalogów. Nie mogłem utworzyć pojedynczego repozytorium git, które zawierałoby cały nasz katalog trunk. Git-zawsze zakończył działanie z błędem, a repozytorium zostało uszkodzone. Pracowałem wokół problemu wykonując następująco:

1. Korzystanie git-svn, że sklonowane podzbiór folderów off SVN/bagażniku, że muszę przez utworzenie jednego repozytorium git-per folderu.
2. Utworzono lokalny repozytorium git dla rodziców, które zawiera wszystkie moje sklonowane przez git-svn foldery.
3. Każde repozytorium git zostało dodane jako podmoduł do nadrzędnego repozytorium git.

Problem z Visual Studio polega na tym, że nie rozpoznaje on wielu projektów poza głównym projektem, w którym otworzyłem rozwiązanie. To rozwiązanie znajduje się w folderze, który zawiera tylko pliki rozpoznawane przez program Visual Studio jako znajdujące się pod kontrolą git-source.

Próbowałem ustawić preferencje git, aby użyć katalogu nadrzędnego wyższego poziomu jako lokalizacji git-repostitory, nie zauważając żadnej różnicy.