Każdy programista, prędzej czy później dotrze do momentu, gdy trzeba podjąć pracę w grupie (mnie to spotkało prędzej, ale dopiero teraz o tym piszę). Teoretycznie można wtedy wspólny projekt podzielić na moduły i pracować nad nimi niezależnie, a potem je sklejać. Da się, ale to szalenie niewygodne.
O wiele lepiej jest zaprząc do działania SVN. Z resztą ten system przydaje się nawet wtedy, gdy samemu sobie jest się sterem żaglem i okrętem. Myślę, że nie jednemu z nas po wielu godzinach pracy przyszło do głowy: „kurcze, jednak tamto rozwiązanie było lepsze”. Tylko co z tego, skoro „tamto” zostało już dawno skasowane.
Z resztą nie chcę w tym momencie nikogo przekonywać do SVN, bo do tego trzeba po prostu dojrzeć. A jak już ktoś poczuje potrzebę skorzystania z tego potężnego narzędzia, to polecam zapoznanie się z całkiem niezłym podręcznikiem do SVN
9 lis 2011 o 13:51
Ja osobiście o ile to oczywiście możliwe, polecam przesiadkę na GIT.
w mentaxie SVNa używaliśmy 5 lat – ale to co daje GIT stawia SVN na dalekiej pozycji.
9 lis 2011 o 17:05
Czemu nie Git? Obecnie zdobywa coraz większą popularność, duże projekty migrują z SVNa do Gita. Patrz: https://github.com/
Sam też dopiero go poznaję, więc nie potrafię go porównać z SVN, ale podobno łatwiej zarządza się gałęziami, nie wymaga centralnego serwera. No i Kohana też korzysta z Gita
https://github.com/kohana
9 lis 2011 o 17:08
Czemu nie Git? Bo na to nie zawsze ma się wpływ
9 lis 2011 o 19:01
Z tego co kojarzę Git ma wbudowaną obsługę SVN, więc można sobie lokalnie pracować z Gitem a commitować/pushować do SVN
9 lis 2011 o 20:16
Pewnie można tylko po co pracować lokalnie w Git a potem eksportować do SVN? Nie bardzo rozumiem sens takich ekwilibrystyk.
10 lis 2011 o 7:20
A dlaczego nie Mercurial? Rozumiem, że nie zawsze jest wybór, ale jednak Git czy Mercurial oferują większe możliwości… To taki, SVN na sterydach.
12 lis 2011 o 0:09
Na przykład – pracujesz przy jakimś dużym feature, i nagle okazuje się, że musisz na szybko wprowadzić kilka fixów – w git zrobienie brancha lokalnego na zmiany to jedna czy dwie komendy (kliknięcia) – dzięki czemu zmiany z tego dużego feature, które nie są dokończone, przetestowane nie maja wpływu na główną gałąź.