Co powinienem zrobić, gdy nie powiedzie się czyszczenie SVN?

Mam wiele zmian w folderze roboczym i coś spieprzyło próbując zrobić aktualizację.

Teraz, gdy wydam „czyszczenie SVN”, otrzymuję:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp to nowy plik, który został dodany przez innego programistę i został obniżony w aktualizacji. Nie istniał wcześniej w moim folderze roboczym.

Czy jest coś, co mogę zrobić, aby przejść dalej bez konieczności sprawdzania nowej kopii repozytorium?

Wyjaśnienie: Dziękujemy za sugestie dotyczące przeniesienia katalogu na bok i usunięcia nowej kopii. Wiem, że jest to opcja, ale tej chciałbym uniknąć, ponieważ istnieje wiele zmian zagnieżdżonych w kilku katalogach głęboko (powinna to być gałąź ...)

Mam nadzieję na bardziej agresywny sposób czyszczenia, może w jakiś sposób zmuszenie pliku SVN ma problem z powrotem do znanego stanu (i próbowałem usunąć jego roboczą kopię ... to nie pomogło).

Gdy zaczynasz wszystko od nowa, nie ma opcji ...

Usunąłem plik dziennika w .svnkatalogu (usunąłem również plik naruszający dane .svn/props-base), wykonałem czyszczenie i wznowiłem aktualizację.

Sytuacja zmieniła się wraz z SVN 1.7, a popularne rozwiązanie polegające na usunięciu pliku dziennika z katalogu .svn nie jest możliwe w przypadku przejścia do implementacji kopii roboczej bazy danych.

Oto, co zrobiłem, które wydawało się działać:

1. Usuń katalog .svn dla kopii roboczej.
2. Rozpocznij nowe zamówienie w nowym, tymczasowym katalogu.
3. Anuluj kasę (nie chcemy czekać, aż wszystko zostanie rozebrane).
4. Uruchom czyszczenie w tym anulowanym kasie.
5. Teraz mamy nowy katalog .svn z czystą bazą danych (chociaż brak / kilka plików)
6. Skopiuj ten plik .svn do starego, uszkodzonego katalogu roboczego.
7. Uruchom aktualizację svn. Powinno to przyspieszyć twój nowy częściowy katalog .svn ze starym katalogiem roboczym.

To wszystko jest trochę mylące, jeśli chodzi o proces. Zasadniczo usuwamy uszkodzony plik .svn, a następnie tworzymy nowy plik .svn dla tej samej ścieżki płatności. Następnie przenosimy ten nowy plik .svn do naszego starego katalogu roboczego i aktualizujemy go do repozytorium.

Właśnie to zrobiłem w TSVN i wydaje się, że działa dobrze i nie wymaga pełnego pobrania i pobrania.

-Jody

Spojrzeć na

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupt/

Podsumowanie poprawki z powyższego linku (Podziękowania dla Anuj Varma)

1. Zainstaluj powłokę wiersza polecenia sqlite (sqlite-tools-win32) ze strony http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

WYBIERZ powinien pokazać ci obrażający folder / plik jako część kolejki roboczej. To, co musisz zrobić, to usunąć ten element z kolejki roboczej.

3. sqlite3 .svn/wc.db "delete from work_queue"

Otóż ​​to. Teraz możesz ponownie uruchomić czyszczenie - i powinno działać. Możesz też przejść bezpośrednio do wykonywanego zadania, zanim zostaniesz poproszony o uruchomienie czyszczenia (dodanie nowego pliku itp.)

Jeśli wszystko inne zawiedzie:

1. Sprawdź w nowym folderze.
2. Skopiuj zmodyfikowane pliki.
3. Sprawdź ponownie.
4. Spakuj gdzieś stary folder (nigdy nie wiadomo, że paranoja jest dobra) przed usunięciem go i użyciem nowego.

Najnowsza wersja (używam 1.9.5) rozwiązuje ten problem, dodając opcję „Przerwij blokady” w menu czyszczenia. Upewnij się tylko, że to pole wyboru jest zaznaczone podczas czyszczenia.

Ta odpowiedź dotyczy tylko wersji wcześniejszych niż 1.7 (dzięki @ ŁukaszBachman) .

Subversion przechowuje informacje w każdym folderze (w .svn), więc jeśli masz do czynienia z podfolderem, nie musisz sprawdzać całego repozytorium - tylko folder, który został zablokowany:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

To da ci dobrą kopię roboczą zablokowanego folderu, ale nadal masz kopię zapasową zmian w borked_dir.bak. Ta sama zasada dotyczy Windows / TortoiseSVN.

Jeśli masz zmiany w izolowanym folderze, spójrz na

svn checkout -N borked_dir   # Non-recursive, but deprecated

lub

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

Następnie

$ svn update

Mam nadzieję, że to pomoże

Miałem dokładnie ten sam problem. Nie mogłem popełnić błędu, a czyszczenie się nie powiedzie.

Za pomocą klienta wiersza polecenia mogłem zobaczyć komunikat o błędzie wskazujący, że nie udało się przenieść pliku z .svn/propsdo .svn/prop-base.

Przejrzałem konkretny plik i stwierdziłem, że został on oznaczony jako tylko do odczytu. Po usunięciu atrybutu „tylko do odczytu” udało mi się wyczyścić folder i zatwierdzić moje zmiany.

Możliwe, że masz problem z dwoma nazwami plików różniącymi się tylko wielkimi literami. Jeśli napotkasz ten problem, utworzenie innego katalogu kopii roboczej nie rozwiąże problemu.

Obecne systemy plików Windows (tj. Kiepskie) po prostu nie zasłaniają różnicy między Filenamei FILEname. Masz dwie możliwe poprawki:

1. Sprawdź na platformie z prawdziwym systemem plików (opartym na Uniksie), zmień nazwę pliku i zatwierdź zmiany.
2. Gdy jesteś zaopatrzony w system Windows, możesz zmieniać nazwy plików w przeglądarce repozytorium SVN Eclipse, która rozpoznaje różnicę i zmienia tam nazwę pliku.
3. Możesz zmienić nazwę problematycznych plików również zdalnie z dowolnego klienta SVN z linii poleceń svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Uruchom svn cleanuppolecenie w terminalu (jeśli nie powiedzie się z Eclipse, co miało miejsce w moim przypadku):

~/path/to/svn-folder/$ svn cleanup

Próbowałem różnych rozwiązań opisanych tutaj, ale żadne nie działało .

Zespół akcji → Aktualizacja do głowy nie powiodła się:

svn: E155004: W katalogu „/ home / user / path / to / svn-folder” znajdują się niedokończone elementy pracy; najpierw uruchom „czyszczenie svn”.

Zespół akcji → Czyszczenie kończy się niepowodzeniem z tym samym błędem.

Rozwiązanie, które działało dla mnie: uruchom polecenie svn cleanup w terminalu .

Polecenie się powiodło.

Następnie zespół → Aktualizacja w Eclipse znów działał.

Uwaga: moja wersja SVN to 1.9.3.

Sprawdź także odpowiedź Chrisa, jeśli svn cleanupnie działa.

Próbowałem to zrobić svn cleanupza pomocą konsoli i wystąpił błąd:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

Więc utworzyłem ten plik ręcznie (pusty) i zrobiłem to svn cleanupponownie. Tym razem udało się.

Miałem ten sam problem. Dla mnie przyczyną był konflikt z EasySVN i (TortoiseSVN lub po prostu SVN). Miałem automatyczną aktualizację i zatwierdzanie za pomocą EasySVN (co nie działało).

Kiedy to wyłączyłem, nie byłem w stanie wyczyścić, zatwierdzić ani zaktualizować. Żadne z powyższych rozwiązań nie działało, ale zrestartowało się :)

Właśnie miałem ten sam problem na Windows 7 64-bit. Uruchomiłem konsolę jako administrator i usunąłem katalog .svn z katalogu problemów (dostałem błąd dotyczący logów lub czegoś, ale zignorowałem go). Następnie w Eksploratorze usunąłem katalog problemów, który nie był już wyświetlany jako pod kontrolą wersji. Następnie uruchomiłem aktualizację i wszystko przebiegło zgodnie z oczekiwaniami.

Jeśli problemem jest rozróżnianie wielkości liter (co może być problemem podczas wyewidencjonowywania na komputerze Mac, a także w systemie Windows) i nie masz opcji wyewidencjonowania w systemie * nix, poniższe działania powinny działać. Oto proces od samego początku:

% svn co http://[domain]/svn/mortgages mortgages

(Kasa następuje… następnie…)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

Tutaj SVN próbuje wypisać dwa pliki o podobnych nazwach, które różnią się tylko wielkością liter - Header_3_noBookmark.gifi Header_3_nobookmark.gif. W systemach plików Mac domyślnie rozróżniana jest wielkość liter, co powoduje, że SVN dusi się w takich sytuacjach. Więc...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Jednak bieganie svn cleanupnie działa, jak wiemy.

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gifto nie jest problem… Po prostu nie można przejść od poprzedniego błędu do następnego pliku. Więc .svnusunąłem wszystkie pliki z katalogu innego niż i usunąłem dziennik SVN. Spowodowało to wyczyszczenie, dzięki czemu mogłem wyewidencjonować i zmienić nazwę niepoprawnego pliku.

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

Następnie udało mi się wrócić do katalogu głównego projektu i uruchomić, svn upaby sprawdzić resztę.

Ilekroć mam podobne problemy, używam rsync (NB: używam Linuksa lub Mac OS X), aby pomóc:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

W ten sposób masz świeżą kasę, ale z tymi samymi plikami roboczymi. Dla mnie to zawsze działa jak urok.

Ostatnio na to wpadłem. Sztuczka była dla mnie po wybraniu „Wyczyść”, w oknie dialogowym opcji wyskakujących zaznacz „Przerwij blokady”, a następnie „OK”. Oczyściło mnie to z powodzeniem.

Subclipse wprawia w zakłopotanie naprawdę diabelskie zachowanie systemu Windows. Unlocker jest twoim przyjacielem. To może znaleźć zablokowane pliki i siłą zwolnić blokady.

(Zanim spróbujesz przenieść foldery i zrobić nową kasę).

Usuń folder, w którym znajdują się obrażające pliki - tak, nawet .svnfolder, a następnie zrób to svn cleanupna najwyższym / nadrzędnym folderze.

Napotkałem ten sam problem. Po kilku wyszukiwaniach w Internecie znalazłem poniższy artykuł . Potem zdałem sobie sprawę, że jestem zalogowany jako użytkownik inny niż użytkownik, którego użyłem do skonfigurowania SVN, co jest zasadniczo kwestią uprawnień.

Kiedy napotykam ten problem z TortoiseSVN (Windows), idę do Cygwin i uruchamiam odtąd „ czyszczenie svn ”; czyści to dla mnie poprawnie, po czym wszystko działa z TortoiseSVN.

Odpowiedzi tutaj nie pomogły mi, ale zanim ponownie sprawdziłem projekt, zamknąłem i otworzyłem Eclipse (Subversive to mój klient SVN) i problem zniknął.

Może nie mieć zastosowania we wszystkich sytuacjach, ale kiedy ostatnio napotkałem ten problem, moją „poprawką” było uaktualnienie pakietu Subversion w moim systemie. Uruchomiłem coś 1.4., A kiedy zaktualizowałem do najnowszej wersji (w moim przypadku 1.6.6), kasa zadziałała.

(Próbowałem go ponownie pobrać, ale kasa do czystego katalogu zawsze wisiała w tym samym miejscu).

Blokowanie tylko do odczytu czasami zdarza się na dyskach sieciowych z systemem Windows. Spróbuj odłączyć i podłączyć ponownie. Następnie oczyść i zaktualizuj.

Po przejrzeniu większości przytoczonych tutaj rozwiązań nadal występował błąd.

Problem polegał na tym, że OS X nie rozróżniał wielkości liter . Sprawdzanie katalogu, który ma dwa pliki o tej samej nazwie, ale inna wielkość liter powoduje problem. Na przykład ApproximationTest.java i Approximationtest.java nie powinny znajdować się w tym samym katalogu. Gdy tylko pozbędziemy się jednego z plików, problem zniknie.

Wystąpił problem polegający na tym, że po aktualizacji SVN pokazywał folder jako będący w konflikcie. O dziwo, było to widoczne tylko z linii poleceń - TortoiseSVN myślał, że wszystko jest w porządku.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn updateIsvn resolve wszystkie były nieudane przy ustalaniu tego.

W końcu rozwiązałem problem w następujący sposób:

• Poszukaj w katalogu .svn „katalog_danych”
• Użyj RC -> Właściwości, aby odznaczyć flagę „tylko do odczytu” w pliku wpisów
• Otwórz plik wpisów i usuń wiersz „niedokończone ...” oraz odpowiednią sumę kontrolną
• Zapisz i ponownie włącz flagę „tylko do odczytu”
• Powtórz dla katalogu my_dir

Po tym wszystko było w porządku.

Uwaga: nie miałem żadnych lokalnych zmian, więc nie wiem, czy byłbyś zagrożony, gdybyś je zrobił. Nie użyłem metody usuwania / aktualizacji sugerowanej przez innych - przeszedłem do tego stanu, próbując tego w katalogu my_dir / sub_dir / sub_sub_dir (który zaczął się z tymi samymi objawami) - więc nie chciałem ryzykować pogorszenia sytuacji jeszcze raz!

Nie do końca na ten temat, ale może być pomocny, jeśli ktoś trafi na ten post tak jak ja.

Nie nie nie! Jeśli używasz SVN 1.7 lub nowszego, polecenie czyszczenia powinno wykonać zadanie!

Przeprowadziłem również pewne eksperymenty i odkryłem, że rozwiązaniem (przynajmniej w Eclipse ) było czyszczenie w przypadku folderu określonego w komunikacie o błędzie, a nie całego projektu!

Zrobiłem to, sudo chmod 777 -R .aby móc zmienić uprawnienia. Bezsudo tego nie działałoby, dając mi ten sam błąd co uruchamianie innych poleceń.

Teraz możesz zrobić svn updatecokolwiek, bez konieczności usuwania całego katalogu i jego ponownego tworzenia. Jest to szczególnie pomocne, ponieważ w twoim IDE lub edytorze tekstu mogą już być otwarte niektóre karty lub problemy z synchronizacją. Nie musisz usuwać i zastępować katalogu roboczego tą metodą.

Rozwiązałem ten problem, kopiując katalog .svn kolegi do mojego, a następnie aktualizując kopię roboczą. To było miłe, szybkie i czyste rozwiązanie.

Istnieje kilka bardzo dobrych sugestii w poprzedniej odpowiedzi, ale jeśli masz problem z TortoiseSVN w systemie Windows (dobry produkt, ale ...) zawsze wracaj do wiersza poleceń i najpierw wykonaj proste „czyszczenie svn”.

W wielu okolicznościach klient Windows nie uruchomi polecenia czyszczenia, ale czyszczenie działa dobrze przy użyciu narzędzia wiersza poleceń SVN.

W obliczu podobnego problemu ręczne scalenie w widoku synchronizacji repozytorium pomogło rozwiązać problem.

Jedna nazwa pliku powodowała konflikt z inną i wyraźnie wskazywała na problem. Zmieniło to nazwę nowego pliku na inną nazwę.