git-svn "Nie można znaleźć mapy" - co to znaczy?

Question

Uruchamiając git svn clone i często podczas kolejnych git svn fetch operacji dostaję ten komunikat dla wielu folderów:

Couldn't find revmap for <SVN folder URL> 

Moje repozytorium wydaje aby działać poprawnie. Co oznacza ta wiadomość? Czy powinienem się tym przejmować?

Answer 1

Nie mam pełnej odpowiedzi, ale ten błąd jest generowany przez git-svn.perl. (Odpowiednią ścieżką do kodu wydaje się być do_fetch -> make_log_entry -> find_extra_svn_parents -> lookup_svn_merge.) Ten kod wydaje się próbować spojrzeć na właściwość svn: mergeinfo svn merge commit, aby obliczyć wszystkie jej commity/oddziały macierzyste, w nadziei, że zamieniając to w miłe, wielorodzajowe zatwierdzenie scalania wewnątrz klona git. Jeśli ta funkcja rodzicielska nie powiedzie się, twoje zatwierdzenie nadal będzie pobierane do git; po prostu nie będzie mieć tych samych informacji o rodzicach, jak by nie było.

Do tej pory nie znalazłem żadnych poważnych problemów wynikających z tego błędu w moim bieżącym głównym przypadku użycia, który konwertuje repozytorium svn na git; git-svn był w stanie rozwiązać duże fuzje, które mają dla mnie znaczenie, a te błędy zdają się na razie ograniczać do pojedynczych frazesów lub starych gałęzi, na których mi już nie zależy.

Po drugie, wygląda na to, że w moim przypadku większość z tych błędów pochodzi z zatwierdzeń, w których svn:mergeinfo zostało zarejestrowane w tym, co interpretuję jako niewłaściwy poziom w svn. W repozytorium svn zwykle staramy się rejestrować svn: mergeinfo w katalogu głównym gałęzi, np. w svn/trunk, natomiast case git narzeka, że ​​wydaje się dotyczyć mergeinfo, który jest dołączony do konkretnych podkatalogów branch, np. w svn/trunk/dir1. Nie jestem ekspertem od svn, ale moja obecna heurystyka jest taka, że ​​jeśli masz dużo svn: mergeinfos, które nie znajdują się w głównym katalogu, może być coś nie tak z twoim repozytorium svn lub z procesem scalania. Jeśli to prawda, zrozumiałe jest, że git narzekałby. W moim własnym przypadku, myślę, że większość tych "dziwnych" zatwierdzeń modyfikuje svn: mergeinfo zarówno w katalogu głównym gałęzi (na przykład svn/trunk) , jak i na poziomie subdiru (na przykład svn/trunk/dir1); git zbiera wszystko, czego potrzebuje od poziomu root i rzuca pozornie nieszkodliwy błąd na poziomie subdir.

To powiedziawszy, niektórzy ludzie wydają się zgłaszać problemy w niektórych przypadkach, być może zwłaszcza, gdy rebasing in a git-svn repo where not all the branches were checked out.

Answer 2

Chciałem tylko zwrócić uwagę - nie jest w rzeczywistości plikiem ukrytym w git-svn, zwany coś

.git/svn/refs/remotes/git-svn/.rev_map.00088888-caaa-4444-9999-2222eeeeeee4 

... gdzie id zamknięcie jest Repository UUID lub git-svn-id.

Ten plik jest binarny, a tam jest trochę bardziej na nim w /usr/lib/git-core/git-svn:

# rev_map: ... 
# This is the replacement for the rev_db format, which was too big 
# and inefficient for large repositories with a lot of sparse history 
# (mainly tags) 
# 
# The format is this: 
# - 24 bytes for every record, 
#  * 4 bytes for the integer representing an SVN revision number 
#  * 20 bytes representing the sha1 of a git commit 
... 
# - Piping the file to xxd -c24 is a good way of dumping it for 
#  viewing or editing (piped back through xxd -r), should the need 
#  ever arise. 

Należy pamiętać, że wyjście wygląda mniej więcej tak:

$ cat .git/svn/refs/remotes/git-svn/.rev_map.* | xxd -c24 | head -1 
0000000: 0000 0001 33ee 22cc 9933 88aa 44ff 22dd 5566 88ee 66aa bbcc ....5.'..?..J...Zj..`... 

myślę, że po wpisaniu git svn info , to jest ten plik, który jest konsultowany, aby uzyskać numer rewizji SVN oparty na hash SHA dla zatwierdzenia git. Nie mam pojęcia, jak można go zrekonstruować, chociaż (althogh git svn reset może pomóc w usuwaniu wpisów z tego pliku, a nie w 100% na pewno nie)