Błąd SVN - nie kopia robocza

Ostatnio nasz serwer svn został zmieniony i dokonaliśmy przełączenia svn.

Ponieważ kopia robocza miała ogromną ilość niewersjonowanych zasobów, kopia robocza została zablokowana i zaczęliśmy przełączać folder po folderze dla wszystkich folderów pod svn, co działa idealnie dobrze.

Ale na najwyższym poziomie repozytorium, gdy próbuję zaktualizować pliki, otrzymuję svn: kopia robocza '.' zablokowany błąd i czyszczenie też nie pomaga. Kiedy robię czyszczenie, otrzymuję takie błędy - svn: 'content' nie jest katalogiem kopii roboczej

Świeża realizacja kasy wcale NIE jest opcją. Czy są jakieś inne sposoby na oczyszczenie i zwolnienie blokad i całkowite przełączenie?

EDYCJA: Ostatni akapit w odpowiedzi JesperE

Jeśli podczas rekurencyjnego „czyszczenia svn” pojawi się „nie kopia robocza”, domyślam się, że masz katalog, który powinien być kopią roboczą (np. Katalog .svn na najwyższym poziomie tak mówi), ale brakuje jej własny katalog .svn. W takim przypadku możesz spróbować usunąć / przenieść ten katalog, a następnie wykonać lokalną aktualizację

wydaje się być rozwiązaniem problemu w repozytorium. Zidentyfikowałem te foldery i sam sprawdziłem te konkretne foldery i wow, blokady są zwalniane podczas następnego czyszczenia! Wielkie dzięki JesperE !!

Ale nadal nie mogę znaleźć błędu przełącznika svn, który odczytuje teraz coś takiego,

svn: Repozytorium o nazwie „svn: // repourl / reponame / foldername” ma identyfikator UUID „m / reponame”, ale toaleta ma „b5b39681-0ff6-784b-ad26-2846b9ea8e7d”

Jakieś pomysły ?

Jeśli podczas robienia rekurencji otrzymujesz „nie kopię roboczą”, svn cleanupdomyślam się, że masz katalog, który powinien być kopią roboczą (tzn. .svnKatalog na najwyższym poziomie tak mówi), ale brakuje mu własnego .svnkatalogu. W takim przypadku możesz spróbować usunąć / przenieść ten katalog, a następnie wykonać lokalną aktualizację (tj rm -rf content; svn checkout content.).

Jeśli pojawi się not a working copybłąd, oznacza to, że Subversion nie może znaleźć w nim odpowiedniego .svnkatalogu. Sprawdź, czy w .svnkatalogu znajduje się katalogcontents

Idealnym rozwiązaniem jest świeże zamówienie, jeśli to możliwe.

W podobny sposób ( svn: 'papers' is not a working copy directory) wpadłem na inny sposób, więc pomyślałem, że opublikuję swoją historię bitwy (uproszczoną):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

Ups! napraw uprawnienia ... następnie:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

I nawet zejście papersz drogi i bieganie svn up(które działały dla OP) nie naprawiły tego. Oto co zrobiłem:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

To się udało.

Rozwiązałem to przez

1. Skopiuj kopię zapasową folderów, których dotyczy problem
2. SVN przywraca foldery, których dotyczy zmiana
3. Wklej pliki z kopii zapasowej

W moim przypadku przyczyną były usunięte pliki .svn.

Być może właśnie skopiowałeś drzewo folderu i próbujesz dodać najniższy.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

w takim przypadku musisz zatwierdzić katalog na wyższym poziomie.

Obejście: Zmień nazwę katalogu, który nie jest „kopią roboczą” Pobierz / zaktualizuj / przywróć ten katalog ponownie Przenieś pliki z katalogu o zmienionej nazwie do nowego Zatwierdź zmiany

Powód: Wprowadziłeś pewne zmiany w niektórych plikach w katalogu .svn, to przerywa „kopię roboczą”

Jeśli utworzyłeś plik w nowym katalogu, zamiast 'svn add newdir / newfile' use 'svn add newdir', ponieważ musisz dodać katalog. Wszystkie pliki w katalogu zostaną dodane domyślnie.

Właśnie dostałem „nie kopię roboczą” i dla mnie powodem był Automouter na Uniksie. Tylko nowy „cd / path / to / work / directory” załatwił sprawę.

Tak samo musiałem zaktualizować folder „contrib”:

1. Wyprowadziłem stary folder,
2. Skopiowałem nowy
3. Skopiowałem foldery .svn do każdego (tylko trzy w moim przypadku) nowego folderu.

Również w moim przypadku problem był spowodowany usunięciem folderów .svn.

Rozwiązany.

Próbowałem wkleić folder .svn z podfolderu do folderu głównego. To działa!!!

Oto co zrobiłem:

1. zmień nazwę trunk na trunk_
2. utwórz nowy folder główny
3. Ponownie wyewidencjonuj i przerwij proces po wyrejestrowaniu kilku plików
4. Przenieś pliki z trunk_ do trunk
5. Czy svn cleanup
6. Wykonaj aktualizację SVN. Spowoduje to zaktualizowanie statusu plików, a następnie wszystkie pliki zostaną poddane wersji.

Spotykam również ten problem w działaniu svn diff, był on spowodowany niepoprawną ścieżką pliku, należy go dodać, './'aby wskazać bieżący katalog plików.

svn: Repozytorium o nazwie „svn: // repourl / reponame / foldername” ma identyfikator UUID „m / reponame”, ale toaleta ma „b5b39681-0ff6-784b-ad26-2846b9ea8e7d”

Każde repozytorium subversion ma unikalny identyfikator (identyfikator UUID). Subversion używa tego, aby upewnić się, że repo jest w rzeczywistości takie samo podczas robienia rzeczy takich jak przełączanie. Prawdopodobnie powinieneś zmienić identyfikator UUID na serwerze, aby był taki sam jak poprzednio.

Czy może to być niezgodność formatu kopii roboczej? Zmienił się między svn 1.4 i 1.5, a nowsze narzędzia automatycznie konwertują format, ale wtedy starsze nie działają już z przekonwertowaną kopią.

Musisz usunąć plik podstawowy SVN ze swojego projektu (które są plikami tylko do odczytu). Z tego powodu pojawia się ten błąd.

Sprawdź ponownie nowy projekt, scal zmiany (jeśli w ogóle) starszego projektu SVN z nowym przy użyciu „Winmerge” i zatwierdź zmiany w najnowszej wersji.

@JesperE wspomina , że musisz zmienić identyfikator użytkownika. Poniższe informacje powinny pomóc Ci to osiągnąć.

W SVN 1.5+ możesz wykonać svnadmin setuuid; możesz następnie sprawdzić, czy został poprawnie ustawiony za pomocą svnlook uuid. We wcześniejszych wersjach SVN jest to trudniejszy proces. Zobacz http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

Ponadto identyfikator UUID „m / reponame” wygląda podejrzanie. Uważam, że powinna to być liczba w formacie szesnastkowym, taka jak kopia robocza, więc może ta akcja poprawi wszystko :-)

[Pierwotnie skomentowałem odpowiedź @ JesperE , ale stworzyłem tę odpowiedź, aby była bardziej oczywista dla ludzi i bardziej pomocna dla Google. Od tego czasu usunąłem moje komentarze. ]

Miałem ten sam problem, okazało się, że mieliśmy Slik 1.6.2, a także Tortoise na tej samej maszynie. Żółw został zaktualizowany (i zaktualizował kopię roboczą), ale Slik nie, więc Tortoise działało OK, ale wiersze poleceń nie powiodły się:

svn: '.' nie jest katalogiem kopii roboczej

Usunięcie zarówno Tortoise, jak i Slik, a następnie ponowna instalacja Tortoise z włączonymi narzędziami wiersza poleceń naprawiło to dla mnie.

dla systemu Mac: - weź zamówienie ze strony serwera, a otworzy się nowe okno, aby wybrać katalog z komputera lokalnego, niż umieść cały kod w wybranym folderze, a następnie otwórz svn po stronie lokalnej i dodaj i zatwierdz projekt

Dziś znalazłem ten sam problem /FILE_NAME/ is not a working copyrano i spędziłem ponad dwie godziny na jego rozwiązaniu. Po długim czasie od RND i Google znalazłem jakieś rozwiązanie i to jest CHECKOUT.

1. CHECKOUTz SUBVERSIONlokalnego na nowy projekt.
2. Zmień część kodu w pliku Java i ZATWIERDŹ projekt.
3. To działa dla mnie.

Mam nadzieję, że to ci pomoże.

Ostatnio korzystałem z innych programistów Mac Miałem taką samą sytuację, problem był; najpierw musiałem wpisać get repo path to terminal, ale nie zrobiłem tego, ponieważ mówi, jaka jest twoja nazwa użytkownika i hasło.

Właśnie natrafiłem na przypadek, w którym katalog .svn znajduje się na serwerze nfs na innym komputerze, a klient nfs nie uruchomił usługi blokowania plików ( lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

Zniknęło to, gdy lockduruchomiono go na hoście klienta NFS.

Wygląda na to, że subversion może uzyskać lepszy komunikat o błędzie, gdy ma problemy z blokowaniem plików. To była subversion 1.10.0

Zrobiłem nową kasę z tego samego projektu do innej lokalizacji, a następnie skopiowałem z niej folder .svn i zastąpiłem go starym folderem .svn. Następnie wywołano funkcję aktualizacji svn i wszystko zostało poprawnie zsynchronizowane na bieżąco.

Usuń folder .svn, który jest obecny na twoim komputerze lokalnym. Naciśnij ikonę Windows i wpisz .svn, usuń cały folder. To zadziałało dla mnie.