Przenoszenie repozytorium SVN o rozmiarze wielu GB do Git

13

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.

ikh
źródło
Czy te rozmiary przekraczają rozmiary repozytoriów, w tym historii, czy też są to rozmiary lokalnej kopii roboczej?
Doc Brown
1
@DocBrown tylko lokalna kopia robocza, nie zawiera historii.
ikh

Odpowiedzi:

10

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ą.

Wilbert
źródło
Czy NuGet obsługuje kompilacje wiersza poleceń? Zawsze szukam przenośnej wersji, którą mogę skłonić Jenkins do zbudowania i przetestowania dla mnie. Czy NuGet obsługuje serwery CI takie jak Jenkins?
odznacz
Jeszcze jedna myśl: jak długo potrzebujesz wspierać swój produkt? Jeśli potrzebujesz wsparcia przez bardzo długi czas, nie liczę na to, że poprawna wersja twoich bibliotek stron trzecich będzie dostępna w NuGet. Możesz mieć bardzo duże problemy, polegając na narzędziach takich jak NuGet, aby uzyskać prawidłową kombinację narzędzi innych firm, nawet za 2-3 lata.
odznacz
3
@uncletall: tak, NuGet ma kompletny interfejs wiersza poleceń. Pomysł polega na skonfigurowaniu lokalnego repozytorium NuGet, które może być po prostu folderem w udziale sieciowym (zwanym „kanałem”, docs.nuget.org/docs/creating-packages/… )
Doc Brown
Tak, przyjąłem oczywiście, że korzystasz z lokalnego serwera lustrzanego. Zaktualizuję odpowiedź.
Wilbert
2
@ikh budowanie pakietów nugetowych dla zależności zewnętrznych jest dość proste. Potrzebowałem około pół dnia, aby spakować 9 zależności z 50 bibliotekami DLL, nigdy wcześniej tego nie robiłem.
Wilbert
5

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.

Idan Arye
źródło
4

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.

Donal Fellows
źródło
Jakie są opcje zarządzania bibliotekami zewnętrznymi? Pracujemy w Visual Studio z C ++ i C #, więc Maven nie wygląda na dobre dopasowanie. Głównym problemem jest to, że posiadanie ThirdPartyfolderu w repozytorium jest tak wygodne, że trudno jest znaleźć dobrą alternatywę.
ikh
2
@ikh: W środowisku Visual Studio zwykle używasz do tego Nuget , docs.nuget.org , który jest już zawarty w VS 2012 i nowszych wersjach.
Doc Brown
2

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!

niezupełnie
źródło
3
Chociaż dałem Ci +1, ponieważ „pozostaw wszystko tak, jak jest” to pragmatyczne rozwiązanie, myślę, że „wielokrotne repo” może nie być jedynym problemem. DVCS, takie jak Git, zachęcają do posiadania wielu lokalnych oddziałów, aw każdym z nich kompletnej lokalnej kopii wszystkiego. Może to zatem prowadzić do posiadania tej samej dużej biblioteki innej firmy (zazwyczaj tej samej wersji!) Wiele razy jako kopii lokalnej. W niektórych sytuacjach może to być wykonalne, w innych mogę sobie wyobrazić, że będzie to miało negatywny wpływ na wydajność rozgałęziania i łączenia.
Doc Brown
O ile mi wiadomo, gałąź to bardzo tania operacja w Git, która utworzy tylko wskaźnik i zajmie prawie zero miejsca.
odznacz
O ile mi czegoś nie brakuje, gałęzie są „wolne” w Git. Właśnie sprawdziłem mój .git / refs / heads i wszystkie gałęzie są plikami tekstowymi 1KB, .git / logs / refs / head zawiera dzienniki, w których największy to 11 KB dla mastera. Moja normalna struktura projektu to około 500 MB kodu, biblioteki stron trzecich i inne narzędzia. Bardzo się cieszę, że trafiłem na 1KB za utworzenie oddziału
odznacz
1
@MichaelT: samo rozgałęzianie jest oczywiście bezpłatne, ale mówię o sytuacji, w której równolegle masz wiele kopii roboczych różnych oddziałów na lokalnej stacji roboczej. A jeśli sprawdzisz komentarze poniżej pierwotnego pytania, OP odnosiło się do 3 GB narzędzi stron trzecich jako rozmiaru kopii roboczej.
Doc Brown