= 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/ rm -rf repos rm -rf repository/.svn }}} Tworzenie bazy repozytorium {{{ svnadmin create repos cd repository svn checkout file:///home//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'); }}}