HOVD 2010 - Kedvenc verziókezelő rendszer

HUP

bazaar
5% (29 szavazat)
cvs
8% (46 szavazat)
darcs
0% (1 szavazat)
fossil
0% (1 szavazat)
git
36% (217 szavazat)
gnu arch
1% (4 szavazat)
mercurial
6% (36 szavazat)
monotone
0% (0 szavazat)
subversion
43% (259 szavazat)
svk
1% (4 szavazat)
Összes szavazat: 597

( crystal88 | 2010. 12. 01., sze – 17:01 )

tud vki vmit mondani az svn mellett a git-tel szemben? (mondjuk a jobb IDE integrációt leszámítva)
Valahogy az az érzésem hogy az svn userek azért svn userek mert még nem láttak git-et :)

Jo, hat szar dontest en is tudok hozni, attol meg nem lesz jo, mert meghoztam ;)

(Foleg ceges kornyezetben tartom egyebkent furanak, hogy ez szempont. LAN-on kurvagyorsan atjon, a mai hdd mereteknel meg nehogymar a repo merete legyen a szempont; ha meg remote kell checkoutolni: egyszer kell egy nagyot. big deal. Ha pedig laptopra kell, hat akkor esetleg vagjak kisebb darabokra, es submodules ;)

Jo, hat szar dontest en is tudok hozni, attol meg nem lesz jo, mert meghoztam ;)
esetleg vagjak kisebb darabokra, es submodules ;)

Nem volt az olyan szar döntés, és akkoriban a Git submodules támogatása igencsak gyengécske volt. Ha volt.

LAN-on kurvagyorsan atjon

És a VPN-en?

Ne érts félre, nem kötözködni akarok, de egyszerűen vannak olyan helyzetek, ahol az SVN egy elég jó döntés lehet. Pláne akkor, ha a decentralizáltság is hátrány.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Szerintem meg ilyen esetben el kene gondolkodni hogy esetleg nem egy repoba kene tenni mindent, hanem logikusabb darabokban tarolni. Maris csak akkor 300g, ha tenyleg a teljes repo kell a T. usernek. Ha meg a teljes kell, akkor ugyis at kell huznia az egeszet (de, DVCS eseteben akkor is csak egyszer; mondjuk 300g VPN-en tenyleg nem egy orom, de ott imo mar ennel komolyabb problemak vannak, mint a meret maga).

Én még olyant is hallottam, hogy filmek vágásához használt nyersanyagokat tartottak verziókezelőben. Nyilván én is tudom, hogy a verziókezelő rendszereket nem erre találták ki, de azt szedd szét több repóra. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Felvagas apro darabokra. Kiveve ha tenyleg nagy fileok vannak, es nem csak sok (+ sok history), mert akkor peched van. git eseteben akkor segit git-annex valamennyire, valamint a -bigfile fork (ha azt meg nem mergeltek vissza... de ugy lattam hogy 2009-es az utolso commit bele, igy konnyen lehet hogy az mar gitben is benne van, vagy mas okbol szakadt meg a fejlesztese).

Nem feltetlenul.

1. A githez (ahogy te is iertad) kicsit nehezen jonnek a GUI-k, talan mar lassankent van hasznalhato beloluk. SVN-hez meg vannak mar regota egesz jok. Ez ugye hatraltatja a git elterjedest. Ha pedig mar valaki hasznal egy kornyezetet, akkor nagyon nyomos ok kell a migralashoz. Tehat, hiaba jobb mondjuk a git, ha nekem potn nem kellenek azok a featureok.

2. Nem az svn mellet, csak altalanossagban: a clearcasen felnott fejlesztoi (de)generaciok nem hogy az eloszott repositorykat nem ertik, de csak reserved checkoutokban es kizarolag file szintu verziomanagementben tudnak gondolkodni. Na ezek mar sokkal sulyosabb problemak. Kulon kulon is, hat meg egyutt.

( sz | 2010. 12. 13., h – 14:40 )

Nahát, csak öt százalék a különbség? Valahogy nagyobbra számítottam.

( bervi | 2010. 12. 20., h – 17:22 )

engem sokkol, hogy a mercurial-t még a cvs is megelőzi, pedig nagyon fasza vcs...