git svn - <file>не был найден в коммите <hash>

Question

В процессе обработки (довольно большого) репозитория svn с помощью git-svn я обнаружил следующее сообщение об ошибке (общая информация заменяет реальную информацию):

Found possible branch point: svn://server/project/trunk/dir => svn://server/project/branches/branchname, <revision>
Initializing parent: refs/remotes/branchname@<revision>
project/trunk/dir/file was not found in commit <hash> (r<revision>)

Я прочитал в других сообщениях , что можно «извлечь» эту информацию через некоторые операции. Однако я бы не стал терять историю и идти вперед как можно безболезненнее.

Как мне заставить git-svn fetch продолжить?

Answer 1

Это, вероятно, означает, что вы получаете новую ревизию svn, которая изменяет файл, который (по какой-то причине) не существует в вашем git commit эквиваленте родительской ревизии svn. Один из очень простых способов вызвать это - быть несовместимым с --ignore-paths (изначально не было никакого способа настроить их, и их нужно было вводить в каждой командной строке git-svn, которая может быть получена). Другой способ заключается в том, чтобы кто-то на стороне сервера svn изменил разрешения репозитория таким образом, чтобы внезапно появилось целое поддерево файлов (с вашей точки зрения), для которого у вашего git-репозитория нет истории.

Самый простой способ обойти эту непосредственную проблему и продолжить git-svn fetch - это использовать --ignore-paths (или лучше запись конфигурации svn-remote.svn.ignore-paths), чтобы игнорировать проблемную часть дерева. Вы можете сойти с аргумента командной строки, чтобы передать одну ревизию, и вы не столкнетесь с проблемой снова, пока кто-то не изменит ее на стороне svn.

Если вы хотите восстановить без --ignore-paths, вам нужно будет исправить родительскую ревизию, чтобы она включала изменяемый файл. Я написал git-svn reset специально для того, чтобы сделать «выборку», на которую вы ссылаетесь, с меньшими усилиями. Он может сбросить ваш SVN Remote обратно туда, где файл был действительно создан, чтобы вы могли интегрировать его в свою историю. Это не уничтожит ваши рабочие копии, но вам нужно будет переписать все рабочие ветви в этой новой истории.

Answer 2

Я получил эту ошибку из git svn fetch, когда в репозитории были установлены svn: externals urls, и мое регулярное выражение --ignore-paths отфильтровало бы их.

Answer 3

Быстрое решение здесь - сбросить ревизию до проблемной.

git svn reset <a past revision>

Например, когда в сообщении об ошибке упоминается r1000 например, запустить git svn reset r990 и т. Д.

И запустить git svn rebase или git svn fetch.

Answer 4

Я столкнулся с этой проблемой с именами каталогов, содержащими символы Юникода, хотя ошибка приводит к появлению определенного файла в каталоге. Я пытался

git svn fetch --ignore-paths path/up/to/filename

с полным путем к файлу, но это не сработало. Также не пробовал полный путь к каталогу с символами Unicode.

Команда, которая в конечном итоге сработала, была с родительским каталогом каталога с символами Unicode, например:

git svn fetch --ignore-paths path/up/to/but-not-including-unicode-chars

Answer 5

Получена та же ошибка в Windows в отношении специальных символов (здесь: умляуты) в именах файлов:

(...)
r36770 = 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (refs/remotes/origin/xxx)
    M   doc/specification/xxx/2013 03 07 Workflows.xls
xxx/branches/xxx/doc/specification/xxx/2013 03 07 München.xls 
    was not found in commit 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (r36770)

Файл, о котором идет речь, действительно был в указанной ревизии, но git svn не смог его увидеть.

Мне удалось решить эту проблему, настроив переменные среды для языка и локали следующим образом:

SET LANG=C
SET LC_ALL=C

Вы можете выполнить эти команды просто перед запуском git svn, но они будут сохраняться только в течение всего времени существования текущей оболочки. Если вы хотите установить их постоянно, перейдите в Панель управления> Система> Расширенные настройки системы> Переменные среды.