2011-01-17 11 views
8

Próbuję sprawdzić pełną repozytorium Subversion tym wszystkie oddziały i tagi:Błąd sprawdzania repozytorium Subversion (SVN: Twój katalog .svn/tmp mogą być utracone lub uszkodzone;)

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

To trwa jakiś czas, ale w kasie oddziału pojawia się następujący błąd:

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. 

Spróbowałem więc do kasy oddziału ręcznie wykonując:

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

To działa, grzywny i dostaję oddział. Mogę wtedy skopiować gałąź do katalogu gałęzi pełnego projektu i kontynuować z kasą. Ale problem ten pojawia się w innych gałęziach.

Czy ktoś ma pojęcie, dlaczego nie mogę zrealizować transakcji w oddziale w ramach całego projektu, ale mogę to sprawdzić samodzielnie?

+0

Czy próbowałeś uruchomić czyszczenie svn? –

+0

Tak, to nie pomogło. – DaveJohnston

+0

uwaga, która prawdopodobnie nie ma związku z błędem: jeśli nie wiesz, co robisz (tj. Wiesz, jak tworzyć płytkie zamówienia), nie powinieneś sprawdzać najwyższego poziomu projektu z uwzględnieniem wszystkich gałęzi i tagów. Jeśli projekt zawiera tysiąc tagów, Twoje zamówienie będzie zawierało tysiąc egzemplarzy projektu. Zamiast tego sprawdź port lub konkretny oddział. –

Odpowiedz

6

Ok, więc faktycznie znalazłem odpowiedź na moje własne pytanie, przynajmniej rozwiązanie. Okazuje się, że ma to związek z długością ścieżki. W powyższym pytaniu zredagowałem nazwę ścieżki, aby nie zamieszczać szczegółów kodu firmy, ale w rzeczywistości był to plik o bardzo długiej nazwie i żył w dość głęboko zagnieżdżonym katalogu.

Kiedy sprawdzałem oddział samodzielnie, sprawdzałem go w katalogu wyższego poziomu na moim twardym dysku i działało. Próbowałem samemu odszukać gałąź bezpośrednio w katalogu gałęzi, który utworzyłem dla projektu, ale także się nie udało, więc myślę, że musiało to mieć coś wspólnego ze ścieżką.

Teraz sprawdzam cały projekt w D: \ ProjectDir i wszystko wydaje się przebiegać znacznie sprawniej. Myślę, że istnieje limit subversion do długości ścieżki, więc nie udało się uzyskać niektórych wymaganych plików.

* Aktualizacja: limit wynosi 255 znaków. Okazało się, że w moim przypadku ścieżka liczyła 269 znaków. Tak więc wystarczy przejść o 1 poziom katalogu, aby obejść problem.

+2

Jesteś w systemie Windows. Dobrze? Maksymalna długość ścieżki to duży problem z systemem Windows. Widziałem ukryty spyware za pomocą tego. Eksplorator Windows i program antywirusowy nie widziały plików, ale one tam były. Ironia polega na tym, że Windows CAN obsługuje te długie ścieżki, a NTFS CAN obsługuje te ścieżki. Jednak Eksplorator Windows i podstawowe biblioteki otwierania/zamykania plików nie mogą. Możesz programować techniki za pomocą // ścieżek, które pozwolą ci ominąć te problemy, ale nikt ich nie używa. Dlaczego MS nadal ma ten fałszywy limit w systemie Windows, to nikt nie zgaduje. Zwłaszcza, że ​​.NET używa długich nazw ścieżek. –

+0

To nie jest zbyt użyteczne w tym obejściu, ponieważ czasami nie masz takiego luksusu, aby "podnieść się o jeden poziom". Polecam rozwiązanie Victora (zamieszczone później) zamiast: używanie bezwzględnej ścieżki w linku do kasy, a nie względnej ścieżki –

7

Możesz obejść ten problem w systemie Windows, podając pełną ścieżkę parametru w komendzie svn. Na przykład zamiast

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

spróbować tej

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

jakiegoś powodu path length limits only apply to relative paths.

+1

To zadziałało dla mnie. Dobrze, ponieważ byłem już u podstaw dysku, nie było sposobu, aby skrócić ścieżkę kasy. –

+0

PRACOWAĆ DLA MNIE ZBYT !!! Przepraszam, jestem zbyt podekscytowany –

2

Zaznacz to: find . -iname '.svn' -exec mkdir {}/tmp \;

Powiązane problemy