HOVD 2015 - Kedvenc verziókezelő rendszer

HUP

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

( uid_4263 v | 2015. 12. 14., h – 15:49 )

Az svn miért lehet kedvencebb mint a git?

--
arch,debian,openelec,android

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.

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

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

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

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.

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…

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.

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.

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.

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

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


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

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

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

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.

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…

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!

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.

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

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

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

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.

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™

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.

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™

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™

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

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…

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.

( Joejszaka v | 2015. 12. 23., sze – 23:35 )

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.

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"

( zdesigner | 2015. 12. 29., k – 16:15 )

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

( asch v | 2016. 01. 13., sze – 16:25 )

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