HOVD 2014 - Kedvenc verziókezelő rendszer

 ( trey | 2014. december 15., hétfő - 7:17 )
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

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

Fura, hogy a Mercurial ilyen keveset kapott.

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

Én vállalom. :)

Bár git-et is használok, de bonyolultabb, ha pedig nincs szükség az extra feature-ökre, akkor ez csak teher. A git féle branch merging és a cherry-picking persze azért jó lenne az svn-be is.

(Nem programozó vagyok.)

A legtöbb értelmes IDE kezel gitet, nem látom értelmét mást használni.

Nekem a fő bajom a gittel, hogy a gitet használó csapatokban hajlamosak a csapattagok bekattanni és valahogy szétk*rni a workflow-t. Értsd ezalatt például olyan branchek generálása, amit már a végén senki nem tud követni, hogy mi honnan származik.

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.

Persze, de azért vannak olyan eszközök, amik erős táptalajt adnak arra, hogy szarul használják. Ld. ilyen enterprise hupu technológiákat, mint C meg a PHP.

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

Kedeves nemet cegek vaskalapos modon ragaszkodnak hozza.
Szerencsere a git tudja kezelni, de attol meg borzadaly.

Köszi, remek ötletet adtál, sajnos itt is ragaszkodnak hozzá, és nem német.

http://lostechies.com/derickbailey/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches/

Ezt feltettem a fakultatív olvasmányok listájára, meg a git-et is feltettem.

Én a SVN-re szavaztam. Mi vele a baj?

Erre is volt találatom:
https://git.wiki.kernel.org/index.php/GitSvnComparison

Bár ezt a git fejlesztői oldalán írják, és nehéz a "Git is much faster than Subversion"-ekből kihámozni konkrétumot.

Szerintem semmi.
Miért ne lehetne ez a kedvenced?
Bizonyos fejlesztőknek én is inkább az SVN-t ajánlom. Másoknak mást.

Fuszenecker_Róbert

A git gondolom a linux és az egomán Tolvards miatt népszerű, miközben messze elmarad a Mercurial-tól.

Igen, biztosan. Olyanok, mint a DragonFly BSD projekt a Linux és Torvalds miatti mély tiszteletük miatt és nem technikai érvek miatt váltanak rá. BS.

--
trey @ gépház

Miben marad el? Mercurial egyetlen elonye, hogy egyszerubb kicsit. Ezert lehet jo svn-rol valtasra. (Amugy mercurial python.) :)

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?

Ha régen Git-eztél, miért mondasz ilyen markáns véleményt róla? Pláne, ha igazán meg sem ismerted.

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

Mert mély nyomokat hagyott bennem. Már akkor is nagy volt a hype a git körül. Senki nem említette, hogy létezik a Mercuriál is, amivel közel sincs annyi szopás.
Vhogy a Tolvards-nak kibaszott nagy marketing értéke van és hype-olják a cuccait ha kell ha nem.

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?

Nem túl szép, nem túl integrált, de két GUI-s appot szoktam használni, ha nagyon muszáj (leginkább a fa nézegetésére, vagy soronkénti kommitra bontáshoz)
- gitk (vagy gitg)
- git gui

Én is meglepődtem, azt hittem népszerűbb.

git vs. mercurial:
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

Esetleg valami nem ~6 éves összehasonlítást is megnéztél?

Hint: azóta gitbe is került egy-két újdonság. A világ meg átállt gitalapra. Láasd még: github.

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)

"hanem mert ehhez épült fel a legteljesebb ökoszisztéma"

A kérdés az, hogy miért ehhez épült fel néhány év alatt a legteljesebb ökoszisztéma és nem azokhoz, amik már csillió éve itt vannak. A git jött és néhány év alatt ledarált mindent.

--
trey @ gépház

Pontosan. SZVSZ a git a legfontosabb szoftver amit valaha írtak.

     .--------.
    / .------. \
   / /        \ \
   | |        | |
  _| |________| |_
.' |_|        |_| '.
'._____ ____ _____.'
|     .'____'.     |
'.__.'.'    '.'.__.'
'.__  | LOCK |  __.'
|   '.'.____.'.'   |
'.____'.____.'____.'
'.________________.'

őrizzük meg eme bölcsességet az utókor számára

:) Na jó, a web browser valszeg előrébb van a rangsorban.....

A firefox meg a web browsernel.

Hogy valami hasznos is legyen, itt egy egész jó lista. http://www.dwheeler.com/innovation/innovation.html

OMG LOL.

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™

"A világ meg átállt gitalapra."
Azért akadnak kivételek. pl.: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
--
♙♘♗♖♕♔

Az összes cuccuk egy repóban van, hát mit mondjak, gratulálok. Mindenesetre ez nem éppen tipikus használata egy verziókezelőnek sem.

Mas nagy cegek is hasznaljak igy a verziokovetot, peldaul a Google is egy nagy repo-t hasznal.

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™

Mindig, mindenre vannak kivételek. Az ég kék, a víz nedves, a nők titkolóznak...

--
trey @ gépház

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

Mintha ő lenne a CVS-ek linuxa...

Bazaar lemaradt, elment mellette a világ.

Egy ideig használtam, aztán átálltam Git-re. Nem elég, ha egy szoftver elég jó, fejleszteni is kell.

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

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.

Melyik git klienst használjátok?

Mit értesz "git kliens" alatt?

GUI, plugin, stb
Gondolom nem mindenki terminálban nyomja...

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

parancssor, ha szükséges, akkor tig. Még ritkábban git gui.

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

smartgit+git parancssor
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

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