2017-02-12 111 views
9

Przeczytałem tę odpowiedź: How do I return to an older version of our code in Subversion? i użyłem polecenia svn merge -r 150:140 ., aby powrócić do starej wersji (nie musiałem zatwierdzać cofniętych zmian, wystarczy przejść do starej wersji plików). Wcześniej miałem czystą wersję repo w wersji 150 (brak ręcznych zmian w plikach). Niestety, mam tych ostrzeżeń:Nie udało się cofnąć zmian w przypadku niektórych pomijanych ścieżek.

... 
Skipped 'some/file.h' 
Skipped 'some/file2.h' 
... 
Skipped 'some/file3.h' 
Skipped 'some/file4.h' 
... 
Summary of conflicts: 
Skipped paths: 4 

który zaskakuje mnie widząc, jak wszystko, co chciałem zrobić, to wrócić do jakiejś starej wersji plików (i nie miałem żadnych zmian wcześniej).

Co mogło być przyczyną? Jak dostać się do starej wersji?

Edit: I zostały sprawdzone i najwyraźniej te pliki nie istnieją w wersji currrent (150) (zarówno na dysku lub w SVN):

svn: warning: W155010: The node 'some/file.h' was not found. 

Ale nie istnieje w wersji 140. Tak gdzieś po drodze zostały usunięte. Ale dlaczego SVN nie może ich przywrócić?

+0

Gdyby nie zmienia nazwy plików? Subversion nie radzi sobie dobrze z nazwami. – andref

+0

Nie, te pliki zostały właśnie usunięte. – NPS

+0

Jaki jest wynik działania 'svn stat'? – Constantin

Odpowiedz

4

Najczęstszą przyczyną takiego konfliktu z drzewem jest to, że twoja kopia robocza uległa pewnym zmianom, a następnie próbujesz się połączyć - mogą się zdarzyć złe rzeczy. Po prostu zgadywanie na wyjściu może być związane z folderem "some" (to znaczy, jeśli cały folder został usunięty między wersjami 140 i 150 - nie tylko plikami, lub jeśli przed scaleniem miałeś jakieś lokalne zmiany w pomijanych plikach).

W przypadku takiej sytuacji w przyszłości, spróbuj przywrócić uszkodzony seryjnej poprzez wykonanie:

svn revert --recursive 

Powrót na rewizji 150 usunąć wszelkie niewersjonowane pliki & foldery z kopii roboczej i ponownie scalanie za pomocą

svn merge -r 150:140 -v --force . 

(-v wyświetli bardziej opisowy informacje, --force usunie pliki z kopii roboczej, nawet jeśli zostały one zmodyfikowane lokalna)

W przypadku gdy wszystko inne zawiedzie, ostatecznością jest zawsze tylko kasa świeżą kopię roboczą z rewizji 140 do nowego folderu lokalnego z wykorzystaniem

svn checkout -r 140 $your_url 
+0

"Wcześniej miałem czystą wersję repo w wersji 150 (brak ręcznych zmian w plikach)." – NPS

+0

Bez dodatkowych informacji o zmianach svn i statusie kopii roboczej, możemy jedynie zgadywać, co naprawdę było główną przyczyną. – Constantin

+0

Wiem, że napisałem to w komentarzu do mojego pytania. – NPS