HOVD 2010 - Kedvenc verziókezelő rendszer

 ( hup | 2010. november 30., kedd - 14:09 )
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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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 :)

Az semmi, de mi az érv a CVS mellett? Akármivel szemben?

cvs-hez van fastimport (lasd itt), amibol korrektul visszallithato a git repo is. svnhez tudtommal csak export van.

ergo cvs > svn. ezt is megeltuk!

(igen, tudom, hogy ez nagyon kifacsart ertelmezese az elonynek, de ha nagyon hunyorog az ember, akkor valahol logikus!)

vendor branch
partial repo checkout

peldaul

--
NetBSD - Simplicity is prerequisite for reliability

Azt tudja svn is. A partial repo checkoutot biztos, branchelni meg ugy branchelsz ahogy jol esik.

(Az mas kerdes, hogy CVS-ben mergelni ne akarj, mert abbol csak szomorusag lesz :P)

Git-tel csak nehézkesen oldható meg, ha nem akarod az egész repót letölteni és kezelni, csak egy alkönyvtárát. Nagyméretű repóknál ez szempont lehet.

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

Haat... Eleg hulye szempont, es ha jobban belegondol az ember, elegge elhanyagolhato is.

Nem feltétlenül, ismerek olyan céges projectet, ahol ez szempont volt.

Persze ettől függetlenül én is a Git-re szavaztam, bár a Bazaar se rossz. :)

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

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 ;)

Idézet:
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.

Idézet:
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."

submodules helyett ./bootstrap.sh, mint anno tla-s idokben! :P

VPN: Azon lassu, igen. De csak egyszer kell athuzni az egeszet, azt meg tul lehet elni. Hacsak nem india kozepen van a vpn egy 22k-s modemen ami 5 percenkent megszakad. Akkor tenyleg inkabb valami mas.

Hat nemtom, lattam en mar 300 giga feletti clearcase site-ot, amit 100-nal tobb fejleszto hasznalt parhuzamosan. Akarhogy gondolok bele, ilyen esetekben ez szempont, es nem is tunik hulyenek.

:wq

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."

http://git-annex.branchable.com/ sokat segit ebben ;)

(nekem ~120gb zenem van per pill gittel managelve, fenti extension segitsegevel)

És hogy oldottátok meg? Mercurial-ban ugyanez a problémánk, és mindenhol azt írják, hogy a Mercurial-t nem így kell használni.

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).

Igyekeztünk már eleve úgy kialakítani a rendszert, de ez is segíthet: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7

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

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.

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

Kar, hogy a clearcase kimaradt. :(

Jovore majd bekerulhet monotone helyere :)

--
|8]

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

engem az sokkolt, hogy a CVS barmit is megelozott.

--
|8]

jogos... na de a mercurial-t ?! :D

aki cvs-fan, elmondaná nekem, hogy miért szereti?

Szeret szívni a félbemaradt commit-okkal.

mert azt ismeri a legjobban (esetleg még nem is látott mást)

szomorú :)