git-svn "Не удалось найти revmap" - что это значит?

Question

При запуске git svn clone и часто во время последующих операций git svn fetch я получаю это сообщение для ряда папок:

Couldn't find revmap for <SVN folder URL>

Мой репозиторий кажется работает нормально.Что означает это сообщение?Должен ли я беспокоиться об этом?

Answer 1

У меня нет полного ответа, но эта ошибка генерируется git-svn.perl .(Соответствующий путь к коду выглядит так: do_fetch -> make_log_entry -> find_extra_svn_parents -> lookup_svn_merge.) Этот код пытается просмотреть свойство svn: mergeinfo коммита слияния svn, чтобы выяснить все его родительские коммиты / ветви, в надежде напревратив это в приятный многопользовательский коммит слияния внутри клона git.Если это родительское разрешение не удается, ваш коммит все равно будет загружен в git;у него просто не будет той же родительской информации, которая была бы в противном случае.

Пока я лично не обнаружил каких-либо серьезных проблем, связанных с этой ошибкой, для моего текущего основного сценария использования, который заключается в преобразовании репозитория SVN.мерзнуть;git-svn удалось разрешить большие слияния, которые действительно важны для меня, и до сих пор эти ошибки кажутся ограниченными либо отдельными слияниями вишневого пика, либо старыми ветвями, которые мне больше не нужны.

На самом делеНа первый взгляд, похоже, что в моем случае большинство этих ошибок происходит от коммитов, где svn: mergeinfo было записано на том уровне, который я считаю неверным в svn.В репозитории svn мы обычно пытаемся записать svn: mergeinfo в корне ветви, например, в svn / trunk, тогда как случаи, на которые жалуется git, похоже, относятся к mergeinfo, который прикреплен к конкретным подкаталогам ветвей, например, в svn / trunk / dir1,Я не эксперт по svn, но моя нынешняя эвристика заключается в том, что если у вас много svn: mergeinfos, которых нет в корне ветки, возможно, что-то не так с вашим репозиторием svn или процессом слияния.Если это правильно, понятно, что мерзавец будет жаловаться.В моем собственном случае, я думаю, что большинство этих «странных» коммитов изменяют svn: mergeinfo как в корне ветви (например, svn / trunk) , так и на уровне subdir (например, svn / trunk / dir1);git получает все, что нужно от корневого уровня, и выдает явно безобидную ошибку об уровне subdir.

Тем не менее, некоторые люди, кажется, сообщают о проблемах в некоторых случаях, возможно, особенно когда перебазирует врепозиторий git-svn, в котором проверены не все ветви .

Answer 2

Просто хотел заметить - на самом деле в 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% уверен, что это не так)