Git svn - <файл> не найден в commit <hash>

Ответ 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 специально для того, чтобы сделать "un-fetch", с которым вы ссылаетесь, с меньшим количеством мастеринга. Он может reset удалить ваш svn remote обратно туда, где был создан файл, чтобы вы могли интегрировать его в свою историю. Это не приведет к уничтожению ваших рабочих копий, но вам нужно будет отследить любые рабочие ветки в этой новой истории.

Ответ 2

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

Ответ 3

Быстрое решение здесь - reset для пересмотра до того, как возникнет проблема.

git svn reset <a past revision>

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

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

Ответ 4

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

(...)
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, но они будут сохраняться только до тех пор, пока текущая оболочка будет жить. Если вы хотите установить их постоянно, перейдите в Панель управления > Системa > Дополнительные параметры системы > Переменные среды.

Ответ 5

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

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

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

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

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

Ответ 6

Для более новых систем MacOSX настройте

git config --global core.precomposeunicode false

для старших true. Это объясняется здесь:

https://michael-kuehnel.de/git/2014/11/21/git-mac-osx-and-german-umlaute.html

После правильной настройки опции конфигурации я смог импортировать SVN-репозиторий, используя svn2git (который использует git svn под капотом).

У меня также был

$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"

Но я сомневаюсь, что это многое меняет.