Przenoszenie repozytorium SVN o rozmiarze wielu GB do Git

Obecnie moja firma ma rozwiązanie Visual Studio w repozytorium SVN, które jest zorganizowane w następujący sposób:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1 i Tool2 są budowane niezależnie (mają własne rozwiązania), ale wytwarzają pliki wykonywalne, które są używane w głównej wersji. Folder ThirdParty zawiera wszystkie zależności dla projektu, w tym niektóre wstępnie skompilowane ponad 100 MB plików .lib i duże biblioteki, takie jak boost.

Wygodnie jest mieć to wszystko w jednym repozytorium SVN, dzięki czemu (1) programista musi wykonać tylko jedno sprawdzenie i (2) nie musimy śledzić, które wersje zależności potrzebujemy dla każdej wersji kompilacji. Z drugiej strony sprawdzenie tego repozytorium zajmuje trochę czasu.

Jaki byłby najlepszy sposób na przeniesienie tej struktury projektu do git? Przypuszczalnie najlepiej jest wykluczyć ThirdParty i ewentualnie Narzędzia z głównego repozytorium, ale chcielibyśmy, aby ThirdParty można było łatwo pobrać w jednym kroku, i podoba nam się jego wersjonowanie (a niezgodności wersji między głównym repozytorium a ThirdParty / Narzędziami byłyby złe).

W tym momencie nie interesuje mnie zachowanie historii, tylko zastanawianie się, jak zorganizować taki projekt.

Użyj odpowiedniego narzędzia do pracy. Oznacza to w systemie Windows

Użyj NuGet do zależności od innych firm

W ten sposób utrzymujesz zależności między stronami trzecimi w sposób wersjonowany, ale nie będziesz rozszerzać swojego repozytorium niepotrzebnymi rzeczami. Kasy są znacznie szybsze, a projekt jest zorganizowany tak, jak powinien. Możesz włączyć opcję w Visual Studio, aby zawsze automatycznie pobierała wszystkie zależności.

Oczywiście możesz użyć rozwiązania, które po prostu używa git (inne repozytorium, submoduły itp.), Ale to tylko hacki. Wykonanie tego we właściwy sposób szybko się zwróci i zapewni system przyszłościowy.

Edytuj po komentarzach: Najlepszym sposobem korzystania z NuGet jest skonfigurowanie lokalnego źródła NuGet na dysku udostępnionym lub na pełnym serwerze nuget. Instalacja nie powinna zająć więcej niż kilka minut. W ten sposób możesz zagwarantować, że wszystkie potrzebne pakiety są zawsze dostępne, bez względu na to, skąd pochodzą.

Do narzędzi można użyć submodułów . W ten sposób możesz przechowywać je w podkatalogu, tak jak teraz, i używać osobnego repozytorium do ich wersjonowania. Oznacza to również, że możesz sklonować (wypisać) narzędzia i opracować je osobno, a inne projekty mogą polegać na tych repozytoriach - oraz na określonych, możliwych do aktualizacji wersjach.

Możesz również użyć podmodułów dla bibliotek stron trzecich, ale jeśli to możliwe, zaleciłbym użycie do nich menedżera zależności.

Jednostki, które zamieniasz w repozytoria git, są koniecznie jednostkami, które aktualizujesz i rozgałęziasz; jeśli SolutionFolder/Tools/Tool1odpowiada jednej takiej rzeczy, to jest to poziom bytu. To dlatego, że git chodzi cały stan drzewa katalogów być versionable podmiot, natomiast z SVN jest możliwe (nawet jeśli nie jest to dobry pomysł), aby mieć trunk, branchesi tagsnigdzie w drzewie.

Pochodne artefakty nie powinny być przechowywane w repozytorium, podobnie jak biblioteki zewnętrzne. Są lepsze sposoby radzenia sobie z nimi. (Jeśli pracujesz z Javą, rozważ użycie prywatnego repozytorium Maven; są one stosunkowo łatwe w obsłudze i ładnie integrują się z wieloma innymi rzeczami.)

Jeśli jesteś przyzwyczajony do przepływu pracy, który ma wszystko w jednym repozytorium dla ułatwienia realizacji transakcji, rozważ użycie skryptu, który konfiguruje rzeczy.

Szczerze mówiąc, nie zmieniłbym niczego w twoim ustawieniu. Właśnie to robimy teraz. Bawiłem się tworzeniem osobnego repozytorium git, aby obsługiwać bibliotekę stron trzecich, której używamy, ale nie sądzę, żeby ważyła to koszt przenośności. Teraz każdy programista może po prostu przejść do kasy i rozpocząć bez konieczności ręcznego konfigurowania. I ja każdy serwer / slave kompilacja może zbudować projekt. Jeśli nie masz wielu repozytoriów udostępniających narzędzia thridparty, po prostu trzymałbym się twojej obecnej konfiguracji.

Bawiłem się konfigurowaniem narzędzi stron trzecich w osobnym repozytorium. Potem miałem jeden prosty skrypt wsadowy, który przeczytał plik tekstowy z poleceniem sha1 i sprawdził poprawną wersję. Pozwoliłoby mi to mieć różne wersje stron trzecich dla różnych projektów. Mam ten pomysł z narzędzia do budowania Facebook Buck. Ale w końcu wielu programistów nie lubi używać narzędzi wiersza poleceń (tutaj sklep MS VC), więc zrezygnowałem z tego pomysłu.

Jednym z głównych powodów, dla których nie należy pobierać bibliotek stron trzecich, gdy są one wymagane (za pomocą NuGet), jest to, że jeśli potrzebujesz obsługiwać swój produkt przez długi czas. W mojej branży musimy czasami udostępniać aktualizacje dla starych wersji, które korzystają ze starych bibliotek stron trzecich. Nie chcemy poświęcać dużo czasu na sortowanie bibliotek, które możemy uaktualnić lub nie, i po prostu używamy bibliotek lib używanych w tej wersji. Teraz wyobraź sobie, że używasz NuGet, ups ... najnowsza wersja wymaganej biblioteki to 3.98, ale potrzebujesz 2.04 ..... jak wytłumaczyć swojemu szefowi, że musisz poświęcić 2 miesiące na aktualizację starej wersji, aby móc korzystać z najnowszych bibliotek, kiedy spodziewał się niewielkiej zmiany!