Ответ 1
Вызов git svn fetch, поскольку Администратор работал у меня. Он может получить доступ (и попытаться отредактировать/удалить) некоторые файлы, требующие прав администратора.
Ошибка с Git клоном SVN
Я переношу несколько проектов из SVN в Git, и я использую Git 'svn clone'. Я пытаюсь запустить следующее:
git svn clone --stdlayout --authors-file=authors.txt <path-to-svn-project> <local-git-repo-name>
Я смог клонировать несколько небольших проектов, но когда я пытаюсь клонировать более крупный проект, он дает следующие ошибки:
couldn't truncate file at /usr/lib/perl5/site_perl/Git.pm line 1322.
Error removing .git/Git_04wYzV at /usr/lib/perl5/5.8.8/File/Temp.pm line 890.
Я подумал, что скорее всего найдет быстрое исправление в поиске Google, но вместо этого это выглядит необычной ошибкой. Кто-нибудь знает, как я могу пройти мимо этого?
Мои версии довольно недавно, и я пытаюсь запустить это в Windows 8.1:
Git: using version 1.9.4.msysgit.0
Subversion: using version 1.8.9
git-svn: using version 1.9.4.msysgit.0
Ответы
Ответ 2
Запустите git --version и убедитесь, что вы находитесь в версии 2.4+. Я не могу найти ссылку прямо сейчас, но в 2.2.x и ранее произошла ошибка в коде Git SVN, которая могла бы привести к сбою в разных точках через большие миграции репозитория. Я закончил работу с разработчиками Git в IRC и использовал патч, который был отправлен в список рассылки Git и получил его работу. Однако этот патч был объединен и выпущен. Убедитесь, что у вас есть недавний Git и недавний SVN. Вы также можете возобновить git svn clone, просто запустив git svn fetch внутри каталога. Кроме того, --verbose помогает увидеть больше контекста при ошибке.
Ответ 3
Я получил ту же самую проблему с msysgit 1.9.4.
Попробуйте вместо этого использовать v1.8.3: я клонировал все мои репозитории SVN без ошибок с ним.
Ответ 4
У меня были те же проблемы, когда хранилище svn слишком велико. Я смог обработать его с помощью приложения SmartGit.
http://www.syntevo.com/smartgit/svn-tour Существует бесплатный маршрут продолжительностью 30 дней.
Другим способом решения этой проблемы является слишком импорт из ревизии, если вам не нужна вся история.
git svn clone -r12345:HEAD --stdlayout --authors-file=authors.txt <path-to-svn-project> <local-git-repo-name>
И, наконец, вы можете попробовать эту команду (установить размер буфера):
git config http.postBuffer 524288000
Ответ 5
Не знаю, была ли это ваша проблема, но у меня была та же ошибка: git svn clone/git svn fetch -ing большой репозиторий svn. Иногда он жаловался на couldn't truncate file, иногда он жаловался на слишком много открытых файлов, но он умирал с одним из них довольно надежно и честно в процессе, обычно с особенно большой ревизией (первоначально, повторяя выборку) сработало, но в итоге оно начнёт надежно умирать на той же огромной ревизии).
Чтобы исправить последнее, я запустил ulimit -n 4096 (ulimit -n сообщил, что для меня установлен предел по умолчанию 1024), увеличив ограничение на дескрипторы открытых файлов в четыре раза. Но вместо того, чтобы просто исправить ошибку "слишком много открытых файлов", похоже, что исправлен и couldn't truncate file. Хотя проверка исходного кода указывает на его усечение по дескриптору файла (и, следовательно, для этого не нужно открывать новый дескриптор файла, что может привести к исчерпанию дескриптора), это изменение, похоже, также решает проблему, поэтому возможно реализация, лежащая в основе делает что-то, что идет вразрез с пределом открытых дескрипторов и умирает таким образом, что подразумевает truncate, даже если ответственность за это несло само ограничение открытых файлов.
Ответ 6
Я потратил много часов на своей машине с Windows 10 с той же ошибкой. Я попробовал предложения выше и многие другие. Моим решением было запустить его из образа докера Linux.