Ошибка проверки репозитория Subversion (svn: ваш каталог .svn/tmp может отсутствовать или быть поврежден;)

Я пытаюсь проверить полный репозиторий subversion, включая все ветки и теги:

svn co svn+ssh://path/to/project

Это работает некоторое время, но во время проверки ветки я получаю следующую ошибку:

svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again
svn: Can't open file 'project\branches\BRANCH\source\java\com\bS\.svn\tmp\text-base\Event.java.svn-base': The system cannot find the path specified.

Поэтому я попытался проверить ветку вручную, выполнив следующие действия:

svn co svn+ssh://path/to/project/branches/BRANCH

Это работает нормально, и я получаю ветку. Затем я могу скопировать ветку в каталог веток всего проекта и продолжить оформление заказа. Но он продолжает сталкиваться с этой проблемой в других ветках.

Кто-нибудь знает, почему я не могу проверить ветку как часть общего проекта, но я могу проверить ее самостоятельно?


repository version-control svn svn-checkout
person DaveJohnston    schedule 17.01.2011    source источник
comment
Вы пытались запустить очистку svn?   -  person Michael Kopinsky    schedule 17.01.2011
comment
замечание, которое, вероятно, не связано с ошибкой: если вы не знаете, что делаете (т. е. не знаете, как создавать неглубокие проверки), вам не следует проверять верхний уровень проекта со всеми включенными ветвями и тегами. Если в проекте тысяча тегов, то в вашей кассе будет тысяча копий проекта. Вместо этого проверьте ствол или конкретную ветку.   -  person Wim Coenen    schedule 17.01.2011
comment
@Вим Коэнен, спасибо. Я просто хотел создать локальную копию репозитория SVN, чтобы попробовать конвертировать его в Mercurial без риска повредить какие-либо данные. Теперь я изменил тактику и создал свою локальную копию, создав дамп с основного сервера и загрузив его во вновь созданное локальное репо.   -  person DaveJohnston    schedule 17.01.2011

Ответы (4)


arrow_upward
7
arrow_downward

Вы можете обойти эту проблему в Windows, указав полный путь в параметре команды svn. Например, вместо

c:\dev> svn co http://repoman.example/svn/myproj/trunk myproj

попробуй это

c:\dev> svn co http://repoman.example/svn/myproj/trunk c:\dev\myproj

По какой-то причине ограничения длины пути применяются только к относительным путям.

person Victor    schedule 05.08.2011
comment
Это сработало для меня. Хорошо, что я уже был в корне диска, не было возможности сократить путь проверки. - person ; 15.01.2013

arrow_upward
6
arrow_downward

Итак, я действительно нашел ответ на свой вопрос, ну, по крайней мере, решение. Оказывается, дело в длине пути. В моем вопросе выше я отредактировал путь, чтобы не публиковать подробности кода компании, но на самом деле это был файл с очень длинным именем, и он находился в довольно глубоко вложенном каталоге.

Когда я проверял ветку сам по себе, я проверял ее в каталоге более высокого уровня на своем жестком диске, и он работал. Я попытался проверить ветку самостоятельно непосредственно в каталоге веток, который я создал для проекта, и это также не удалось, поэтому я предполагаю, что это должно быть как-то связано с путем.

Сейчас я проверяю весь проект в D:\ProjectDir, и все, кажется, идет намного более гладко. Я предполагаю, что в subversion есть ограничение на длину пути, поэтому некоторые из необходимых файлов не удалось получить.

*Обновление: ограничение составляет 255 символов. Оказалось, что в моем случае путь был 269 символов. Так что просто подняться на 1 уровень каталога было достаточно, чтобы обойти проблему.

person DaveJohnston    schedule 17.01.2011
comment
Вы находитесь в Windows. Правильно? Максимальная длина пути — большая проблема Windows. Я видел спам, спрятанный с помощью этого. Проводник Windows и антивредоносное ПО не могли видеть файлы, но они были там. Ирония в том, что Windows МОЖЕТ обрабатывать эти длинные пути, а NTFS МОЖЕТ обрабатывать эти пути. Однако Проводник Windows и основные библиотеки открытия/закрытия файлов не могут. Вы можете применять технику программирования, // используя пути, которые позволят вам обойти эти проблемы, но никто их не использует. Остается только гадать, почему у MS до сих пор есть этот фальшивый лимит в Windows. Тем более, что .NET использует длинные имена путей. - person David W.; 10.03.2011
comment
Этот обходной путь не очень полезен, поскольку иногда у вас нет такой роскоши, чтобы подняться на один уровень. Вместо этого я бы порекомендовал решение Виктора (опубликовано позже): использование абсолютного пути в вашей ссылке для оформления заказа, а не относительного пути - person Hoàng Long; 12.11.2014

arrow_upward
2
arrow_downward

Проверьте это: find . -iname '.svn' -exec mkdir {}/tmp \;

person EpokK    schedule 23.10.2013

arrow_upward
0
arrow_downward

Вы также получаете эту ошибку при извлечении имен файлов с префиксом специальных имен устройств Windows, таких как CON и PRN (например, CON.java):

http://mail-archives.apache.org/mod_mbox/subversion-users/201209.mbox/%[email protected]%3E

person Arno Bakker    schedule 12.04.2013