Subversion
Subversion – scentralizowany system kontroli wersji o następujących właściwościach:
- Transakcyjność – operacja albo się powiedzie w całości, albo wcale. W praktyce zwykle działa, choć kilkakrotnie odnotowałem jakieś problemy.
- Tanie kopiowanie - pliki i całe poddrzewa katalogów mogą być błyskawicznie skopiowane w inne miejsce w obrębie tego samego repozytorium metodą copy on write.
- Pojęcia branchy czy tagów nie istnieją, ich czysto umowne ekwiwalenty uzyskuje się poprzez kopiowanie.
- Wersjonowanie całego repozytorium (a nie pojedynczych plików, jak to ma miejsce w przypadku CVS i VSS), co pozwala na traktowanie grupy zmian jako logicznej całości.
Mimo, że commit dotyczy całego repozytorium, to Subversion nie traktuje jego zawartości jako jednej całości i pozwala wykonywać operacje copy, merge itd. na poddrzewie katalogów, czy wręcz na poszczególnych plikach. Do wersji 1.4 włącznie nie stanowiło to większego problemu. Niestety, w wersji 1.5 autorzy postanowili wprowadzić merge tracking, czyli wspomaganie merge'owanie poprzez automatyczne śledzenie branchy i tego, co się z nimi dzieje, co doprowadziło do bałaganu, jaki jest obecnie (v1.6)...
[edytuj] Przyszłość
Program mimo swych wad ma też niewątpliwe zalety: jakość wykonania, stabilność, popularność no i oczywiście GUI pod Windows (TortoiseSVN). Docenili to ludzie od Apache'a i wzięli go pod swoje skrzydła. Teraz to się nazywa Apache Subversion, a beta wersji 1.7 jest dostępna do pobrania. Zachodzą tam rewolucyjne zmiany, na przykład:
- koniec z tysiącami podkatalogów .svn, będzie jeden na samym dnie kopii roboczej
- koniec z zaśmiecaniem properties plików i podkatalogów myriadami wpisów "svn:mergeinfo"....
Na pewno idzie to w dobrym kierunku, ale ja osobiście mam już Subversion powyżej uszu i nie wierzę, by w bliskiej przyszłości zdołali rozwiązać zasadnicze problemy. Dlatego definitywnie przechodzę z czym tylko mogę - dzisiaj do Mercuriala, może w przyszłości, gdy się nauczę, także do gita. Co i wam polecam :)
Niemniej jednak ściągnąłem sobie "betę" żeby potestować merdżowanie... Może i tak nachalnie się te propertisy nie propagują, ale nie rozwiązali podstawowego problemu: można zmerdżować kawałek projektu, podzbiór jego drzewa katalogów bądź wręcz pojedynczy plik. To powoduje wpisanie mergeinfo do najwyższego co prawda punktu merdżowania, jednak wciąż niekoniecznie będącego rootem projektu. Obawiam się, że póki tego nie zmienią, to nigdy nie będzie działać dobrze. Z drugiej strony zmienić tego za bardzo nie mogą, bo wszyscy się już przywyczaili, że SVN to wersjonowany zbiór plików i katalogów niekoniecznie tworzących spójną logicznie całość.
