HOVD 2014 - Kedvenc verziókezelő rendszer

HUP

bazaar
1% (6 szavazat)
clearcase
1% (6 szavazat)
cvs
3% (17 szavazat)
git
69% (467 szavazat)
gnu arch
1% (7 szavazat)
jazz
0% (1 szavazat)
mercurial
4% (27 szavazat)
perforce
0% (3 szavazat)
subversion
19% (128 szavazat)
team foundation server
2% (14 szavazat)
Összes szavazat: 676

( Joejszaka v | 2014. 12. 15., h – 14:33 )

Fura, hogy a Mercurial ilyen keveset kapott.

Az is furcsa, hogy valaki szereti manapság a subversiont.

De vágod, hogy nem az eszköz tehet arról, ha szarul használják. Gitolite tud olyant, hogy nem hozhat létre mindenki új branch-ot, aki egyébként push-olni tud.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ezzel abszolút egyetértek, viszont tapasztalataim alapján igenis vannak olyan eszközök, amik bevonzzák a helytelen használatot. Azaz természetesen lehet őket jól is használni, de az átlagos eszköznél jóval több embernek sikerül a szög helyett az ujjára ütni vele. Akár technikai értelemben, akár a józan észt tekintve. Ilyen például:

- Git
- PHP
- a LAMP stack úgy általában, különösen ha egy apt-get huszár rendszergazda "konfigurálja"
- apt-get
- VBA

És a listát még folytathatnám a végtelenségig. Hogy ne érje szó a ház elejét, hogy mindig bántom a Linuxot (sic), most a VBA-val fogok példálózni.

A VBA önmagában egy elég hasznos valami, nagyon sok időt tudtam már megspórolni a használatával, viszont 100 emberből max 1 érti úgy igazán, hogy mire jó. Értem ezalatt, hogy előző melóhelyen rendszeresen raktak rám olyan ticketeket, hogy ez meg az kéne VBA-ban. Jellemzően komplett projektmenedzsment rendszerek, meg hasonló szarok, amire a VBA természetesen nem alkalmas.

Eleinte szórakoztató ezeket a ticketeket egy "baszódj meg", "nooormális?" és hasonló megjegyzések közepette WONTFIX státuszba rakni, de amikor hónapokig csinálod, akkor egy kicsit unalmassá válik.

Régen git-eztem, hálistennek. Akkor vmi gitolite-al csináltam remote repot (merthogy nekem azt mondták az a legegyszerűbb). Az egy fapados komplikált szar amivel csak a szenvedés van. Mercuriallal jóval egyszerűbb egy remote repo, ssh elérés kell hozzá és pazony, működik sima unix authentikációval.

Mercuriálhoz van normális GUI, tortoisehg, ami pl. benne van az ubuntu és a fedora repojában is, nem kell forrásból fordítani és összegányolni vele a rendszert. Amikor én giteztem, akkor githez csak vmi használhatatlan eclipse plugin volt.

Mercuriálon van branch history, úgy tudom git-en olyan nincs.

"Mercuriallal jóval egyszerűbb egy remote repo, ssh elérés kell hozzá és pazony, működik sima unix authentikációval."

Ősidők óta így megy gittel is.

"Mercuriálhoz van normális GUI, tortoisehg"

tortoisegit.

"Mercuriálon van branch history, úgy tudom git-en olyan nincs."

giten vannak branchek, úgy tudom Mercurialon olyan nincs ;)

"tortoisegit."


$ yum list 'tortoise*'
Loaded plugins: langpacks, refresh-packagekit
Available Packages
tortoisehg.noarch 2.11.1-1.fc20 updates
tortoisehg-nautilus.noarch 2.11.1-1.fc20 updates
$

$ apt-cache search --names-only 'tortoise.*'
tortoisehg - Graphical tool for working with Mercurial
tortoisehg-nautilus - Graphical tool for working with Mercurial (Nautilus extension)
$

"giten vannak branchek, úgy tudom Mercurialon olyan nincs ;)"

Miért is?

Szerintem a Git-tel nincs különösebb szívás, csak kicsit jobban meg kell ismerni. Nem kellenek nagy dolgok, 5-10 parancs alapszintű ismeretével már jól el lehet lenni. Ha pedig így is nehéz, van több frontend is hozzá.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Vszínű, hogy az a fő bajom vele, hogy amikor használni kezdtem, akkor olyan útakra tereltek, amik nekem marhára nem fekszenek. Biztos nem kezdtem volna gitolite-al szarakodni, ha tudom, hogy egy egyszerű ssh elérés is megteszi (kevés emberes projekthez) unix athentikációval. A verziófa nézegetést és a diffelgetést is szívesebben csináltam volna vmi jó frontend-del, mint parancssorból. Nekem akkor annyit mondtak, hogy a git-et mindenki parancssorból használja.

Meg zavar a nagy hype körülötte. Amikor évekkel később megmutatták a Mercuriált, nagyon meglepődtem, hogy milyen fasza, stramm kis rendszer és még csak nem is hallottam róla.

Git-hez egyébként milyen frontend van, ami eléri a tortoise szintet és felmegy egy yum install-al alap repóból?

Szerintem git nem azért népszerű mert olyan jó lenne, hanem mert ehhez épült fel a legteljesebb ökoszisztéma (az összes ide támogatja, ott a github, bitbucket, stb.). Ennek ellenére én csak parancssorból merem használni egy kis segítséggel, nem azért mert szeretek parancssorban turkálni, hanem mert baromi körültekintően kell eljárni bizonyos műveletek során ami gui-n kevésbé lehetséges a kevesebb kijelzett információ miatt.

Hogy nem olyan jó? Pont amiatt, mert mindent meg lehet benne csinálni, gyors, és van mellé ökoszisztéma, pont ezek miatt lesz mégiscsak _JÓ_. Az edit-commit-push loopnál bonyolultabb dolgokhoz pedig mindig kelleni fog körültekintés, bármilyen vcs-t használsz. Már ha egyáltalán támogat ennél bonyolultabb dolgokat a vcs. (Lásd svn branching)

Szerintem sok-sok nagyságrenddel kevesebb ember élete lenne nehezebb, ha mondjuk holnaptól nem lenne Git, mintha mondjuk Excel.

A Git azért meglehetősen sokat köszönhet annak, hogy a Torvalds hype adott neki egy kis hátszelet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Aki refactorált már úgy, hogy több repót is érintett, az átérzi, hogy miért jó ez.

Nálunk is van kb. 4-5 repo, vannak kapcsolódások egy-egy projekt között, most már sokkal egyszerűbb lenne egybe rakni az egészet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( mortein79 | 2014. 12. 15., h – 19:50 )

Bazaar elég keveset kapott...Kár.

Mintha ő lenne a CVS-ek linuxa...

( NPeete | 2014. 12. 15., h – 20:45 )

1 év alatt megtanultam tisztelni (és majdnem már szeretni is - azért túlzásokba ne essünk) a perforce dolgait. Ezek után ráugrasztottak gitre egy projektmunka kapcsán, köpni-nyelni se tudtam, valamint számomra jóval kényelmetlenebb volt egy központosított repos fejlesztésre mint a p4. Nem mondom, hogy ultimate eszköz a p4, de azért ment rá egy voks.

( sarkanyolo v | 2014. 12. 19., p – 18:33 )

Melyik git klienst használjátok?

- git (mert terminalban nyomom)
- fugitive
- git gui
- gitk
- ha barmikor eclipse/netbeansben vagyok, akkor inkabb terminal, es git
- ha ennel fenszibb kell, akkor gitlab (ha van. magamnak termeszetesen nem allok neki telepiteni :) )

szerk.: amugy nem is erzem hianyat barmilyen GUI-nak. Nem vagyok az a terminal-fanboi, de mit tudna egy gui nyujtani? A pull-commit-push trio vagy brancheles nem egy bonyolult hadmuvelet (kiveve, ha nem egesz fajlokat, hanem soronkent commitolsz, na akkor elokerul a git gui meg az eger), az ennel bonyolultabb dolgok (pl. rebase, cherrypick, history rewrite) meg mar eleg bonyolultak ahhoz, hogy ugyanannyi idot vegyen el egy wizard vegigolvasasa-gondolasa-kattintasa, mint a man oldal vagy egy google search megtekintese.

( fabian-bros | 2014. 12. 25., cs – 11:59 )

A hat clearcase szavazo viccbol kattintott ra, vagy tenyleg azt szeretik a legjobban?
Ha igen, miert? (bonus kerdes: milyen adatot kovetnek benne? pl: forraskod, office dokumentumok, stb.)

--------------------------------------
Unix isn't dead. It just smells funny.

Szia!

Az egyik én vótam :)

Sajnos csak a ClearCase-t és az SVN-t ismerem, szóval közel sem tudtam tudományosan elég megalapozott szavazatot adni, de a kérdés amúgy is a kedvenc, és nem a legjobb volt :) Ráadásul csak annyira ismerem mindkettőt, amennyire szükségem volt rá. Lehet, hogy idén már a Git-et is használni fogom, és ki tudja, talán a kedvencem lesz.

ClearCase-t használtam életemben először, nagyjából három éven át. Egyik hátrányaként említeném, hogy nem volt egyszerű beletanulni. A másik, hogy ha meghal a szerver vagy a hálózat, akkor aztán nincs semmi :) Csak forráskódot követtem benne, de ezek elég komplikált rendszerek voltak, összesen akár több száz fejlesztő munkájával.

Ami legjobban hiányzik belőle:
- config spec: A vob(repo) minden eleméről meg tudtam mondani, hogy melyik verziót szeretném használni. Ha az egyik mókus becsekkol valami baromságot, és nem fordul a cucc, akkor az övéből egyszerűen visszatérek egy régebbi verzióra, vagy fel sem veszem az újat, míg a sajátomból a legutolsót látom. SVN-ben először megvárom, míg egy időzónával arrébb beér a mókus, aki felel érte, majd valamikor kijavítja és becsekkolja. Vagy mehetek vissza az enyémmel is a régebbire. Biztos van erre is megoldás SVN-ben, de nem egy sort átírni, hogy mit szeretnék látni. De jól jött például akkor is, ha változott az interface a modulomon, mert becsekkolhatom addig is, amíg a rendszer többi részét nem igazították hozzá, legfeljebb nem használják mások.
- A fileoknak volt verziója, nem az egész reponak. Egyrészt file verziószámok 1, 2, 3, stb. voltak, nem 7748, 9983, 11521. A saját dolgaim közt könnyebb volt eligazodni. Másrészt ha becsekkoltam egy filet, a komment hozzá tartozott, nem az egész hóbelebanchoz. Az látta, akinek köze volt hozzá, és aki tudta, hogy egyáltalán miről van szó. Ezért ha SVN-ben becsekkolok egy filet, akkor a kommentbe bele írom a teljes elérési utat, hogy legalább azt tudjuk, melyik filehoz tartozik.
- Könnyen hozzáférhettem a file összes verziójához. Tudom, hogy ilyen van SVN-ben is, de CC-ben könnyebb volt. A verziókra is működött a tab-os kiegészítés :)
tkdiff abc.c@@/main/LATEST abc.c@@/main/1
- reserved checkout: Ha kicsekkoltam valamit, akkor más nem tudja módosítani. Ennek persze van hátránya is, de az is tuti, hogy nem csekkol alám. Hülyéskedni meg ott volt az unreserved checkout, aztán legyen az én bajom, ha más beletúr, míg reszelem.
- release label: Valaki írt valami scriptet, ami rátette egy modul összes fileára a labelt, és nekem csak azt kellett az integrációért felelős embernek elmondanom, hogy melyik release labelt tegye be.
- Nem kellett semmit letöltögetni, a vob(repo) elérése hálózaton keresztül ment. Ennek megvan az az előnye, hogy ha a repoban esetleg vannak több száz MB-os fileok is, amit nem használok, akkor nem kell megvárnom, amíg azokat lehúzza. Hátránya, ha nincs hálózat/server, nincs munka.

Lehet, hogy én nem értek az SVN-hez, de a véleményem ez:) Több kollégámé is hasonló.

Üdv,
Bálint