WebSVN | Closer to Code

Not long ago I've migrated last of my SVN-managed projects into Git with GitLab (finally!). Everything was OK, until this message occurred, when I tried to do an web-based repository file update:

Your changes could not be commited, because the file has been changed

After googling I've executed following command (because I didn't create satellites earlier):

sudo -u git -H bundle exec rake gitlab:satellites:create RAILS_ENV=production

Unfortunately this didn't solve my problem (although I'm pretty sure, that either way this was required). I've decided to check GitLab logs, but unluckily nothing suspicious was there. I suddenly remembered, that by default all my Rails/Rack Passenger applications are executed using www-data user. This was a good guess. I've added a user declaration in Apache vhost configuration file:

PassengerUser git

and after that I've finally started to get some new things in application log:

Errno::EACCES (Permission denied - /home/git/gitlab/tmp/satellite_15.lock):
  lib/gitlab/satellite/satellite.rb:57:in `initialize'
  lib/gitlab/satellite/satellite.rb:57:in `open'
  lib/gitlab/satellite/satellite.rb:57:in `lock'
  lib/gitlab/satellite/action.rb:23:in `block in in_locked_and_timed_satellite'
  lib/gitlab/satellite/action.rb:22:in `in_locked_and_timed_satellite'
  lib/gitlab/satellite/edit_file_action.rb:22:in `commit!'
  app/controllers/edit_tree_controller.rb:18:in `update'

All my satellite locks were created by www-data user with different set of privileges, so git user was not able to use them. After I removed all the locks and restarted both GitLab and Apache server, everything started to work just fine:

sudo rm /home/gitlab/tmp/satellite_*
/etc/init.d/apache2 restart
/etc/init.d/gitlab restart

Zanim zajmiemy się stricte tym jak używać SVNa i narzędzi do niego, zapoznajmy się z kilkoma pojęciami które są kluczowe w pracy z systemami kontroli wersji:

Repozytorium (repository) - foldery i pliki znajdujące się na serwerze SVN. Repozytorium zawiera w sobie oprócz plików i katalogów, także historię zmian w tych danych. Dzięki temu możemy prześledzić każdą zmianę dokonaną w obrębie repozytorium.
Head - najnowsza wersja plików dostępnych w repozytorium (wersja aktualna).
Rewizja (revision) - dana "wersja" plików. Przy zatwierdzaniu zmian na serwerze, numer rewizj jest podnoszony o 1. Dzięki temu możemy przywrócić system do stanu np z rewizji numer 46. System przechowywania danych, ze względu na oszczędność miejsca, jest systemem przyrostowym. Oznacza to że zapamiętywane są tylko zmiany, nie zaś stan całego kodu.
Kopia robocza - nasza lokalna wersja kodów źródłowych. Możemy na niej dokonywać zmian, eksperymentować, bez ryzyka zniszczenia czy też uszkodzenia kodu. Zmiany które uznamy za poprawne wprowadzamy (commitujemy) do repozytorium.
Checkout - pobranie z repozytorium kodów w celu utworzenia swojej kopii roboczej.
Gałąź główna (trunk) - główna linia projektu. Bardzo często ta gałąź ma zawierać w sobie kod źródłowy który się kompiluje i przechodzi wszystkie napisane do niego testy.
Gałąź rozwojowa (branch) - gałąź "poboczna". W niej mogą być przechowywane nieskończone części kodu czy też kod zakończony częściowo. Kiedy w gałęzi tej kod zostanie już przetestowany i działa, można scalić ją z gałęzią główną.
Switch - przeskok między gałęziami w kopii roboczej.
Update - aktualizacja swojej kopii roboczej, plikami z repozytorium.
Commit - przesłanie naszych lokalnych zmian do repozytorium.
Merge (scalanie) - złączenie różnych gałęzi projektu w jedną.
Kolizja - sytuacja w której dany plik był modyfikowany przez różne osoby i w czasie scalania SVN nie mógł zdecydować która z wersji pliku jest poprawna. Musimy wtedy sami zdecydować którą wersję pliku uznać za właściwą.
Lock (blokada) - aby uniknąć sytuacji w której kilku programistów pracuje nad tym samym fragmentem kodu, można dane pliki zablokować. Po zablokowaniu inne osoby które chciałyby pracować nad danym plikiem, dostaną informację że nad tym plikiem ktoś już pracuje. Nakładanie locków pozwala uniknąć konfliktów przy mergowaniu.

Mając już podstawową wiedzę teoretyczną, zapoznajmy się z podstawowymi poleceniami jakie możemy wydawać z konsoli. Nie będę ich zbyt szczegółowo omawiał, ponieważ omówię narzędzia graficzne które bardzo ułatwiają pracę z systemami wersjonowania.

Tworzenie repozytorium

Tworzenie repozytorium z wiersza poleceń, jest relatywnie proste. Mając narzędzia Submin i WebSVN, musimy pamiętać tylko o tym, żeby tworzyć repozytoria w miejscach w których oba narzędzia je znajdą. Samo tworzenie repozytorium wygląda tak:

svnadmin create [nazwa repozytorium]

Tworzenie kopii roboczej

Utworzenie kopii roboczej, jest równoznaczne z pobraniem odpowiednich plików z serwera. Wykonamy to wpisując w wierszu poleceń następującą komendę:

svn checkout svn://aders_naszego_serwera/[nazwa repozytorium]/ [nazwa projektu]

Warto zauważyć że po utworzeniu kopii roboczej, w każdym katalogu będziemy mieli ukryty katalog .svn. Często jest w tych katalogach dużo plików, dlatego metoda "przeciągnij i upuść" w wypadku np. uploadowania projektu przez FTP może trwać bardzo długo.

Aktualizacja kopii roboczej

Aby zaktualizować naszą kopię roboczą, będąc w jej katalogu głównym wykonujemy następującą komendę:

svn update

Commit zmian na serwer

Przesłanie swoich zmian do głównego repozytorium także jest bardzo proste:

# Komentarz w którym opisujemy zmiany
svn commit -m "Komentarz"

I to by było na tyle jeśli chodzi o "konsolowe" podstawy. W następnej części zapoznamy się z Subminem.

Tag: WebSVN

GitLab: Your changes could not be commited, because the file has been changed

Debian (lub Ubuntu) i SVN (Submin, WebSVN) – mini słowniczek i podstawy użytkowania