При запуске git svn clone и часто во время последующих операций git svn fetch я получаю это сообщение для нескольких папок:
Couldn't find revmap for <SVN folder URL>
Мой репозиторий работает нормально. Что означает это сообщение? Должен ли я беспокоиться об этом?
У меня нет полного ответа, но эта ошибка генерируется git-svn.perl. (Соответствующий путь кода, по-видимому, является do_fetch → make_log_entry → find_extra_svn_parents → lookup_svn_merge.) Этот код пытается найти свойство svn merge commit svn: mergeinfo, чтобы выяснить все его родительские коммиты/ветки, в надежде превратив это в приятное многопользовательское слияние, выполненное внутри клона git. Если это родительское разрешение выходит из строя, ваша фиксация по-прежнему будет получена в git; он просто не будет иметь такую же родительскую информацию, как в противном случае.
До сих пор я лично не обнаружил серьезных проблем, связанных с этой ошибкой для моего текущего основного варианта использования, который преобразует svn repo в git; git -svn удалось разрешить большие слияния, которые на самом деле имеют значение для меня, и эти ошибки до сих пор кажутся ограниченными только отдельными слияниями вишни или старыми ветвями, которые мне больше не нужны.
На самом деле, на первый взгляд, похоже, что в моем случае большинство этих ошибок проистекают из коммитов, где svn: mergeinfo записано на то, что Я интерпретирую неправильный уровень в svn. В svn repo мы обычно пытаемся записать svn: mergeinfo у корня ветки, например. в svn/trunk, тогда как случаи git жалуются на то, что, похоже, относятся к mergeinfo, которые привязаны к конкретным подкаталогам отрасли, например. на svn/trunk/dir1. Я не эксперт svn, но моя нынешняя эвристика заключается в том, что если у вас много svn: mergeinfos, которые не находятся в корневой ветке, может быть что-то неладное с вашим svn-репо или процессом слияния. Если это правильно, понятно, что git будет жаловаться. В моем собственном случае я думаю, что большинство этих "странных" коммитов модифицируют svn: mergeinfo как у корня ветки (например, svn/trunk), так и на уровне субдира (например, svn/trunk/dir1); git выделяет все, что требуется от корневого уровня, и бросает очевидную безвредную ошибку об уровне субдира.
Тем не менее, некоторые люди, по-видимому, сообщают о проблемах в некоторых случаях, возможно, особенно при перезагрузке в реестре git -svn, где не все ветки были проверены.
Просто хотел отметить - на самом деле есть скрытый файл в git -svn, который называется что-то вроде
.git/svn/refs/remotes/git-svn/.rev_map.00088888-caaa-4444-9999-2222eeeeeee4
... где закрытый идентификатор - UUID репозитория или git-svn-id.
Это двоичный файл, и в /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.
Обратите внимание, что вывод выглядит примерно так:
$ 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..`...
Я думаю, что когда вы введете git svn info, с этим проконсультируется этот файл, так что вы получите номер версии SVN на основе хеша git SHA для фиксации. Я понятия не имею, как можно его восстановить, хотя (althogh git svn reset может помочь удалить записи из этого файла, а не на 100% уверен, что это не так)