Uruchamianie SVN na kopii plików katalogu repository
Niniejszą procedurę stosuje się, gdy posiadamy kopię plików w katalogu repository z przenoszonego serwera lecz z jakichś powodów nie posiadamy kopii samego SVNa i nie zależy nam na poprzednich wersjach plików a jedynie na ich ostatnich aktualnych wersjach.
Czyszczenie repozytorium oraz lokalnej bazy
cd /home/<user> rm -rf repos rm -rf repository/.svn
Tworzenie bazy repozytorium
svnadmin create repos cd repository svn checkout file:///home/<user>/repos .
Następnym krokiem jest wyszukwanie oraz usunięcie wszystkich katalogów .svn z repository.
# Wyszukiwanie find . -name .svn
# Usuwanie find . -name .svn -type d -print0 | xargs -0 rm -r --
Wykonujemy commit wszystkich plików znajdujących się w katalogu repository_2 oraz nadajemy uprawnienia dla użytkownika www-data
svn add repository_2 cd repository_2 svn ci -m "Komentarz" cd .. chown -R www-data:edokumenty repository repos chmod -R u+rwX,g+rwX,o-rwx repository repos
Naprawa SVN po aktualizacji systemu Linux
W przypadku gdy po aktualizacji dystrybucji Linuxa podczas edycji plików w eDokumentach a następnie po ich zatwierdzaniu 'commit' otrzymujemy poniższy komunikat
$ svn status svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/home/edokumenty/repository' is too old (format 10, created by Subversion 1.6)
Wszystkie czynności wykonujemy na użytkowniku www-data, w przypadku wykonywania komend z innego użytkownika po zakończeniu prac należy zweryfikować uprawnienia do katalogów.
W tym celu należy zaktualizować aktywną kopię plików. W tym celu używamy polecenia
svn upgrade
które wykonujemy na katalogu z aktywną kopia repozytorium czyli - /home/edokumenty/repository. Ponownie sprawdzamy stan repozytorium
svn status lub svn st
Ostatnim poleceniem jest
svn cleanup
Naprawa SVN w przypadku otrzymania komunikatu o nie prawidłowej wersji pliku
svn ci file_1652969.xlsx -m "" Wysyłanie file_1652969.xlsx svn: Zatwierdzenie nie powiodło się (szczegóły poniżej): svn: Plik '/repository_2/2016/10/05/file_1652969.xlsx' jest nieaktualny
Wykonujemy kopię pliku
cp file_1652969.xlsx file_1652969.xlsx_backup
Podnosimy wersję
svn up file_1652969.xlsx Odkryto konflikt w 'file_1652969.xlsx'. Wybierz: (p) odłóż, (mf) moje w całości, (tf) ich w całości, (s) pokaż wszystkie opcje: mf G file_1652969.xlsx Uaktualniono do wersji 12228.
Przywracamy wersję pliku
p file_1652969.xlsx_backup file_1652969.xlsx
Wykonujemy commit, zatwierdzenie wersji
svn ci file_1652969.xlsx -m "" Wysyłanie file_1652969.xlsx Przesyłanie treści pliku. Zatwierdzona wersja 12229.
Wersja pliku działa już poprawnie. Ale aby wszystko zgadzało się z otwarciem wersji z właściwości pliku musimy zmodyfikować wpis w tabeli versions
SELECT * FROM versions WHERE fileid='1652969';
Następnie aktualizujemy numer wersji w bazie
begin; UPDATE versions SET revnum = '12229' where ver_id='1010771';
gdzie revnum to numer wersji z commita z wykonanego z konsoli Gdy wszystko jest poprawnie to zatwierdzamy zmiany {{ commit; }}}
Naprawa plików, w przypadku których wystąpiły konflikty
svn resolve --accept mine-full {ścieżka_do_pliku}
Po wykonaniu powyższego zapytanie zatwierdzenie zmian możemy wykonać z konsoli lub z poziomu eDokumentów
svn ci -m "Komendarz" {ścieżka_do_pliku}
Zmiana lokalizacji REPOS oraz REPOSITORY
W przypadku gdy zmieniamy lokalizację plików repos oraz repository z domyślnych /home/edokumenty/repos, /home/edokumenty/repository na inną.
svn info URL: file:///home/edokumenty/repos Relative URL: ^/ Katalog główny repozytorium: file:///home/edokumenty/repos UUID repozytorium: 727ada91-bd74-4ca9-ad1f-7a7634465e4f Wersja: 1 Rodzaj obiektu: katalog Zlecenie: normalne Autor ostatniej zmiany: www-data Ostatnio zmieniona wersja: 1
Po przeniesieniu folderów do nowej lokalizacji.
cd /home/edokumenty-test/repository
svn relocate file:///home/edokumenty/repos file:///home/edokumenty-test/repos .
svn info Working Copy Root Path: /home/edokumenty-test/repository URL: file:///home/edokumenty-test/repos Relative URL: ^/ Katalog główny repozytorium: file:///home/edokumenty-test/repos UUID repozytorium: 727ada91-bd74-4ca9-ad1f-7a7634465e4f Wersja: 1 Rodzaj obiektu: katalog Zlecenie: normalne Autor ostatniej zmiany: www-data Ostatnio zmieniona wersja: 1
Problemów z kolejką SVN podczas uruchamiania cleanup
Komendę svn cleanup wykonujemy tylko przy wyłączonym system eDokumenty. Tak aby pracownicy nie mogli dodać nowego dokument do svna
www-data@eDokumenty:/home/edokumenty/repository# svn cleanup svn: E155009: Failed to run the WC DB work queue associated with '/data/edokumenty/repository', work item 127620 (file-install 26 2018/03/12/file_522565.rtf 1 0 1 1) svn: E155017: Can't install '/data/edokumenty/repository/2018/03/12/file_522565.rtf' from pristine store, because no checksum is recorded for this file
Jeśli nie mamy sqlite3, wykonujemy polecenie
apt-get install sqlite3
Następnie wchodzimy do folderu:
cd /home/edokumenty/repository sqlite3 .svn/wc.db "delete from work_queue"
Problemy z repozytorium po użyciu polecenia cleanup
Przypadek gdy nie wyłączymy systemu eDokumenty i uruchomimy polecenie cleanup użytkownicy nadal mogą dodawać pliki do svn. W takim przypadku może dojść do zablokowania. Poniżej jeden ze sposobów rozwiązania tego problemu.
www-data@eDokumenty:/home/edokumenty/repository$ svn cleanup svn: W katalogu '2018/01/14' svn: Błąd podczas wykonywania polecenia 'committed' w '2018/01/14' svn: Nie można przenieść '2018/01/14/.svn/props/file_111111111.rtf.svn-work' do '2018/01/14/.svn/prop-base/file_111111111.rtf.svn-base': Nie ma takiego pliku ani katalogu
Tworzymy kopię pliku, którego dotyczy problem.
cp -rp /home/edokumenty/repository/2018/01/14/file_111111111.rtf /home/edokumenty/backup_svn
Następnie tworzymy pusty plik w lokalizacji, którą wskazał komunikat o błędzie:
cd /home/edokumenty/repository/2018/01/14/.svn/props/ touch file_111111111.rtf.svn-work
Ponownie wykonujemy polecenie
svn cleanup
Wycofywanie zmian na plikach w SVN
svn revert /home/edokumenty/repository/2018/01/14/file_111111111.rtf
Błędy sum kontrolnych MD5 podczas wykonywana svn upgdare
Podczas wykonywania aktualizacji SVN, ma to miejsce np podczas aktualizacji systemu Debian z wersji 7 do 8 konieczna jest aktualizacja SVN, którą wykonujemy komendą svn upgade. Może zdarzyć się tak, że plik będzie uszkodzony, podczas aktualizacji jest sprawdzana suma kontrolna pliku, system zgłosi nam to poniższym komunikatem:
svn: E155016: This working copy is corrupt and cannot be upgraded. Please check out a new working copy. svn: E155016: Bad base MD5 checksum for '/home/edokumenty/repository/repository_2/2016/06/15/file_4689242.rtf'; expected: 'd41d8cd98f00b204e9800998ecf8427e'; found '05106e77bb5346920031a8275944e930';
Aby to poprawić należy edytować plik entries znajdujący się w lokalizacji pliku
vim /home/edokumenty/repository/repository_2/2016/06/15/.svn/entries
Odszukujemy tam linię z nazwą naszego pliku a następnie podmieniamy obecny MD5 na ten którego oczekuje SVN podczas weryfikacji. Po zapisaniu plik możemy ponownie użyć komendy svn upgade.
Wycofanie zmian oznaczenia do usunięcia
W przypadku gdy mamy oznaczony folder do usunięcia
root@eDok:/home/edokumenty/repository# svn st
D C repository_2
> local dir unversioned, incoming dir add upon update
? repository_2/2023
Podsumowanie konfliktów:
Konflikty drzewne: 1
Możemy wykonać polecenie do wycofania zmiany
svn revert . --recursive
Uruchomienie SVN na środowisku testowym w przypadku gdy test jest aliasem a nie vhostem
W pliki config.inc dla środowiska testowego modyfikujemy odpowiednio wpis dotyczący WEBDAV_URL
define('WEBDAV_URL', 'edokumenty.webdav:'.SELECTED_PROTOCOL.'://192.168.50.51/test/apps/edokumenty/webdav2.php');
