Czy Git-svn może być używany w dużych, rozgałęzionych repozytoriach?

Question

Próbuję użyć Git jako frontend do repozytorium SVN, aby móc korzystać z ciekawych funkcji git niczym prostym rozgałęzienia, stashing itp

Problem polega na tym, że repozytorium SVN jest dość duża (8000 obrotów) i zawiera wiele gałęzi i tagów (zarówno starych, jak i nowych).

To prawie standardowy układ z konfiguracją zawierającą dyrektywy pobierania, rozgałęzienia i znaczniki.

Ponieważ najstarsze odgałęzienie i znacznik odnoszą się do wersji 10, oznacza to, że każde svn fetch odczytuje całą historię repozytorium z wersji 10 i do przodu, co może trwać wiele godzin przy wolnym połączeniu.

Jeśli śledzę tylko bagażnik, to jest w porządku, ale nadal chcę, aby git był świadomy nowych gałęzi i znaczników.

Zwykle patrzę na git log -1 na oddział, w którym się znajduję, i otrzymuję wersję SVN z komentarza, więc mogę zrobić git svn fetch -r7915:HEAD lub coś podobnego. Domyślam się, że to właśnie robi git svn fetch --parent. Ale dlaczego muszę to zrobić?

Jestem w systemie Windows i używam TortoiseGit, który ma całkiem niezłą obsługę dla git-svn, ale ponieważ TortoiseGit działa tylko git svn fetch, utknąłem.

Czy robię coś nie tak? Oczekuję, że svn fetch będzie szybką operacją, gdy pierwszy svn clone -s zostanie ukończony.

Answer 1

Używasz go poprawnie: początkowy import repozytorium Subversion z dużą ilością historii będzie bardzo wolny.

Zła wiadomość jest taka, że ​​gałęzie i znaczniki Subversion są tylko katalogami, git-svn jest zmuszony do podjęcia pesymistycznej drogi odczytywania każdej gałęzi od jej głowy aż do pierwszej wersji. Tak, jeśli jesteś zdyscyplinowany w korzystaniu z Subversion, spowoduje to wiele pobrań tych samych danych, ale rzeczywiste wzorce użycia sprawiają, że jest to mało prawdopodobne.

Uruchom klona wieczorem i wróć do miłego repozytorium git następnego ranka!

Po sklonowano git svn fetch nawet ostrzega:

This may take a while on large repositories

Subversion jest prosty i głupi, więc git musi wziąć sprawy powoli.

Answer 2

Jeśli nie potrzebujesz pełnej historii w repozytorium git, polecam przyjrzeć się podejściu "git + svn", opisanemu w poniższym łączu, zamiast standardowej integracji git-svn. Twój początkowy import do git powinien być bardzo szybki, ponieważ nie będziesz importować historii.

Należy przeczytać rozdział zatytułowany "Korzyści, wady i wnioski".

http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx

Answer 3

Dzięki za odpowiedzi. Ale tak naprawdę mi nie pomogli.

Komenda ta jest najlepszym rozwiązaniem do tej pory:

git svn log --all -1 | \ 
    sed -n '2s/r\\([0-9]*\\).*/\\1/p' | \ 
    xargs --replace=from git svn fetch -r from:HEAD

Wykorzystuje git svn log --all znaleźć najwyższy numer wersji SVN pobrane do tej pory, i pobiera wszystko od tego momentu.

Życzę sobie, aby git svn fetch miał możliwość zachowania się w ten sposób. O ile zmiany SVN nie zostaną zmienione, nie ma powodu, dla którego git svn powinien za każdym razem pobierać te same poprawki.

Answer 4

Czy masz dowiązanie symboliczne w repozytorium SVN? Jeśli nie próbowałeś tego ustawienia:

svn.brokenSymlinkWorkaround

Wyłącza potencjalnie kosztownych kontrole Obejście połamane dowiązania sprawdzonych w SVN przerywanymi klientów. Ustaw tę opcję na "false", jeśli śledzisz repozytorium SVN z wieloma pustymi obiektami blobowymi , które nie są dowiązaniami symbolicznymi. Ta opcja może zostać zmieniona, gdy uruchomiona jest git svn i będzie miała wpływ na pobraną wersję następnej wersji . Jeśli nie jest ustawiony, git svn zakłada, że ​​ta opcja ma wartość "true".