Podczas pracy z SVN natrafić możemy podczas commitu na dość kuriozalny błąd. Szczególnie jeśli nasze repozytorium posiada z hakiem kilkadziesiąt tysięcy rewizji. Błąd typu:
|
1 2 3 |
Dodawanie wp-content/plugins/akismet svn: Zatwierdzenie nie powiodło się (szczegóły poniżej): svn: Plik już istnieje: system plików '/home/user/repo/db', transakcja '52329-dey, ścieżka '/wordpress/blog/wp-content/plugins/akismet' |
Może wytrącić z równowagi. Szczególnie dlatego, że uniemożliwia commit i np. pójście do domu..
Pomocne może być następujące działanie.
1. Zmieniamy lokalizację na folder nadrzędny i zmieniamy nazwę folderu z naszą kopią roboczą. Ważnie – nie usuwamy go bo stracimy w końcu naszą pracę.
|
1 2 |
cd .. mv blog blog-tmp |
2. Zgrywamy od nowa naszą kopię roboczą w te samo miejsce.
Najpierw musimy znać pełną ścieżkę. W tym celu używamy komendy:
|
1 |
svn info |
Ścieżka podana jest po dwukropku:
|
1 |
URL: [ścieżka] |
Zaznaczamy ją i kopiujemy. W terminalu to skrót:
|
1 |
CTRL + SHIFT + c |
Wykonujemy checkout – zgrywamy od nowa kopię roboczą.
|
1 |
svn co [ścieżka] |
ścieżkę wklejamy w terminalu poprzez komendę:
|
1 |
CTRL + v |
3. Wracamy do „niedziałającej” kopii roboczej i usuwamy pliki SVN:
|
1 2 |
cd blog-tmp find -name ".svn" | xargs rm -r |
(omawialiśmy tą komendę wcześniej na naszym blogu)
4. Przechdzimy do „nowej” kopii roboczej i wgrywamy pliki z „niedziałającej” kopii roboczej do naszej „nowej” kopii roboczej:
|
1 2 |
cd ../blog cp * ../blog-tmp/. -R |
Gotowe! Teraz należy skrupulatnie przeglądnąć zmienione przez nas pliki. Jeśli np. pracujemy w zespole – od momentu jak poprzednio zgraliśmy stare pliki – mogły nastąpić dodatkowe zmiany w zmienianych przez nas plikach. To rozwiązanie nie pozwoli uniknąć konfiktów i należy je ręcznie przepatrzyć.
Oczywiście możemy już zacommitować jak wszystko je O.K. i np. iść do domu 😉
