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');