HOVD 2015 - Kedvenc verziókezelő rendszer

 ( trey | 2016. január 13., szerda - 8:29 )
bazaar
0% (3 szavazat)
clearcase
1% (7 szavazat)
cvs
2% (14 szavazat)
git
75% (555 szavazat)
gnu arch
1% (5 szavazat)
mercurial
3% (25 szavazat)
perforce
1% (4 szavazat)
rcs
1% (4 szavazat)
subversion
15% (111 szavazat)
team foundation server
1% (10 szavazat)
Összes szavazat: 738

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

Az svn miért lehet kedvencebb mint a git?

--
arch,debian,openelec,android

Szerintem nem kedvencebb, negyedannyi szavazat jott ra eddig...

Szerintem a kérdező azt gondolta, hogy egy-egy személy hogyan szavazhat SVN-re, ha létezik a git.

Így van.

--
arch,debian,openelec,android

Megszokás, hagyomány, bőven elég, tudod, hogy van ez.

Lehetnek olyan csapatok, akiknek nem kell a git tízmillió feature-e, "csak" verziókezelni akarnak.
Vagy csak nem akarnak felülni a git hype vonatra (a Mercurial kb. 1 héttel korábban/később jött létre, mégis elég kevéssé népszerű, pedig technológiailag nem látok túl sok különbséget a githez képest).

Fuszenecker Róbert

Hogy egyik exkollegat idezzem: "hg-ul a szakma" :)
(egyebkent az SVN-t egyszerubb hasznalni, viszont bizonyos kodmeret utan hasznalhatatlanra lassul - vagy csak az IT nem ert hozza, nemtom, de tapasztaltam)

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Nekünk tobbszáz megás repositoryaink vannak, semmi lassulást nem tapasztaltunk.

1.6-volt rohadt lassú volt nekünk, mert abban még mappánként volt .svn mappa, és elég lassan szedte össze magát. Utána 1.7-tel nagyságrendekkel gyorsabb lett, nem volt érzékelhetően lassabb, mint a git (persze más kódbázis, de hasonló nagyságú projekt)

Nekem a mercurial is megfelel, csak azon csodálkozom hogy valakinek az svn a kedvence, amiben a branchek mappák, és az adott IDE-t ki lehet nyitni mindegyikre külön. Au.

--
arch,debian,openelec,android

vs. git, ahol kicheckout-olod a masik branchet, eclipse/intellij meg 10 percig daral, mire mindent ujraindexel. franko.

Neked darál 10 percet? Nekem gyorsan végez, pedig nincs is erős gépem. Ha pedig kevés az eltérés a két ág között, akkor végképp.

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

+SSD

---------------------------------------
Devmeme - fejlesztői pillanatok

"és az adott IDE-t ki lehet nyitni mindegyikre"

Hjabat kérem, az svn-t is lehet rosszul tartani. Minek checkoutolnek ki mindent? Es miert nem csak az adott branchet huznam be az IDE-be?

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

Max. nem használják, én itthon is gitet használok saját mindenféle bigyóra, kb. megy a home szerveren és kód backup célra, mondjuk bele szoktam irogatni mit csináltam, de nem látom, be, hogy miért lenne bonyolultabb gitet használni. Az android is git alapú azt meg sokat fejlesztek (romot is).

Gittel lehet imitálni a centralizált verziókövetést. Ebben az esetben tényleg nincs nagy különbség.
Ha viszont úgy használod, ahogy a Github-on meg van oldva (pull requesteket készítesz), már más lesz a workflowd, bonyolultabb, mint SVN esetén.

A git rebase vagy git pull --rebase időnként egészen elképesztő dolgokat tud művelni.

Fuszenecker Róbert

"A git rebase vagy git pull --rebase időnként egészen elképesztő dolgokat tud művelni."
még sosem képedtem el, mindig látszott pontosan a történés - de oszd meg, hátha :)

--
arch,debian,openelec,android

Akkor sajnos üzleti titkot sértenék. De amint otthon is előjön, ideírom.

Általában az alábbi esetben jön elő:

git checkout master -b mybranch
... csinálom a változtatásaimat ...
... más meg teszi be a dolgait masterre (a központi repóban) ...
git commit -am "..."
git checkout master
git pull
git checkout mybranch
git rebase master

Időnként előfordul, hogy a változtatásaim más változtatásaimmal ütköznek.
Git 1.8.x

Fuszenecker Róbert

"Időnként előfordul, hogy a változtatásaim más változtatásaimmal ütköznek."

Hogy mi ütközik mivel?

Ezen az oldalon van egy kis minta:

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

Rebase során a git újra elkezdni alkalmazni a változtatásaimat a branchen. Előfordult már, hogy az egyik változtatásom, amit "Applying"-olt a git ütközött egy előző (de a rebase során alkalmazott) változtatásommal.

Fuszenecker Róbert

Valószínűleg félreérted, és a kérdéses ütközés nem "egy előző (de a rebase során alkalmazott)" változtatás miatt van, hanem egy master-en történt változás miatt.

Nem, azt azért még látom, hogy mit módosítottam én és mi jött a másik branchből :-)

Fuszenecker Róbert

A felhozott példád alapján én úgy látom, hogy nem látod :)

Ebben eltér a véleményünk. De tegyük fel, valóban elrontottam valamit, végülis én is ember vagyok.
Ugyanez a jelenség előjött egy másik kollégámnál is. Ez egyébként téma volt, amikor a gitre való váltást értékeltük.

Fuszenecker Róbert

+1

A rebase-zel az a bajom, hogy hiába lesz egyszerűbb tőle a history, attól még a múlt meghamisítása. Főleg egy rendes CI mellett ez furcsán hat (mondjuk ott van push is). Mindenesetre én inkább pullolni szoktam a mastert, így a meglévő commitjaim megmaradnak olyannak, amilyenek. De gondolom, hogy ha a rebase valamiért félremegy, azért a reflogból előáshatóak a korábbi történések.

Kétféle iskola van, a merge-esek és a rebase-esek :-)
Mi rebase-esek vagyunk, mert meg van mondva.

Fuszenecker Róbert

mi merge-sek, de a gitlogban a rebase olyan tisztábbnak hat, legalábbis így ránézésre.
--
blogom

Azt leszámítva, hogy merge esetén pl. a gitk képes egy össze-vissza színű vasúti rendező pályaudvart odarajzolni bal oldalra, nem látom a különbséget a merge és a rebase logja között. Mindegyikben ott vannak a commitok.

Ha a mastert rendszeresen merge-eled a saját branchedbe, akkor ha jobban megnézed, láthatsz ott egy csomó felesleges és hátrányos merge commitot is, ami nem lenne ott, ha a saját branch-edet rendszeresen rebase-elnéd a master tetejére.

Nem feltétlen baj az a merge commit, van olyan workflow, ahol kifejezetten törekszünk rá. Amúgy szerintem a merge és a rebase nem zárja ki egymást, mi általában használjuk mindkettőt.

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

Ártanak az áttekinthetőségnek, nehezítik a release managementet, stb. Potenciális előny hirtelen nem jut eszembe egy se.

Van olyan, hogy a feature branch-eket csak merge committal fésüljük össze a másik ággal (még ha menne is a fast-forward), hogy később is azonosítható legyen a beolvasztás helye. Ott ilyen a workflow és szerintem nem is rossz.

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

+1
Igazából az a rebase-zel a bajom, hogy sokan dolgozunk a repóinkon és egy-egy feature branchen is. Így folyamatosan megy a push-pull, hogy összedolgozzunk, no meg a CI rendszer sem az én gépemen nézi, hogy változott-e valami. Ahhoz, hogy rebase-elni tudjunk egy pusholt cuccot, a szerveren is át kéne írni a history-t, ami nem mindig szerencsés, így nem is engedjük.

Ez rendben van, de fentebb azokról a merge commitokról volt szó, amik akkor keletkeznek, amikor a master branchet időről időre merge-eled a feature branchbe.

nalunk is latszik hogy mikor lett beolvasztva, es a history is "szep":

git rebase master
git checkout master
git merge --no-ff feature-branch

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szinte minden érv a rebase mellett szól. Azt pedig el kell engedni hogy "jaj frissült a master ezért a melóm pár committal feljebb kerül". Igen.

--
arch,debian,openelec,android

Szinte. Merge commitot egyszerűen lehet revertelni, rebase-nél viszont szopó van. Kivéve persze ha squash mergelsz, de az más tészta.

Maximum a helyi history lesz "meghamisítva", de ha egyszerre akarunk szép lineáris historyt rendezőpályaudvar nélkül és sok egyszerre dolgozó fejlesztőt akkor valamiről le kell mondani!
Az idézőjel direkt van, a gitben minden commit tökéletesen immutable, amikor azt hinnéd hogy manipuláció van, akkor az már másik sha id, és a reflogban örökre nyoma marad mindennek.

--
arch,debian,openelec,android

Khm, apróbetűs megjegyzés, mert ez így ebben a formában nem igaz:
- A reflog opcionális, normál repókban alapértelmezetten be van kapcsolva, de kikapcsolható, bare repókban alapértelmezetten nincs bekapcsolva, szóval nem biztos, hogy nyoma marad.
- A régi reflog bejegyzéseket a gc eltávolítja, szóval ha nyoma is marad, akkor is valószínűleg nem örökre.

Köszi a pontosítást!

--
arch,debian,openelec,android

Ott a hiba, hogy nem kell rebaselni és kész. :) (Na jó, ha egyszerre többen dolgozunk egy feature branchen (ami eleve nagyon ritka), akkor szoktam git pull --rebase-elni.)

Simán lehet, hogy ilyenkor conflictol, mert ahogy applikálja rá a branchre a commitokat, előfordulhatnak olyan állapotok, amik külön-külön egyik branchen sem fordultak elő. Például: http://pastebin.com/SxjYC33L

Ebből következik, hogy eljuthat olyan állapotba, amikor az egyik commitodat még valahogy rá tudta húzni a másik branchre, a következő már conflictol.

Azért is jó az ilyen, mert simán el tudom képzelni, hogy olyan köztes állapotba visz pl. egy forráskódot, ami teljesen invalid, sok szerencsét git bisecthez.

A "git pull" mar meger egy nyaklevest. :)

És mégis miért?

Fuszenecker Róbert

sokkal egyszerubb, kenyelmesebb hasznalni, nem kell hegeszteni, amit becommitolsz az ott lesz, stb

nem kell hegeszteni, amit becommitolsz az ott lesz
Várom a gites történetedet.

"sokkal egyszerubb, kenyelmesebb hasznalni"
az egyszerűbbet elhiszem

"nem kell hegeszteni"
nem szoktam hegeszteni

"amit becommitolsz az ott lesz"
a gitben is :)

--
arch,debian,openelec,android

"nem szoktam hegeszteni"
boldog ember... nalunk rengetegszer kell mert elbaszodik valami, megy a rebase, a patchek tologatasa, stb

""amit becommitolsz az ott lesz"
a gitben is :)"

hat perrrrrszeeee... megszamoljam neked hogy hanyszor volt olyan hogy:

- b+ en ezt mar megcsinaltam es beraktam!
- ja, en meg 'pushminuszeffeltem"

> - ja, en meg 'pushminuszeffeltem'

mondjuk normális helyen ezt nem engedi a központi repo, de legalább seggbe lesz rúgva, aki ilyet próbál.
--
blogom

rebase-hez muszaj a push -f
a masterre nalunk sem lehet push -f-elni (egy ideje, az elejen onnan is tuntek el commitok...)

buta vagyok, tudom, de...

a rebase-es móka nem úgy néz ki, hogy:
- originben van commit, és én is commitoltam a local branchemre
- origin fetch, de nem merge
- majd valami magic segítségével a saját repomat összehúzom az originnel, s a lokális commitokat az originen lévő "mögé" rebase-lem?

Valahogy így:
Kiindulás

 . origin/master - munkatárs commitja
 |
 |  . master     - én commitom
 | /
 |/
 '               - közös ős

Eredmény

 . - én commitom 
 |
 |
 . - munkatárs commitja
 |
 |
 ' - közös ős

--
blogom

de igen
majd a legutolso lepesed utan fel akarod rakni az originre a rebase-elt branchet -> jon a push -f

 . - én commitom 
 |
 |
-------------------------- idáig ugyanaz a lokális, mint az origin
 . - munkatárs commitja
 |
 |
 ' - közös ős

De a jelölt vonalig a nálam lévő lokális repo, meg az origin teljesen megegyezik, nem? Van egy új commit az egész legvégén. Ezt miért nem tudom -f nélkül feltolni?
--
blogom

Pusholt branchet nem rebase-elünk, ez alap kéne legyen. Asszem még a git manualban is külön felhívják rá a figyelmet.

mi az a 'pusholt branch'? :S

amugy a rebase-es megoldas dontes volt meg a legelejen (a git-magusok dontottek igy), raadasul eddig a legtobb ismerostol azt hallottam hogy ok is a rebase-elos megoldast szeretik

amugy ezen is szoktam rohogni, hogy a git userek meg abban sem tudnak megegyezni hogy hogyan is kene hasznalni ezt a toolt :)

Idézet:
„amugy ezen is szoktam rohogni, hogy a git userek meg abban sem tudnak megegyezni hogy hogyan is kene hasznalni ezt a toolt”

Ez már legyen a git userek hibája, de nem az eszközé. Főleg, ha nem alakítanak ki egységes, a céljaiknak megfelelő workflow-t és azt nem dokumentálják.

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

"amugy ezen is szoktam rohogni, hogy a git userek meg abban sem tudnak megegyezni hogy hogyan is kene hasznalni ezt a toolt :)"

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.

szerk.: az már nem a tool hibája, hogy rossz workflow-t alakítottatok ki magatoknak, és az se, hogy ennek felismerése után se változtattok rajta.

Igen, ez hatalmas +1! :)

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

Megosztott branch.

Kikerestem a vonatkozo figyelmezteteseket a manualbol:

"You should understand the implications of using git rebase on a repository that you share."

"Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history."

Nem ordogtol valo dolog, csak esszel kell hasznalni. Nalunk eddig egyszer vagy ketszer kellet force push-olni, akkor korbejartam a kollegakat, es mindenkivel egyeztettem, hogy ne legyen belole galiba. Rutinszeruen force pusholni megosztott repoba - mar elnezest, de - orultseg.

Amugy bitbucketen meg lehet tiltani a remote branch-ek rebase-eleset.

Nem olyan bonyi a git, csak ezt kell elolvasni parszor es megerteni: https://git-scm.com/book/en/v1/Git-Internals

Felmerül a kérdés, hogy miért is kell ismerni a git belső működését, hogy normálisan lehessen használni? Elvileg a git eszköznek pont az lenne a dolga, hogy elrejtse a felhasználó elől a működési részleteket és egy könnyen használható interfészt adjon.

Valójában nem kell ismerni, én sem ismerem pontosan, mégis vígan használom évek óta. Mások pedig még ennyire sem ismerik körülöttem.

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

Nem kell, csak ha érted, mi történik belül, akkor jobban megérted az egyes parancsokat, a hatásukat, és adott esetben könnyebben boldogulsz egy szembejövő problémával. Semmi ijesztő nincs benne, nagyjából a belső key-value store működését magyarázza el.

"akkor jobban megérted az egyes parancsokat"

Látod a problémát? :)

Nincs probléma, mert ha nem ismered a Git belső működését, akkor is megérted az egyes parancsokat. De ha ismered a belső működést, akkor tudod, hogy mi történik a háttérben. Ez kb. mindennel így van.

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

git reset
git reset HEAD^
git reset --hard

Le tudnád nekem írni legfeljebb 4 egyszerű mondatban, hogy a fenti 3 parancsban mi a közös és miben térnek el egymástól? :)

Le lehet írni, de nem fogom, mert az a négy mondat feltételez más, hasonlóan egyszerű mondatokkal átadott ismeretek meglétét. Azért sem igazán értelek, mert aki nem akar a fenti parancsokkal dolgozni, az használhat GUI-t vagy az általa preferált fejlesztőkörnyezet eszközeit.

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

Volt egy csapat, akivel egy darabig együtt dolgoztam. Használták is szépen a gitet, ahogy kell. Mígnem egy nap valahogy sikerült annyira összekutyulniuk mindent, hogy nem tudtak megbírkózni vele, és kétségbeesetten futottak segítségért. Pedig ha tisztában lettek volna a gittel kicsit mélyebben is, mint az add / commit / push, akkor fél perc alatt helyretették volna az egészet.

Nem kötelező érteni hozzá, el lehet boldogulni vele elég jól alapszinten is.

Egyáltalán nem szükséges a belső működés ismerete ahhoz, hogy "normálisan lehessen használni".

De ez az egész subthread abból ágazott ki, hogy odaát rendszeresen git push -f-t futtattak, ami a hagyományoknak megfelelően git-nek is azt jelenti, hogy --igen-tisztában-vagyok-vele-hogy-ezzel-potenciálisan-lábon-lőhetem-magam-de-pontosan-tudom-hogy-mit-csinálok. Ahhoz, hogy valaki ennek a következményeit fel tudja mérni, és tájékozott döntést hozhasson, már valamivel több kell, mint felszínes ismeretek. De ez már kívül esik a normális használaton.

Teljesen igaz. Én is magamtól használgattam, és idén kicsit belemélyedtem, elolvastam a könyvet. Nekem nagyon megérte, mert így sokkal jobban értem mi fog történni egy-egy parancsnál és bátrabban is használom az eszközt. Csak ajánlani tudom a könyvet!

Na ne már! Nehogy ezért a git legyen már felelős... Ennyi erővel a {{randomos}} is mekkora egy rakás ..., mert a múltkor letöltöttem egy Linux ISO-t torrentről, tesóm meg letörölte.

miert, ki a felelos? ha a tesod a verziokezelobe berakott ISOt letorli, akkor ott mar bajok vannak :)

az SVN siman nem engedi (pontosabban meg lehetoseget sem ad ra)
az en szememben a verziokezelovel szemben tamasztott egyik legalapvetobb feature hogy amit odarakok, az ott lesz (es emellett a commitok szepen sorban lathatok)

a git siman megengedi hogy kitorold akar mas munkajat (ezzel kb. egy network share-rel felero biztonsagot nyujtva), atrendezd a commitokat, stb
persze ezt illik legalabb a masterre azonnal letiltani, de ez akkor is vicc hogy azzal kell kezdeni a gitet hogy bizonyos feature-eit letiltod

"miert, ki a felelos?"

Ti, vagyis konkrétan az, aki a közös használatra szánt repot nem git init --shared-del hozta létre.

"de ez akkor is vicc hogy azzal kell kezdeni a gitet hogy bizonyos feature-eit letiltod"

Egy alapvetően elosztott verziókezelőt akartok központosítva használni, ezért inkább úgy kellene megközelíteni, hogy bizonyos feature-jeit (közös használat, lásd két sorral fentebb) be kell kapcsolni.

"a közös használatra szánt repot nem git init --shared-del hozta létre"

a bitbucket hozta letre :)
de (lasd fent) a rebase-nel alapkovetelmeny hogy tudj push -f -elni

"Egy alapvetően elosztott verziókezelőt akartok központosítva használni,"
mondom ismet: bitbucket
Tehat igen, kozpontositva akarjuk (illetve igy _kell_) hasznalni.

Mégis ki lenne? A kolléga, aki törölt a fából. Egyik technológia sem lehet felelős azért, ha azt rosszul használva valami balul sül el.
Miért baj az, hogy olyat is tud egy szoftver, amire alapesetben nincs szükségetek, speciális esetekben meg jó ha van? Attól hogy van rá lehetőséged, még nem kell ész nélkül használni (pontosabban nem ész nélkül kell használni).

a technologia lehetoseget ad arra hogy akar MINDENT eltuntess a repobol, az en szememben ennel nagyobb bune egy verziokezelonek (aminek az egyik fo feladata hogy biztonsagban tartsa a forrast) nem lehet

basszus ne kelljen mar folyamatos backupot csinalgatni minden commit utan a git reporol csak hogy tenyleg benne maradjon amit oda commitol az ember...

amugy meg ha a szoftver lehetoseget ad arra hogy valaki egy mozdulattal az egeszet elbassza, akkor az meg is fog tortenni (Murphy, IT userek, stb)

"Miért baj az, hogy olyat is tud egy szoftver, amire alapesetben nincs szükségetek, speciális esetekben meg jó ha van?"
Azert mert az az 'olyan' az nem egy artatlan kis apro feature, hanem a teljes munkat megsemmisito lehetoseg.
Es azert baj, mert alapbol siman engedelyezi, nem pedig a 'specialis esetben' kulon engedelyezheto.

Egy git push -f ... nem tüntet el semmit a repóból.

Tegyünk tisztába pár dolgot. Minden repository manager gyárilag tiltja a published (tehát nem local only, hanem a közösbe pusholt) commitok akár törlését akár megváltoztatását - praktikusan a forced pusht.
Természetesen lehetőség van rá, mint ahogy lehetőség van fájlokat törölni a fájlrendszerről, amik esetleg fontosak lehetnek - az ember azért bizonyos szinten tudja már, hogy mit csinál.
A másik dolog hogy minden commit tökéletesen immutable a gitben, az is megmarad, amit hard reseteltél, csak tudni kell a shaID -t hozzá.
Ha ezek a dolgok TÉNYLEG ennyire fájnak, akkor a git nem való az általad vezetett csapatnak.

--
arch,debian,openelec,android

Subversionnel checkoutolhatom egy borzasztóan hatalmas repó engem érdeklő könyvtárát ahelyett, hogy az egészet kéne. (Jó, sparse checkout... Rég használtam.) Nem egy baromi hosszú hash a revision number. Meg ilyen apróságok.

Idézet:
Nem egy baromi hosszú hash a revision number.

Itt is elég az első hét karakter.

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

Annyi elég, amennyi egyedien azonosítja, de legalább az első négy.
És ami ma egyedien azonosítja, az nem biztos, hogy holnap is fogja.

"És ami ma egyedien azonosítja, az nem biztos, hogy holnap is fogja."
Kuncogok előre, de ez így pontosan mit jelent?

--
arch,debian,openelec,android

Létrehozol egy projektet, aminek az első commitja stílszerűen e83c5163316f89bfbde7d9ab23ca2e25604af290 lesz. Mivel ez az egyetlen commit van, ezért az első négy karakter (e83c) egyértelműen azonosítja. Eltelik néhány nap, hét, hónap, év, a projet nő, hozzájön még néhány tízezer, százezer, stb commit, amik közül már több kezdődhet ugyanezzel a négy karakterrel.

Ezt az első négy karaktert honnan vetted?

Szerk: oké, itt írnak róla: https://git-scm.com/book/uz/v2/Git-Tools-Revision-Selection De gyakorlatban az első hetet érdemes figyelni és ahol rövid commit ID-t jelenítenek meg, ott is így hivatkoznak rá.

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

Értem. Persze mert az csak egy shortcut és te meg én is értjük hogy miért nem elég az a pár karakter később. Ha kell az az id valahonnan valahova, akkor kicopyzod a git(k,x,g,akármi) vagy a git logból, vagy a webes git böngészőből vagy az idea-ból vagy bármiből.

--
arch,debian,openelec,android

Az első hét már kvázi egyértelműnek tekinthető (repón belül), de én az első nyolcat szoktam. Viszont egy elosztott verziókezelőben nincs is értelme az olyannak, mint pl. „14. commit”

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

Ez a repository méretétől függ, pl a linux.git esetén ma már 70 olyan commit van, aminél nem elég az első 8 karakter, és van már két olyan is, ahol a 9 se. Nem véletlenül használják az első 12 karaktert, hogyha egy commit message-ben egy korábbi commitra akarnak hivatkozni.
És ezek még csak a commitok, ha pl olyat mondasz, hogy git show deadbeef, akkor a rövidített objektumnévnek már nem csak a commitok, hanem minden objektum között egyedinek kell lennie.

Eggen, de a revision 6 és revision 7 között el tudod dönteni melyik a frissebb, a revision d894735 és revision 736f73d közül melyik frissebb? Egy ilyesmi nekem például hiányzik a git-ből. Emlékeim szerint a hg-ban mindkettő érték van (7:d894735).


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

És ha a 6 és 7 között a másik ágban van commit? Amúgy a bazaar is így számozott, ha jól emlékszem.

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

Ha én commitolok local 14:30-kor, Pistike 14:35-kor, Pistike feltolja 14:40-kor, majd én a sajátomat 14:45-kor, akkor melyik (#1, #2, #3, #4) commitnak mi a rev. numberje, ha a #1 rev numberje 10 volt?
S ha ezt megbolondítjuk még branchekkel?
--
blogom

git describe --all egyik masik sokat lok a dolgon, de van egyeb mondja is annak, hogy kideritsd, melyik a frissebb. Altalaban nem szokott szuksegem lenni erre az infora, max arra, hogy melyik tartalmazza a masikat, ami szinten trivialisan kideritheto.

--
|8]

Persze, megoldható, például a dátumot használod a verzió azonosítására, de nekem az svn féle megoldás jobban tetszik. Lehet, hogy nincs igazam, sőt több ponton vérzik, de ez egy erősen szubjektív téma. :-)


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

A describe pont egy svn-szeru szamot ad neked.

--
|8]

Neked is köszi, ránézek.


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

Irreveláns, hogy melyik a "frissebb".
De ha ez csak egy pongyola megfogalmazása annak, hogy melyik commit leszármazotta a másiknak, az mindjárt más, és tényleg fontos lehet, de ezt Subversionben sem tudod megmondani pusztán a revision száma alapján, mert simán lehet a két commit két párhuzamos branch-en.

Nekem nem irreleváns. :-) Ha látok egy olyat, hogy 2.1-test-git26837651 és egy 2.1-test-git47636534, akkor nem tudom melyik az aktuális(abb) verzió. Filedátum nem számít, mert az a fordítás ideje. Ha ugyanezt látom svn alatt, akkor látom, hogy 2.1.100 és 2.1.453. Nagyobb szám, későbbi commit. Egy branchról van szó. Ha másik branch, akkor más a file/csomag/archív neve (2.1 helyett 2.2 vagy akár bin helyett bin-test).


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

Nem igazán tudom, hogy mikor van olyan eset, hogy egyetlen azonosító információm van egy commitról és az alapján szeretném eldönteni melyik a "frissebb".
A git log szépen megmutatja a commit-ok sorrendjét és függőségeit. Ha egy igazi verzióról van szó, akkor meg tag-eljük, új branchbe, vagy akár új repository-ba rakjuk az adott verziót.

Látok egy weboldalon egy listát, hogy dosbox-x-git28da367.zip, dosbox-x-git1d72afe.zip és dosbox-x-gitd8ae381.zip. Melyiket töltsem le, hogy a legutolsó verzióm legyen meg?

De kezdem látni, hogy kicsit félreértettetek. Én arra gondoltam, hogy amikor automatikusan létrehoznak egy fordított binárist és elnevezik valahogy, akkor az svn ad segítséget, hogy melyik revízió, a git meg nem. De az ajánlott describe ezen segít, azt még megnézem.


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

Verziókezelőből kinyert archivok és snapshotok elnevezése nem a verziókezelő feladata, az ezekből létrehozott build artifactok elnevezése meg aztán főleg nem.
Ha neked fontos, hogy ezek nevéből ránézésre meg lehessen mondani, hogy melyik aktuálisabb, akkor nosza, nevezd el őket úgy. Git ehhez is nyújt segítséget, a minden opció nélküli git describe kimenete pl. v2.7.0-25-gfc10eb5, ahol az a "25" a v2.7.0 tag után következő commitok száma, "nagyobb szám, későbbi commit", szóval egyből meg is felel az igényeidnek.

Köszi, ezt megnézem.


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

FYI: subversion esetén sem tudod eldönteni, hogy az r6 vagy az r7 az újabb, amennyiben egy repot (vagy annak részét) beleimportálnak egy másikba, ugyanis (nyilvánvaló) okokból a revíziók a már meglévő n+1..n+m tartományba fognak esni, míg a dátumok a régiek maradnak.

Ld. r867-től r877-ig: http://imgur.com/hzw7wFs

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

866 és 867 között látok egy dátum visszaugrást, feltételezem erre célzol, de az alap felvetésem, hogy a fejlesztés menete szempontjából a 867 újabb, mint a 866 áll, nem? Értem, hogy forrás dátum alapján nem, gondolom én, de a projekt szempontjából az a frissebb.

Persze, extrém példákat is lehet mondani, hogy visszamásolom a legelső verziót, commitolok és a következő revision nagyobb lesz, pedig egy régi hulladék forrást tartalmaz.


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

Fejlesztés szempontjából egy fikarcnyival sem újabb a 867, mint a 866. Két projekt logisztikai okokból egy repoba lett mergelve.

Projekten belül értelmezve a revízió számokat persze sorfolytonos, de pusztán revid alapján kijelenteni, hogy nagyobb = újabb, nem igazán valid érv.

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

"Két projekt logisztikai okokból egy repoba lett mergelve."
Erre talaltak ki az SVN externalst.

Masreszt meg a cel repo (ahova mergeltel) szempontjabol az bizony ujabb kod: olyan kod, ami nem volt ott regebben. Az egy dolog, hogy mikor keletkezett a file. Maga a commit ujabb. Es csak ez szamit.
Ha abbol a repobol buildelsz, akkor a 873-es frisebb kodot tartalmaz, mint a 872.
Hiszen az ujabb/nem ujabb relaciot aszerint kell nezni, hogy eppen te most mit buildelsz le es adsz ki. Es ott bizony ez a nagy import az ujabb kod.
Mint amikor mondjuk van 3 branched: feat1, feat2, meg prod.
feat1 elobb lett kesz, mint feat2, de feat2-t elobb mergeled prodba, mint feat1-et. Hiaba kesz feat1 mar regebb ota, prod szempontjabol a benne levo kod ujabb. Hiszen amikor prodbol buildelek, egyszer csak feat2 featuresetem lesz, utana meg feat2+feat1.

SVN externalst ismerem, de végeredményben ahogy elkezdtek a projektek összefonódni, oda jutottunk, hogy sokkal egyszerűbb lenne, ha minden egy repoban lenne és akkor nem kellene két (eseténként három) repoba commitolni egy olyan módosítást, ami mindet érinti. Pl. kapcsolat a két rendszer között, egyik oldalon a hívó, másik oldalon a fogadó fél.

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

Az óriási git repo clone-ozása sem egy nagy cucc: ~5000 commit, ~3000 fájlos struktúra nem tart tovább extrém esetben 15-20 másodpercnél.

"Nem egy baromi hosszú hash a revision number."
És? Ki szoktuk copyzni. És elég annyi, amennyi egyedien azonosít.

--
arch,debian,openelec,android

Ez azért nem egy óriási git repo.

Egyébként meg azért, mert egyszerű, mint a faék és van, hogy bőven elég az is. Pl. múltkor meguntam valamiből a manuális verziózást, gépek között ide-oda másolgatást és fogtam betoltam egy SVN repoba, mert ez esett leghamarabb kézre. Miért SVN? Mert egyszerű, mint a faék, nem kér sokat enni, branchelve a büdös életben nem lesz, bináris az összes fájl, egyébként sincs rá merge tool, nem is nagyon lehet/van értelme, csupán verziózott history kell.

Erre a funkcionalitásra a git overkill.

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

Vannak use casek persze amire megfelelő az svn.

--
arch,debian,openelec,android

Ez szép meg jó, de git-nél a klónok egyben backupok is (függően attól, hogy mit fetch-elsz), míg az SVN-hez nem árt valami plusz backup megoldás. Ez már rögtön megbonyolítja az SVN-es rendszert és a git tűnik simábbnak.

Jelen use caseben maga az svn volt a "backup",

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

Hááát azért so-so, a mezei developerek masináit én nem tekinteném backupnak. Mindenképpen kell mögé dedikált megoldás. Persze a semminél sokkal több.

Amennyiben megpusztul az origin repo, és fogalmad sincs mondjuk minden fontosabb branch utolsó commitjainak SHA idjáról (mert ez az információ egyértelműen beazonosítja a commitot és egyben minden parentet egészen az initialig), akkor maximum tippelni lehet, hogy az a tuti, ami az emberek 90%ánál egyezik.

--
arch,debian,openelec,android

Ha megpusztul az origin repó, azért az embereknél még megmarad a hivatkozás a távoli branch-ekre, így a commit is azonosíthatóvá válik. Persze a backup sose árt.

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

Én most saxus esetéből indultam ki. Szerintem jobb oda a git, mint az svn + svnsync.

Nyilván bonyolultabb esetben nem árt a rendes backup. De én anélkül sem esnék kétségbe, a legelső gépen lévő cuccból csinálnék egy bare repót, a többieknek meg szólnék, hogy pusholjanak újra. Max. lesz egy-két váratlan merge. Inkább a felhasználók elveszett accountja miatt aggódnék, hogy a profiljukat (és benne a publikus kulcsaikat) újra állítgathatják be.

Leszámítva, hogy volt egy gép, ahol futott SVN és csak egy repot kellett létrehozni, nem kellett kotorni neki privát githostingot. Nem mindent akarok kirakni github/bitbucketre.

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

Privát githosting? ssh nem volt?

Tehát még egyszer: adott volt az infrastruktúra, nem akartam vele 5 percnél többet baszakodni, amiből 3 az volt, hogy végigvettem a rendelkezésre álló eszközöket, 1 volt az SVN repo létrehozása és újabb 1 perc volt beimportálni a meglévő kontentet. És nagyjából ennyit ért meg a feladat.

És egészen pontosan 0 új dolgot kellett emiatt csinálni. (A VPS-en még git sincs, nem volt még rá szükség, egyébként is egy kőkorszaki FreeBSD8).

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

Ha nem állt rendelkezésre git, az más. De alapvetően egy svn és git szerver belövése közt nincs igazán különbség, pár perc mindkettő.

Ez megtehető gitblit/gitlab segítségével is, igaz ezek azért nagyobb volumenű cuccok, nem szimpla git repo konténerek.

--
arch,debian,openelec,android

Egyrészt vannak még helyek, ahol nem álltak át. Másrészt vannak olyan szempontok, ahol az SVN jön ki jobbal a gittel szemben. Nyilván ha ráállsz az intenzív branchelgetésre, meg rebase-elésekre meg mindenre, akkor azt azért már nem tudod SVN-ben úgy tolni.

Tenyleg csak kivancsisagbol: miert lenne jobb nekem az egyszemelyes itthoni kis projektjeimhez a git, mint az svn. Tekinteve, hogy nekem kell a szervert is adminisztralni es az svn mar szepen be van allitva, mi lenne az a nagy elony, amiert migralnom kellene, meg egy uj szervert installani, beallitani, megtanulni adminisztralni.

Szoval nekem egyelore kedvencebb, mert egyszeru, mert mar megvan, es mert jol mukdik. Es eleg reg van hozza jol bevalt grafikus felulet is, ami azert kenyelmes.

Mielott valaki altalanossagokat kezdene irni, eleg jol tisztaban vagyok a verziokezelessel, es pontosan tudom, hogy egy eloszottt repos verziokezelo rendszernek milyen elonyei vannak, es hogy az SVN vallalti kornyezetben nagyon korlatozottan alkalmas. Amiket eddig vallalti kornyezteben fejlesztokent (nem adminkent) modom volt hasznalni: CVS, ClearCase, CM Synergy, MKS, SVN. Eddig mondjuk pont a git meg nem kerult sorra, szoval melyrehatobb konkret tapasztalatom nincs, csak a koncepciot ismerem.

Szoval ha valaki meg tud gyozni a git elonyeirol az en felhasznalasi esetemet alapul veve, akkor lehet, hogy valtok, de addig is marad az SVN a kedvencem.

> Tenyleg csak kivancsisagbol: miert lenne jobb nekem az egyszemelyes itthoni kis projektjeimhez a git, mint az svn. Tekinteve, hogy nekem kell a szervert is adminisztralni es az svn mar szepen be van allitva, mi lenne az a nagy elony, amiert migralnom kellene, meg egy uj szervert installani, beallitani, megtanulni adminisztralni.

> Szoval nekem egyelore kedvencebb, mert egyszeru, mert mar megvan, es mert jol mukdik. Es eleg reg van hozza jol bevalt grafikus felulet is, ami azert kenyelmes.

Ilyen felhasználásra imho semmiben nem jobb, minek váltanál?

(Amúgy git szervert nagyon nem kell állítgatni, legalábbis ssh-n keresztül azonnal megy. Most tervezem, hogy a szakdolgozóimat rászoktatom a használatára, így a kódjukat rendszeresen küldhetik egy központi repóba, én meg tudom reviewolni, és így is konzultálni őket. Nekem is jó, meg nekik is.)

Egyszemélyes használatnál az előnyei:
- nem kell szervert adminisztrálnod
- használhatod csak a lokális gépeden
- használhatod olyankor, amikor épp nem elérhető a szerver
- egyszerű a merge/branch kezelés, pl. így könnyen tudod az új feature-t külön branchben fejleszteni, a közben észrevett hibák javítását külön commitolni
- könnyű az egy személyes projekted verziókezelését többszemélyessé alakítani

"- nem kell szervert adminisztrálnod
- használhatod csak a lokális gépeden"

SVN-nél sem kell feltétlen szerver, minden további nélkül csinálhatsz valahova egy repo-t, hogy aztán file:///-el érd el.

"- használhatod olyankor, amikor épp nem elérhető a szerver "

Ld. előző pont.

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

Amikor megint elérhető a szerver, akkor a file:/// -ból fel tudod küldeni a szerverre a commitokat?

Miféle szerver, egyszemélyes, szerver nélküli használatról beszéltem.

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

Rengetegen használnak egyszemélyes használatnál szervert, pl. a GitHub-on is van egy rakat ilyen projekt, illetve a kérdező is úgy tűnik, hogy így használja:

"Tenyleg csak kivancsisagbol: miert lenne jobb nekem az egyszemelyes itthoni kis projektjeimhez a git, mint az svn. Tekinteve, hogy nekem kell a szervert is adminisztralni es az svn mar szepen be van allitva, mi lenne az a nagy elony, amiert migralnom kellene, meg egy uj szervert installani, beallitani, megtanulni adminisztralni."

Koszi, ez egy jo attekintes.
Van valami jol bevalt GUI linuxon? 5 klienst talaltam a git oldalan, de nincsen hozzajuk ertekeles.

Én QGit-et szoktam használni linuxon. Ha 2 fájlt kell összehasonlítani (pl előző commit változás) akkor hozzá a Kompare (vagy ha nem KDE a környezet, akkor meld-et). Nekem ez jött be.
---------------------------
Oszt jónapot!

+1 a meldre. Jó kis eszköz vizuális diffelésre.

+1 innen is

Koszi

Szerintem az SNV-t összességében egyszerűbb használni, különösen olyan csapatban, amelyben SCM ügyekben junior-abb kollégák is vannak. A Git-tel néhányan egészen ordenálé dolgokat tudnak előadni, aztán jönnek panaszkodni, hogy xyz nem sikerült vagy elvesztették a munkájukat...stb.

Az SVN nem rendelkezik a GIT elosztott képességeivel, de erre a csapatok döntő részénél nincs is semmiféle szükség. Viszont, az SVN valamennyivel egyszerűbb workflow-ja a leggyakrabban használt műveletek vonatkozásában egyszerűbb mint a Git-é (többiek változásainak lehozása/merge-elése, saját fejlesztésem betétele).

Szerintem tökre nem lehet kimondani, hogy „a csapatok döntő részénél nincs is semmiféle szükség”. Milyen csapatok? Milyen workflow? Amúgy a git-et is lehet svn-szerűen használni (automatikus hozzáadás commitnál, majd automatikus push) és így a lehetőség megmarad azoknak is, akik összetettebb műveletet szeretnének végrehajtani.

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

> A Git-tel néhányan egészen ordenálé dolgokat tudnak előadni

+ ilyenkor jönnek elő a rejtélyes megjegyzések, hogy a hivatalos git quickstart leírásban is megemlített git pull mégiscsak szar.

Itt, az első válaszban részletesen le van írva, hogy miért rossz a git pull, a második válaszban pedig, hogy miért nem rossz.

rcs4ever :-P

Látszik, hogy még mindig hátulgombolós vagy. Kérdezd meg Csabát az SCCS-ről. (Anno ő tartott belőle bemutatót a cégnél.)

Majd adandó alkalommal megteszem - nekem az rcs volt az első, amit használtam is - emlékeimben haloványan dereng valami, miután utánanéztem, hogy mi ez, de hogy csak említés szintjén volt, az biztos...

Ha épp kedved támadna kőkorszaki eszközökkel játszani, GNU CSSC néven van belőle floss verzió - már a leírásában is ott van, hogy kizárólag azért készült, hogy ha véletlenül valami SCCS-ben van tárolva, akkore kereskedelmi Jujniksz nélkül is ki lehessen belőle szedni az adatokat.

Majd ha sok időm lesz (most nincs)... Ahogy én tudom, ilyesféle (vagy újabb) úri huncutságot errefelé nem igazán használnak :-P

Kőkörszaki vonalon még ajánlanám az arch-ot! :)

Két dolgon csodálkozom.
1) Azt megértem, hogy valahol még SVN-t használnak, mert kell. De mint kedvenc? Az SVN egy idejét múlt vacak, a koncepciója alapvetően elavult és alkalmatlan a komoly fejlesztői csoportmunkára. Mondom úgy, hogy életem nagyobb részében SVN-t használtam, sajnos.

2) Fura, hogy a Mercurial nem népszerűbb. Mindent tud, amit a git, cserébe intuitív, pár nap alatt tanulható, és szinte lehetetlen bármit is elkúrni benne.

A Mercurial a legjobb. Szerintem egy csomó history és verziófa szétgányoló cuccot nem tud, amit a git viszont igen.

Nem kell mindent használni abból, ami elérhető. De adott helyzetben hasznosnak bizonyulhat.

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

A Wikipédia szerint (amit alátámaszt a fájlkezelőm is):
"[Mercurial] Written in: Python and C"
"[Git] Written in: C, Shell, Perl, Tcl, Python"

Fuszenecker Róbert

"Mercurial [...] Mindent tud, amit a git"

Sajnos közelsem.

1. Nem mindenhol folyik a fejlesztés több száz fős csoportokban. Ahol subversion-nel kezdtek és azóta nőtt a fejlesztők száma, nem feltétlenül éri meg átállni (és PM legyen a talpán, aki el tudja adni a managementnek, hogy megéri váltani).
2. Miért fura? Ahol MS technológiát használnak, ott a TFS vagy a GIT az, ami támogatva van Visual Studioból ergo azt fogják használni. Marad a Perl, Python, C, C++ és PHP, amin osztoznia kell a GIT-tel, Subversionnel és a többiekkel.

Nekem személy szerint nincs kedvenc verziókövető rendszerem. Amiket eddig láttam, mind egy buta f0s és kb ugyanazt tudja, csak egy kicsit máshogy. A TFS talán némileg kikandikál a trágyából a work item, web portal, team room és hasonló okosságok miatt, viszont az szerintem megbocsájthatatlan bűn, hogy halvány lila gőze sincs a Visual Studio által használt solution és project fájlok felépítéséről (legalábbis az MSBI stack területen).
Ne vedd személyeskedésnek a hozzászólásom, ebéd utáni kajakómában ez szúrt leginkább szemet :)

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

git - sucks = hg

Tényleg van, akinek a perforce nevű idegromboló borzalom a kedvence, vagy csak véletlenül félre nyomtak?

ClearCase-re is érkezett 5 szavazat.

Fuszenecker Róbert

Aki ezekre meg a TFS -re szavazott az látott mást is?

--
arch,debian,openelec,android

És te "ezeket meg TFS"-t? :)

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

Aki p4-re szavazott, az szerintem csak partfegyelem miatt lehetett :D

Mondjuk mukodik, de szerintem 21 eve is tok ugyanigy mukodott mar.

Tehát megbízható, stabil cucc :-)

Amugy az, csak szemet kenyelmetlen.

Kollegám válasza: Dropbox-ra nem lehet szavazni?