Az bude mit GIT takovou podporu v SW jako ma CVS, budu o tom uvazovat, ale do te doby pojedeme na CVS. Vim o jeho problemech, ale pri prizpusobeniprace jeho vlastnostem, je dobry nastroj, kde ma problem hlavne spravce, vyvojar obvykle ne.
SW myslim hlavne ruzne profi baliky pro navrhy, ktere maji podporu pro par proprietarnich protokolu a pak jeste CVS, nutit vyvojare, aby mel vedle dalsi nastroj aby mohl spravovat verze, je utopie.
Bohuzel taky musim souhlasit. Dalsim duvodem je kompletni zmena prace tymu. Takze se zase musite prizpusobit novym podminkam:). Prace s GIT nebo Mercurial je mnohem slozitejsi, nez s CVS/SVN, ale taky mate mnohem vyssi moznosti! Slucovani dvou vetvi projektu je v Mercurial nebo Git velmi jednoduche i v pripade konfliktu, kdy je videt stav zdrojaku obou vetvi plus jak to vypadalo pri rozdeleni vetvi(base)!
Jak delat merge v CVS jsem se marne pokousel docela dlouho. Muze to byt tim, ze Nikdo u nas neudelal upgrade na novou verzi CVS uz nekolik let, ale aspon to funguje a mame historii nekolik let ... a nejak s tim zijeme a asi budeme zit i dal. Nekdy je slozite presvedcit nektere kolegy, aby investovali cas do uceni se Gitu nebo Mercurial, pro ne je jednodussi porad dokola delat bugfixy do 2 vetvi a HEAD ...
:-) Ten zaver ma trochu pobavil. Merge v CVS do viacerych branchov ide urobit bez problemov rovnako ako asi vo vacsine podobnych systemov. Kolegovia pouzivali TortoiseCVS klienta a mergovali krizom krazom do 4-5 verzii sucasne.
GIT je k nezaplacení pro malé projektíky typu školní úlohy nebo osobní skripty. Nepotřebuje žádný server ani složité nastavování, jede prostě v aktuálním adresáři. To je sice mizivé využití jeho možností, ale u mě nejčastější.
To přeci můžete udělat s SVN taky. Sice si drží repozitář v jiném adresáři než aktuálním (nevím jestli to jde ještě nějak jinak), ale jde o pouhý adresář se soubory na disku. Žádný server také nepotřebujete.
Doporučuji zkusit ;)
Zrovna jsem v práci a tady se k tomu nedostanu. Nepamatuji si už jak jsem vytvářel repository (zřejmě standardním způsobem s využitím utility svnadmin). Přístup k repository je pak řešen pouze uvedením protokolu file:///
Tadyhle je tuším příklad http://www.abbeyworkshop.com/howto/misc/svn01/
Jen se tam hovoří o tom, že není povoleno vytvářet repository na síťovém disku, což myslím není už úplně pravda, ale nikdy jsem nic takového nezkoušel.
Pro běžnou práci je pak dobré využít pluginy pro různá IDE nebo něco jako TortoiseSVN pokud IDE podporu nemá (nebo žádné nepoužíváte)
TortoiseSVN je super, ale jen pro Windows. Jinak používám SmartSVN, to je taky bezva a už jsem si na něj tak zvykl, že ho používám i v těch Widlích. (k dokonalisti mu chybí snad jen to, aby bylo open source).
Tak ten neznám. Osobně nepoužívám ani ten Tortoise, jen se používal u nás v práci. Nemám ani ty Widle ;). Pracoval jsem buď z příkazové řádky a nebo pak pluginy v NetBeans nebo Eclipse, což byla potom pohoda.
Na sitovem disku ho nelze pres file:// pouzit pro vice vyvojaru. Pokud je to soukromny repozitar do ktereho pristupuje vzdy jenom jeden clovek najednou, tak nevidim duvod proc by se to nemelo chovat uplne stejne jako soubor na lokalnim disku.
Nechápete podstatu. GIT byl vytvořen pro řešení velice specifických potřeb vývoje kernelu, které CVS a podobné uspokojit nedokázalo. Pokud budete mít podobné potřeby na vysoce distribuovanou správu verzí mezi velkým množstvím vývojářů a stovkami větví, pak budete moc rád GIT používat, ať už má podporu v SW nebo ne, protože bez GITu si hodíte mašli i s podporou v SW (nebo zaplatíte balík za komerční revizní systém s podobnými schopnostmi). Samozřejmě se dá GIT použít i v jiných scénářích, ale nikdo vás nenutí ho používat pokud vám jiný systém poslouží lépe.
Doporučuji přechod alespoň na SVN, se kterým má GIT dobrou spolupráci (příkaz git-svn). Pak se může každý vývojář rozhodnout, jestli bude dělat nativně na SVN, nebo bude komunikovat zprostředkovaně přes GIT a využívat tak jeho featury (lokální branche, rebase, stash...). Zbavíte se alespoň spousty neduhů v CVS.