Грешка при проверка на хранилището на 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 cleanup?   -  person Michael Kopinsky    schedule 17.01.2011
comment
забележка, която вероятно не е свързана с грешката: освен ако не знаете какво правите (т.е. знаете как да създавате плитки проверки), не трябва да проверявате най-високото ниво на проект с всички включени разклонения и тагове. Ако проектът има хиляда етикета, тогава вашето плащане ще съдържа хиляда копия на проекта. Вместо това проверете багажника или конкретен клон.   -  person Wim Coenen    schedule 17.01.2011
comment
@Wim Coenen благодаря. Просто исках да създам локално копие на SVN repo, за да мога да опитам преобразуване в 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 Explorer и анти-зловреден софтуер не можаха да видят файловете, но те бяха там. Иронията е, че Windows МОЖЕ да обработва тези дълги пътища, а NTFS МОЖЕ да обработва тези пътища. Въпреки това, Windows Explorer и основният файл отварят/затварят библиотеки не могат. Можете да правите техники за програмиране, използвайки // пътища, които ще ви позволят да заобиколите тези проблеми, но никой не ги използва. Защо 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