HOVD 2016 - Kedvenc verziókezelő rendszer

 ( trey | 2017. január 2., hétfő - 14:57 )
bazaar
1% (6 szavazat)
clearcase
1% (4 szavazat)
cvs
3% (19 szavazat)
git
77% (581 szavazat)
gnu arch
1% (11 szavazat)
mercurial
2% (17 szavazat)
perforce
0% (2 szavazat)
rcs
0% (2 szavazat)
subversion
13% (95 szavazat)
team foundation server
2% (15 szavazat)
Összes szavazat: 752

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

:(( Hogy lehet a bazaar csak 2 (már amikor ezt írom) ? hg is siralmas... mindenki ebbe a gitbe van belezúgva...

Lehetne egyenletesebb, ennyire nem király a git azért szerintem. Bár a github nem rossz, de a launchpad sem.

Azt gondolom, az emberek nagy része keveset ismer.

Ha a bazaar a kedvenced, akkor esetleg írd le ide, hogy miért, hátha mások is kedvet kapnak hozzá, hogy kipróbálják!

Idézet:
Azt gondolom, az emberek nagy része keveset ismer.

Ez rám biztos igaz. Régebben használtam a CVS-t, a saját (one-man) projekteimre a git-et. Miért? Mert mindent tud, ami nekem kell (bár valójában mindegyik tudja), meg kb. ez van mindenhol. Mivel mást igazán nem ismerek, így a git a kedvenc.

+1

sot, mostanra a git sajnos annyira egyeduralkodo lett, hogy mast nagyon sokan egyaltalan nem ismernek
multkor pl. kollegam megkerdezte hogy 'az svn-ben lehet branchet csinalni'? ... :-(

Ha már kibeszélő show-t tartunk azt is emesélhetni valaki hogy mi a baj a git-el :)

Úgyértem: használtam már sok mindent (svn, clearcase, bazaar, hg, tfs) de valahogy mind közül a git messze a leg kényelmesebb. Nem véletlen ennyire népszerű. Nem értem ez miért baj?

Nem tudom például megérteni azt a három kollégát, aki a clearcase-re adta le a voksát :) Igen, napi szinten szívok vele, tudom miről beszélek. ;) Még ha a hg-r mondja valaki akkor az rendben van.

Bazaar.. Szegénynek a lassúsága lett a veszte, pedíg ő volt az első dvcs amit használtam. De aztán miután sok órát néztem üveges szemekkel a mozdulatlan terminált, agyvérzés helyett git-re váltottam (ahol tehetm) és azóta szebb a világ :)

nekem a legnagyobb problemam a gittel az, hogy nem ad biztonsagot
alig par hete hasznaltuk a repot, mikor feltunt hogy az egyik commitom eltunt, hiaba kerestem
aztan a ticketing system linkjen keresztul meglett, de a branchen nem latszott
jol le lettem ott is hulyezve hogy marpedig ilyen nincs
aztan fel oraval kesobb kozolte az engem lehulyezo kollega hogy "jaaaa, pushminuszeffeltem, bocs"

szoval innentol en semmit nem mernek a gitre bizni amit kesobb meg latni akarok...
persze nyilvan le lehet tiltani (masteren nalunk most mar hal' istennek le van), de azzal meg gyakorlatilag a git osszes tenyleg jo feature-et kinyirod (pl. fixupok, rebase, stb)

A közösen használt repo-t annak megfelelően kellett volna létrehozni...

"persze nyilvan le lehet tiltani (masteren nalunk most mar hal' istennek le van), de azzal meg gyakorlatilag a git osszes tenyleg jo feature-et kinyirod (pl. fixupok, rebase, stb)"

Nem nyírod ki, a saját lokális repódban továbbra is azt csinálsz, amit akarsz, és vígan átírhatod a nem publikált history-t.

es a lokalis repobol mikor kuldom fel a "fo" repoba? miutan vegeztem a sajat gepemen a fejlesztessel, amihez senki mas nem nyul hozza?
ez egy emberes projectnel biztos tok jol mukodik, de nalunk egy-egy branchen tobben is dolgoznak egyszerre

raadasul ha csak lokalis repoba dolgozol, az megint csak lof@sz, veletlen letorolsz egy konyvtarat vagy megdoglik a vinyo, es megy a levesbe a komplett munkad?

Szerintem az egy jó ökölszabály, hogy nem szabad force pushol egy olyan ágba, ahova más is szokott pusholni (tehát nem csak olvassa). Teljesen jogos a kifogásod a fenti eset miatt, volt egy rossz tapasztalatod, amitől nem védett meg a git. Sajnos ez van, a kollégád hibázott, nem te, de ettől még a force push, ill. a rebase (és társai) remek dolog szerintem és meg kéne szüntetni az alaptalan félelmeket irányukban és inkább megtanítani a fejlesztőket a használatukra.

Tehát pl. van a feature-A ág, amin többen dolgoznak. Szeretnék valamit implementálni. Ekkor ahelyett, hogy közvetlen a feature-A ágba pakolnám a kommitjaimat lérehozom a feature-A-az-en-cuccaim-ne-pusholj-ide-legyszi-semmit-mert-rebase-zel-fogom-majd-par-szep-kommitba-osszerakni-a-sok-kis-kommitot-es-force-pusholom branchet. A kollégákkal megbeszéljük előre, hogy aki az -en-cuccaim-ne-pusholj-ide-legyszi-semmit-mert-rebase-zel-fogom-majd-par-szep-kommitba-osszerakni-a-sok-kis-kommitot-es-force-pusholom suffix-szal hoz létre egy ágat, azt nyugodtan force pusholhatja a tulaja, mások érthető okokból nem fognak pusholni oda semmit. Miután végeztem az implementációval, rebase-zel kiszépítem a múltat, majd pusholok a feature-A ágba.

Közben teljesen nyugodtan lehet force pusholni a közös repóba, csak az a lényeg, hogy a megfelelő ágat használja az ember. Pár alapvető szabály betartásával könnyedén elkerülhetőek lennének a fenti esetek, és közben lehet használni a git legjobb képességeit is.

Alapvetően tévesnek tartom azt a szemlélet, hogy a git history márpedig szépen kell kinézzen. Nyilván jobb, ha szép, de elsősorban inkább igaz legyen. Ha nem sikerül csalás (értsd: history utólagos manipulációja) nélkül szépre csinálni, akkor inkább maradjon kicsit csúnya, de 100%-ban visszakövethető. Mert mindenekelőtt ezért tartjuk...
Thou shalt not lie

_______Peter
I am a stone. I do not move.

+1

Én ezzel messzemenően nem értek egyet.

szerk.: a linkelt cikk meg tele van tévedésekkel.

A history-t nem a publikált, éles brancheken írja újra az ember, hanem a feature-brancheken.

Ha elkezdesz implementálni egy feature-t egy új branchben, és tízszer kell átírnod az egészet, mert ahogy egysze többet tudsz a problémáról, egyre jobb megoldásokat adsz rá, akkor ennek az egész folyamatnak nem feltétlenül van helye a main historyban.

Pl. ha beolvasztás előtti code review-ra ki tudod tisztítani a history-t, azzal a reviewer dolgát nagyon-nagyon meg tudod könnyíteni.

Ha már egyszer a kód a mainline-ban van, akkor valóban nem írjuk át a history-t, és kész.

+1

A nyilvános repó-ra nagyjából igazak a fenti cikk ajánlásai, tehát ott ne írjuk át a history-t (ne "hazudjunk"), a sajátot pedig bizonyos esetekben átírhatjuk, mert nem "hazudunk" vele senkinek. Aztán a tisztítottat szépen felrakhatjuk.

Nagyon szépen le van írva ez az általam már korábban is megosztott "Getting solid at Git rebase vs. merge" cikkben.

Szerk.:
Nyilvános (feature) branch-ben is szükséges lehet a "hazudásra", de ott nagyon körültekintően kell eljárni, mert nagyon könnyen tönkretehetjük más munkáját. Kb. innen is indult az egész, hogy "push -f" -et nem körültekintően használták (hazudtak) és emiatt ment a levesbe bizonyos commit.
Tehát nyilvános repo-ba ne "hazudjunk" vagy nagyon körültekintően, minden érintett figyelmeztetésével!

Ha tízszer át kell írni, akkor tízszer át kell írni. De lehet, hogy lesz tizenegyedik, tizenkettedik és tizenharmadik átírás is két hónap múlva, még több tudással, amiket úgysem lehet utólag hozzászépíteni. Mi értelme letagadni a tökéletlen megoldásokat olyan állapotok "behazudásával", amik a valóságban soha nem léteztek? Ha tíz átírásban annyi szégyellnivaló belekerült, akkor lehet, hogy érdemesebb egy új branch-en újra implementálni az egész addigit a friss tudással, úgy talán a a kódban sem marad annyi szemét, nem csak a history-ban.

A reviewer pedig nyugodtan szenvedjen meg ugyanúgy az átírásokkal, hogy értse, hogy miért is az lett a végleges, ami. Vagy ha csak a végeredmény érdekli, akkor nézze csak a kezdő- és végállapot közötti diffet.

Részemről a history átírását csak lokálisan tartom elfogadhatónak. Pusholni már csak olyant tartok illendőnek, ami merge-ölhető a main history-ba. És nincs "ja bocs, azt hittem", meg "bocsi, rossz branch-en voltam", stb.

Végeredményben persze mindig a csapat fog dönteni a munkamenetről, ahhoz nyilván alkalmazkodom, de azért örülnék neki, ha minél kevesebb olyan fejlesztővel sodorna össze az élet, akik túlértékelik a history esztétikáját.

_______Peter
I am a stone. I do not move.

> A reviewer pedig nyugodtan szenvedjen meg ugyanúgy az átírásokkal, hogy értse, hogy miért is az lett a végleges, ami.

Ennek van amikor van értelme, van amikor nincs. Sokszor röviden le lehet írni, hogy miért a tizedik megoldás a jobb és miért nem az előző kilenc, sokkal rövidebben (időben is), mint végignézni és megérteni rengeteg kódot ami végül benne sem lesz a termékben.

> Vagy ha csak a végeredmény érdekli, akkor nézze csak a kezdő- és végállapot közötti diffet.

Egy nagyobb featuret kényelmesebb több commit-ban implementálni. A kezdő és végállapot közti diff sokszor sokkal nehezebben követhető, mint ugyanazok a változtatások 5-10-100 commitban.

> Részemről a history átírását csak lokálisan tartom elfogadhatónak. Pusholni már csak olyant tartok illendőnek, ami merge-ölhető a main history-ba. És nincs "ja bocs, azt hittem", meg "bocsi, rossz branch-en voltam", stb.

Igen, így értettem én is.

A "push -f"-et lehet és érdemes is tiltani.

Fuszenecker Róbert

ld. fent: ezzel pont a git ertelmes featurei vesznek el

A „push -f” tiltásával? Mikre gondolsz?

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

Minden eszközt lehet rosszul használni, ez nem az eszköz hibája.
A késsel is könnyedén megvághatod magad, ha nem tudod jól használni. A kanál sokkal biztonságosabb, de körülményesebb vele kenyeret vágni.
Minden verziókezelőnek vannak olyan funkciói, amivel törölheted a feltett anyagaidat.
A Git-et részletesen beállíthatod, hogy kinek mihez legyen joga. Ezt akár repository-nként is állíthatod, így lehet olyan repository, ahova csak megfelelő jogosultságú és tudású ember tehet fel, a fejlesztők nem is tesznek fel semmit, csak pull request-tel értesítik a megfelelő személyt, hogy tőlük le lehet kérni a módosítást, pl.: lásd itt.

>A késsel is könnyedén megvághatod magad

hupu körökben elterjedt magatartás a barom analógiák használata, amikor valami megmagyarázhatatlant akarnak megetetni a jobb sorsra érdemes vitapartnereikkel, lásd autós, ajtós-záras hasonlatok

>Minden verziókezelőnek vannak olyan funkciói, amivel törölheted a feltett anyagaidat.

Újabb bizonyíték arra, hogy a git homályban élő propagandistái nem ismerik a CVS-t (se)

Ismerjük a CVS-t, rémálmainkban sajnos még mindig gyakran kísért a file-onkénti history-jával és az atomic commit hiánya miatti inkonzisztens állapotokkal.

ITT: babby nem bír lépést tartani a pro ámítástechnikai igényekkel

"Minden verziókezelőnek vannak olyan funkciói, amivel törölheted a feltett anyagaidat."

mutasd mar meg nekem legyszives hogy SVN-ben hogyan tudsz a repobol torolni commitot ugy hogy az a historybol is teljesen eltunjon.

" ugy hogy az a historybol is teljesen eltunjon."

Nem írtam azt, hogy a history-ból is eltűnik. cvs remove, svn delete
Git esetén se tűnt el a history-ból, pláne nem minden history-ból. Ezért is tudták visszaállítani.
Itt most két dolog keveredik:
1. A feltett módosításod felülírják. Ezt lehet sokféleképpen, akár egy sima commit-tal is, rossz merge-dzsel, ...
Én jól csináltam mindent, de valaki más belebarmolt. History(k) lapján (ha észrevesszük) visszaállítható a dolog.
2. History megváltoztatása. Erre valóban nem nyújt támogatást az SVN és CVS, de Git esetén sem az összes history változik. "A" felhasználó felrakja az Fe85... commitot, "B" felhasználó meg átírja D76f... commit-ra. "A" felhasználó history-jában ott van az általa felrakott commit, ami nem ugyanaz, mint amivel felülírta "B" felhasználó. Ha "A" felhasználó rakott fel hibásan valamit, akkor ez egy jó dolog, hogy "B" ki tudta javítani jóra. Ha "B" tudatlanságból használt egy olyan funkciót, amit nem tud, hogyan működik, akkor ez rossz eredményt ad.

A késes példa (példa az eszköz rossz használatára) nem tetszett mindenkinek, ezért álljon itt a shell rm parancsa. Eleve az rm (kés) nem biztonságos, mert törölni tud egy nem hozzáértő egy fájlt, amit a legtöbb fájlrendszernél nem is tud visszaállítani, sokkal biztonságosabb az ls parancs (kanál). Ráadásul az rm nem is hajlandó védett állományt törölni (hasonlóan, mint a push a Git-nél), de ráerőszakolhatjuk a -f flag-gel (hasonlóan, mint a Git-nél). Van aki szerint ez rossz, sokkal jobb, ha nem is lenne rm parancs, de ha van, akkor se legyen -f flag-je. Ezzel viszont azt a képességet vesztjük el, hogy rengeteg nekünk nem kellő védett fájlt nem tudunk hatékonyan törölni.
Mindenki eldönti mit tart biztonságosnak, hatékonynak és aszerint választ eszközt magának.

>cvs/svn remove ~= git push eff

Kitalálom: bölcsész

Sokan azt gondolják, hogy a git history átírása egyben azt is jelenti, hogy töröljük a régi history-t és felülírjuk az újjal és elvesznek dolgok. Azonban ez nem így van! A git megőriz minden információt és szükség esetén visszaállíthatók belőle a régi commit-ok.
Tehát a fenti példám az rm -f vs git push -f annyiban elvérzik, hogy míg az előbbi esetben (fájl rendszertől függően) tényleg elvesznek dolgok és nem állíthatók vissza, addig a git esetében megmaradnak a törölt elemek is, csak nem látszanak, és később visszaállíthatók.
Ha ilyen esettel szembesülünk, akkor használjuk a git reflog utasítást, amivel láthatóvá válnak a szükséges információk.
Egy-két példa a használatára.

Két gond lehet ezzel:
- A reflog opcionális, konfigban ki-be kapcsolható. "Normál" repókban alapértelmezetten be van kapcsolva, de bare repókban alapértelmezetten nincs. A userek pedig többnyire bare repókba pusholnak... szóval csak akkor lesz ott reflog, ha az admin körültekintő volt. Az itt olvasottak alapján én arra tippelnék, hogy a fenti konkrét esetben nem volt az :) Mindenesetre egy ideig még reflog nélkül, git fsck-val is előhalászhatók a "törölt" dolgok, de az nehézkes.
- A userek többnyire szerveren lévő repókba pusholnak, ahova nem biztos, hogy van shell hozzáférésük, vagyis nem tudnak git reflog-ot futtatni.

Ezek igazak, de a reflog a kliensek gépein alapértelmezetten be van kapcsolva és így a legtöbb kliensről visszaállíthatóak a régebbi commitok is. Egy kliensről biztosan, aki felrakta az eredeti commitot. A többi kliensről meg csak akkor, ha lekérték az eredeti commit felrakása utáni állapotot, de még az elrontás előttit.
Ez az egyik nagy jósága a gitnek, hogy nem csak egy helyen van meg a history, hanem rengeteg helyen.

>messze a leg kényelmesebb. Nem véletlen ennyire népszerű.

mások a windowsal vannak így, érthetetlen!

"Hogy lehet a bazaar csak 2 (már amikor ezt írom) ?"

A bazaar fejlesztése néhány éve stagnál, gyakorlatilag halott.

Főleg, hogy már van lehetőség gitet használni a Launchpad-on is, szóval szerintem még kevesebben fogják a jövőben használni.

ha körülöttem gitet használnak, akkor a saját dolgaimba egyszerűbb gittel integrálni a dolgaikat. gondolom. másik kettőt próbáltam évekkel ezelőtt, semmi olyan nem találtam ami nekem hiányzik a gitből, így nem használom őket, csak git. ha meg már van git, ráadásul megfelel, akkor minek váltsak?


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Szerintem pedig a git megerdemli a poziciojat. Azok kozul amiket eddig hasznaltam (CVS, SVN, ClearCase) messze a git a legjobb.
--
:wq

A gitre szavaztam. Nem szeretem, de ez lett a standard.

De akkor miért szavaztál rá? A kedvenced nincs a felsoroltak között?

A többit nem ismerem, a csapat kizárólagosan git-ben gondolkodik.

Nem értem a mercurial miért ennyire nem népszerű. Gyakorlatilag ekvivalens a git-el. Szerintem az emberek főként csak a gitről hallanak, ezért szavaznak rá.

A git nagyon elterjedt, és mivel annyira univerzális hogy gyakorlatilag mindenhová megfelel, ezért nem is éri meg különcködni és mást használni.

elterjedt, igen. De kb olyan mint a facebook: nem a legjobb, de ez van... Kaotikus, inkonzisztens paraméterek, paraméter nevek. Én is azt használom, de nagyon nem szeretem (bár a perforce pl rosszabb). Az svn volt az utolsó ami kézreállt.

Ez ízlés kérdése, nekem pl. kifejezetten kényelmes a git.

A konzervatívok mindig nyafogni fognak a régi dolgok után :-)

En sokaig hasznaltam mercurialt. Azt pl nem szerettem benne, hogy uj tag = uj commit, de meg lehetett szokni. A gitnel csak a submodule hell, amit kerulok, ha csak tehetem, de alapvetoen ez a standard, es kis projekteknel gyors es konnyen hasznalhato, foleg a staging area hasznos nekem.

A hg kimondottan klassz (nekem csak egy hajszállal ugyan, de szimpatikusabb a gitnél). dolgoztam olyan helyen, ahol az volt a rendszerben, de, ahogy mások is írták, a kedvenc problémásabban definiálható, most gites környezetben dolgozok, tehát ha pár éve szavazok, akkor hg, most éppen git (lévén utóbbit használom állandó jelleggel éppen).

bitkeeper

kimaradsz-lemaradsz, mertmindenkiezthasználja

Akkor most egy ellenvélemény következik:

/me egy elégedett svn user.

Hülye kérdéseket megelőzve:
- Igen, használok gitet is.
- Igen, tudom, hogy mennyivel faszább a git, mert a Linux is ebben van.
- Igen, tudom, hogy dvcs fapfapfap van.
- Igen, tudom, hogy a hg is létezik.
- Igen, tudom, hogy a fél világ gitet használ.

Miért használok még mindig svn-t (is)? Mert kicsi, egyszerű, teszi a dolgát és van, ahova bőségesen elég.

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

> Miért használok még mindig svn-t (is)? Mert kicsi, egyszerű, teszi a dolgát és van, ahova bőségesen elég.

+1

+1

------------------------
Jézus reset téged

+1

10 évig voltam boldog SVN felhasználó. A tudatlanok könnyed boldogságában éltem és Total Commanderrel mergeltem a Subversion branch-ek között...
Imádkoztam update előtt, és mindig vigyáztam, nehogy butaságot commit-oljak.

Aztán elolvastam Joel Spolsky cikkét: Subversion-reeducation: http://hginit.com/00.html

Joel kurva jó író. Általában nagyra becsültem a cikkeit és megfogadtam a tanácsait.

Ezért esett rosszul, amit írt:

It turns out that if you’ve been using Subversion, your brain is a little bit, um, how can I say this politely? You’re brain damaged. No, that’s not polite. You need a little re-education. I walked around brain damaged for six months thinking that Mercurial was more complicated than Subversion, but that was only because I didn’t understand how it really worked, and once I did, it turns out—hey presto!—it’s really kind of simple.

Azt gondoltam, hogy Linus Torvalds egy arrogáns f@, amikor azt írja, hogy a subversion a legrosszabbul tervezett szoftver, amit ismer.
Pedig teljesen igaza van :-)

Toljátok végig Joel tutoriálját. Rengeteg kollegát láttam SVN-ről hg-re migrálni... Senki se nézett vissza.
Az Hg egyszerűbb, mint a rém komplikált SVN...
Én annyira radikális lettem, hogy nem szívesen dolgoznék olyannal együtt, aki még mindig svn-t használ. Olyan, mint a kétütemű motor. Fűnyíróba még jó.

Tehát akkor még egyszer:

"és van, ahova bőségesen elég." Pl. ahol biztosan nem lesz merge már csak azért sem, mert nincs mit.

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

Szerintem ebben is jobb a hg vagy git.

Egy dologban van talán az SVN-nek létjogosultsága, szvsz, ha bináris file-okat is kell tárolni.

"Egy dologban van talán az SVN-nek létjogosultsága, szvsz, ha bináris file-okat is kell tárolni."

TADA.WAV

Illetve hozhatnám még példának azt is, hogy és egy user van össz-vissz és soha nem is lesz több. Vagy amikor az egész dvcs jellege igazából csak plusz nyűg és lépés.

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

> Vagy amikor az egész dvcs jellege igazából csak plusz nyűg és lépés.

Nem kötelező használni a dvcs jellegét, használhatod lokálisan, úgy, hogy nem publikálod sehová.

Egy felhasználó esetén is vannak előnyei. Csak egy pár:
- Kicsi, gyors.
- Könnyen kezelhetsz több különböző fejlesztési állapotot (Prod 1.0, RC 1.0, Dev 1.0, RC 2.0, ...)
- Könnyen kipróbálhatsz ötleteket, új branch, kipróbálod, ha jó felrakod valahová, akár csak egy részét, ha nem jó, akkor törlöd, mintha nem is lett volna.
- Egy-egy feature-t külön branch-ben fejleszthetsz, akár párhuzamosan is. Ha kész, akkor több verzióba is bepakolhatod.
- Egy-egy hibajavítást könnyű átrakni más verziókba is.
- Ha az egyszemélyes projekt több személyessé válik, akkor könnyű az átállás.
- Több egyszemélyes projekt könnyen együttműködhet.

Ez sövönö esetén is mind igaz... már rég nem az 1.3 a legfrissebb... :)

Remek, de a legutolsó SVN repo még mindig az LDD fájljaim számára lett létrehozva, ott is leginkább azért, hogy ne 1drv-n kelljen oda-vissza másolgatni 3 gép között + legyen már róluk egy távoli backup.

Azok meg lényegében zipelt XML fájlok meg egy screenshot. Gyakorlatilag sima backupra használom és mind a feladat, mind fájlok jellegéből adódóan ezen soha senki nem fog egyszerre ketten dolgozni.

Másrészt munkahelyen is kb. 3-4 éve beszéljük, hogy át kellene rakni a meglévő projekteket gitre. Eddig mindig elhalt valahol az egész, egyszerűen azért, mert *minden* valós igényt lefedi jelenleg az svn és az egész migráció és az új workflow kialakítása csak egy plusz nyűg lenne.

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

> Egy dologban van talán az SVN-nek létjogosultsága, szvsz, ha bináris file-okat is kell tárolni.

Arra a ClearCase is jó ;-)

rem komplikalt svn?
amikor egy svn parancsnak 4-5 tagbol allo git parancs-lanc felel meg?
kosz nem :D

Nem git, hanem az hg mellett irtam. De hasznaljatok csak nyugodtan subversiont.

"amikor egy svn parancsnak 4-5 tagbol allo git parancs-lanc felel meg?"

Hm, tudnál erre példát mondani, vagy csak költőien túlzol?

persze

pl. modositas felkuldese repoba
svn ci -m "comment"
git add && git commit -m "comment" && git push (na jo ez nem 4-5 parancs hanem "csak" 3 :D)

van meg jopar ilyen, hasznalat kozben szokott folyamatosan eszembe jutni hogy "mennyire egyszeru lenne ez svn-ben"

a legdurvabb a merge-hell, amikor van valahol a patch-lista aljan egy conflict, es UGYANAZT a nyomorult file-t millioszor kell szerkeszteni mert az osszes felette levo patchet elQrja. mocskos idegesito amikor ugyanazt a file-.t szerkesztgeted, addolod, rebase --continue-zol fel oran keresztul. SVN-ben egy file egyszer conflictol, azt feloldod par masodperc alatt es kesz

Csak 2, a git add és a git commit összevonható: git commit -am "comment". Egyébként workflow függő, adott esetben előnyös, hogy a commit nem kerül azonnal fel az upstream repóba. Pl. én elgépelted a commit message-t, kihagytál egy fájlt a commitból, bennhagytál egy commentet a kódban, ilyesmit még lehet javítani.

Az utolsó bekezdésre: aki rebase-el az meg is érdemli. :)

"na jo ez nem 4-5 parancs hanem "csak" 3"

Sejtettem, hogy nem fog menni...
Egyébként ez is csak kettő lenne, git -am "comment", vagy ha sűrűn akarsz minden egyes commitot azonnal pusholni is, akkor beállíthatsz egy git vagy shell aliast, és már csak egy :)

"a legdurvabb a merge-hell, amikor van valahol a patch-lista aljan egy conflict, es UGYANAZT a nyomorult file-t millioszor kell szerkeszteni mert az osszes felette levo patchet elQrja. mocskos idegesito amikor ugyanazt a file-.t szerkesztgeted, addolod, rebase --continue-zol fel oran keresztul. SVN-ben egy file egyszer conflictol, azt feloldod par masodperc alatt es kesz"

svn-ben van már rebase? Vagy már megint svn-beli merge-elést akarod git rebase-hez hasonlítani, almát körtével? A git merge ugyanúgy csak egyszer fog conflictot jelezni.

Az továbbra sem a tool hibája, hogy rossz workflow-t alakítottatok ki magatoknak, és az se, hogy bár már rég felismertétek, még mindig nem változtattok rajta.

az -am-et nem ismertem, koszi a tippet
valami linket tudsz adni ra, hogy hogyan is mukodik/hasznalando? a git helpje gyakorlatilag maga a tomeny borzalom :-/

a rebase nem az en dontesem volt, egyebkent tokeletesen jellemzi a gitet hogy a felhasznaloi meg abban sem tudnak megegyezni hogy hogyan is kellene hasznalni
anno a profi 'gitmagusok' megbeszeltek hogy a rebase kevesbe szar mint a merge, ugyhogy ez lett...

a shell alias meg... basszus, ha sajat magamnak kell millio workaroundot csinalni egy toolhoz, az mar regen rossz (igen, egyebkent nalunk kb. mindenki egy elore osszerakott alias-csomagot hasznal, hogy ne kelljen kilometeres parancsokat gepelgetni egymas utan sorba, de ettol nem lesz jobb a tool)

Teljesen más filozófiával működik a két eszköz, sarkítva az svn és a git olyan, mint az SQL és a NoSQL... akkor van baj, ha valaki mindenáron az SQL-t vagy a NoSQL-t erőlteti, függetlenül attól, hogy mi a feladat. Ezt súlyosbítja, ha a git-et használja svn filozófiával vagy az svn-t git filozófiával.

+1

"valami linket tudsz adni ra, hogy hogyan is mukodik/hasznalando?"

git commit -h azt írja, hogy:
-a, --all commit all changed files
És ebben minden benne van arról, hogy hogyan működik. A man page részletesebben (szájbarágósabban) mondja ugyanezt.

"egyebkent tokeletesen jellemzi a gitet hogy a felhasznaloi meg abban sem tudnak megegyezni hogy hogyan is kellene hasznalni"

Ezt már az előző HOVD szavazáson is elsütötted, és már akkor se volt semmi értelme.
A válasz ugyanaz, mint tavaly volt: Különböző csapatoknak és projekteknek különböző igényeik vannak, ezért különböző workflow-kat használnak. Nincs egy egyetemes workflow, ami mindenki igényeinek tökéletesen megfelel. Kifejezetten örvendetes, hogy végre van egy tool, ami többféle workflow kialakítását is lehetővé teszi, ahelyett, hogy az általa támogatott egyetlen workflow-t kényszerítene mindenkire, "eszi, nem eszi, nem kap mást" alapon.

"a shell alias meg... basszus, ha sajat magamnak kell millio workaroundot csinalni egy toolhoz, az mar regen rossz"

A fentebbi tapasztalatok alapján ezt a "millió"-t én "egy-kettő"-nek értelmezem ;), az meg bőven a tűréshatár alatt van.
Másrészt felmerül a gyanú, hogy nektek elsősorban a rossz workflow miatt kellenek a workaroundok.

az elobb meg arrol volt szo hogy hulyek vagyunk mert ROSSZUL valasztottunk a rebase-es megoldassal
most meg arrol hogy milyen jo hogy az is van :D

egyebkent ahogy mar emlitettem, a rebase-es megoldast mellett azok dontottek, akik regota hasznaltak es fanatikus modon imadjak a gitet ;)

A rebase jó, az egyik legfontosabb olyan feature, ami lehetővé teszi, hogy tényleg mi kezeljük a verziókat, ne csak belelapátoljuk a kódot egy központi megosztott backupba.
De a rebase-t lehet rosszul és rosszra használni.

Pusztán az itteni panaszaid alapján gyanús, hogy rosszul döntöttek.

"a shell alias meg... basszus"

Azert ez eleg kenyelmesen megoldhato.

"a legdurvabb a merge-hell" / "profi 'gitmagusok' megbeszeltek hogy a rebase kevesbe szar"

A rebase sokszor (legtobbszor?) jobb megoldas, mint a merge, bar annak is megvan boven a letjogosultsaga. Pl. git pull minek tolja tele a commit historyt merge commitokkal --rebase (vagy meg inkabb --rebase=preserve*) nelkul?

Van megoldas arra is, hogy ugyanazt a conflict-ot ne kelljen n-szer megoldani, azt meg aztan tenyleg egyszer kell csak beallitani es ugy hagyni.

*oke, a preserve debian jessie-n ugy tunik nem akarja valamiert az igazsagot nalam, a munkahelyemen viszont csak igy hasznalom. Igaz igy hosszu, arra viszont ott vannak a fent emlitett git alias-ok.

> Igaz igy hosszu, arra viszont ott vannak a fent emlitett git alias-ok.

Vagy (még inkább) be lehet állítani globális konfigban.

Mire gondolsz? Nem ugyanarra amit en is emlitek a parentben? Az is ott kot ki.

Arra gondoltam, hogy nem aliasként állítod be, hanem a pull defaultjának.

git config --global pull.rebase reserved 

> valami linket tudsz adni ra, hogy hogyan is mukodik/hasznalando?

Getting solid at Git rebase vs. merge

Nehéz a merge néha svn esetén, de amúgy istenigazán jól elbaszni git esetén lehet. :)

:D :D de jót nevettem

Főleg ha nem értesz hozzá ...

--
http://pyftpadmin.earthquake.hu

Nekem az a tapasztalatom, hogy ha nem értesz hozzá, akkor elbaszod...

...ha meg értesz hozzá, akkor a többiek által elbaszott merge eredményét javítgatod...

...ezért aztán az első néhány elbaszás után a nagy többség úgy használja, mint egy svn-t, de közben persze nagy az arca, mert látszólag git-et használ...

...és mivel csak látszólag használ git-et, néha elbízza magát, és lásd első bekezdés.

:)

Ha ertesz hozza, rebase-elsz. ;^)

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

+1, teljesen meg vagyunk elégedve az SVN-nel. Egyszerű, átlátható workflow-t ad, teszi a dolgát.

Én is svn user vagyok, de most elgondolkodtam, hogy lehet ésszerűbb lenne git-et használni. Ha ennyivel többen használják, akkor annak sok pozitív hozadéka van/lesz.

Hát ártani biztos nem árt, ha legalább alapszinten mindkettőt ismeri az ember. :)

ProGit könyv már a barátom.

Ha ennyivel többen használják

Több milliárd légy eszik sz*rt, szóval mégsem lehet olyan rossz a kaka, ugye?

Bocs, ez mindenkinek szól, aki isteníti a git-et. Sokáig SVN-t használtam (néha még most is), és teljesen rendben van, ahová nem kell dvcs. A tool-jai fantasztikusak, merge-elni is rettenetesen egyszerű vele (Eclipse alatt a CollabNet merge client, illetve a TortoiseMerge nagyon jók), stabil.

A git-ről viszont az a véleményem, hogy ezt commandline-os júzerek találták ki és készítették, akik az rsync és a tar összes kapcsolóját is fejből tudják. Nekem sajnos grafikus tool kell, mert sokszor igenis gyorsabban lehet dolgozni velük, és nem kell memorizálni mindent. Na ebben fos a git, akárhány GUI-t próbáltam hozzá, mindnek más a terminológiája, az azonos műveleteket másképp kell végrehajtani velük, és nem találtam olyan tool-t, ami rendesen működik Win-en és Linux-on is.
Mercurial párti vagyok, kb mindent tud, amit a git, csak sokkal egyszerűbben lehet megcsinálni benne, és a GUI-ja is nagyon kényelmes és jó. A learning curve-je is sokkal barátságosabb emiatt.

GitKrakent próbáltad? Mi most azt használjuk és elégedettek vagyunk vele.

Legutóbb amikor néztem még igencsak új volt, azóta már használhatónak tűnik. Sajna fizetős, és még egy handycap: valamilyen okból zsigerből irtózom a javascript-ben írt alkalmazásoktól, főleg ha nodejs is érintett :)

Igen, „sajnos” üzleti célra fizetős, viszont nem olyan vészes az ára, 10 felhasználóra 300 dollár / év. Sajnos Linuxon nem állunk valami jól a GUI-s git kliensekkel, így ennyit nekünk megér. :)

"Több milliárd légy ..."

Ez a mondat csupán ott sántít, hogy nem legyek vagyunk. Szóval innentől nincs is igazán értelme :)

"Na ebben fos a git, akárhány GUI-t próbáltam hozzá, mindnek más a terminológiája, az azonos műveleteket másképp kell végrehajtani velük, és nem találtam olyan tool-t, ami rendesen működik Win-en és Linux-on is."

A beépítettet (git-gui) nem próbáltad? Az működik rendesen Linuxon és Windowson is, ugyanaz a terminológiája és ugyanúgy kell a műveleteket is végrehajtani.

Próbáltam, csak sajnos nem vagyok vele produktív, értsd: marhára kényelmetlen, olvashatatlan, összehányt az egész.

Egyszerűen a git a legjobb VCS. Nekem különösen az tetszik hogy milyen jól van tesztelve:

$ git clone http://github.com/Xastir/Xastir
Cloning into 'Xastir'...
$ ls -ld Xastir
ls: Xastir: No such file or directory

Nincs olvasási jogod a könyvtárra, ahová lekérted?

Ha nem adod meg a nevet (ls -l), akkor "Permission denied". Ha meg megadod (ls -ld Xastir), akkor rendesen látszik a Xastir könyvtár.

nem

Úgy értettem, hogy valószínűleg nem az lehet a gond, hogy nincs olvasási jog, hiszen ha minden rendben lezajlott, az olvasási jog hiánya esetén az ls -ld Xastir mutatja a kérdéses könyvtárat (legalábbis nálam egy-két próba alapján, FreeBSD, UFS).

Nem tudom, hogy hol lehet a kutya elásva, de bevallom, érdekel, mi (lehet) a hiba oka.

de

Gyanús nekem az az url; GitHub szerint a https://github.com/Xastir/Xastir.git vagy a git@github.com:Xastir/Xastir.git url-eket lehet a git clone-nak megadni. Gondolom a megadott címen nem talált git repót, ezért nem is klónozott le semmit. Viszont ezt közölnie kellene egy "fatal: repository 'http://github.com/Xastir/Xastir' not found" üzenettel.

nem

Puding próbája az evés. Nekem leszedte, legalábbis lett 33 megabájtnyi fájl a könyvtárban.

worksforme.


λ git clone http://github.com/Xastir/Xastir
...

C:\Users\atom
λ ls -ld Xastir
drwxr-xr-x 1 atom Administ 16384 Dec 21 19:49 Xastir

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

+1

Szerintem mindenkinek ez jön ki csak szegecsnek nem. Valami nagyon félre van állítva Nála.

Hogynepersze rögtön user error, aztán a Világ Legjobb Verziókezelőjének hol a hibaüzenete?

Tudsz rá jobb magyarázatot?

Tekintettel arra hogy pontosan tudom mik az ide vezető git bugok, igen

Nem lövöm le a poént, hadd dolgozzon a manyeyeballs, nekem mint CVS usernek amúgy is tökmindegy. SSL környékén érdemes keresgélni (micsoda meglepetés, ki gondolta volna, trusted, secure, stb...)

Továbbá a git developpereket (a közhiedelemmel ellentétben nem torvaldosz) megkérdezni hogy miért jó elobfuszkálni egy segfaultot.

El lehet gondolkozni a nagy advokáció közben azon is, hogyan lehet megírva eme csodás exe, amikor ilyen dolgok meg tudnak benne történni - és még mi lehet a háttérben.

Idézet:
SSL környékén érdemes keresgélni

Reméltem, valami "egyszerűbb". Ehhez a témához kb. egyáltalán nem értek :(

Szerintem ha küldesz egy bugreportot, akkor jobban fog működni a manyeyeballs, mintha itt a hupperekre vársz...

Felesleges, mert
1) ezzel a hozzáállással, ahogy itt is bemutatta a hibát és aztán ahogy kifejtette, senki sem fogja tudni, akarni kitalálni, hogy mi a gond.
2) a célja nem az, hogy kijavuljon a hiba, csak az, hogy lejárassa a Git-et.

>Felesleges

+1, de azért ne abból induljunk ki amit te művelnél egy bugreportban az angol tudásoddal

>lejárassa a Git-et

Ugyan, ehhez nem kell külön erőfeszítés, megteszi az önmagának is, lásd fent

> +1, de azért ne abból induljunk ki amit te művelnél egy bugreportban az angol tudásoddal

Akkor innentől jön a személyeskedés? Gratulálok!

1. Egyébként azt magyarul is éppen olyan jól félreértettem volna.
2. Valóban nincs nagy magasságokban az angol tudásom, de ilyet nem is állítottam soha.

> Ugyan, ehhez nem kell külön erőfeszítés, megteszi az önmagának is, lásd fent

Én még nem láttam ennek semmi jelét, a kijelentéseden kívül, de nem zárom ki, hogy bizonyos körülmények között tényleg hibás. Kevés szoftvert ismerek, amiben nincs bug, egész pontosan nullát.

Nem, hanem innen

- Szaragit
- Miért?
- Nem mondom meg!

A swapfile-nál is van egy hasonló szál.

Mit jelent a 'λ'? Haskell? Lisp? F#? :-)

Fuszenecker Róbert

gondolom ezt használja :)
http://cmder.net/

Egy 'git clone randomsztring -vvv'-t is idehányhatnál a többi sárdobálás közé, hátha érdemben is előrébb lépne ez a "vita".

$ /usr/local/git-*/bin/git clone randomsztring -vvv
fatal: repository 'randomsztring' does not exist
$

Jézusom..
Azt hittem, azért kiadja az eszed, hogy a randomsztring helyére behelyettesíted a repo nevét, amit le szeretnél húzni.

Lassan írom, hogy megértsd:

git clone http://github.com/Xastir/Xastir.git -vvv

1) ezzel a hozzáállással, ahogy itt is bemutatta a hibát és aztán ahogy kifejtette, senki sem fogja tudni, akarni kitalálni, hogy mi a gond.

Van giten kivul mashoz lolcommit(https://github.com/mroth/lolcommits)? Naugye :P

És ilyen remek aliasok? https://hup.hu/node/150098