HOVD 2017 - Kedvenc verziókezelő rendszer

HUP

bazaar
0% (3 szavazat)
clearcase
0% (3 szavazat)
cvs
2% (10 szavazat)
git
83% (548 szavazat)
gnu arch
1% (4 szavazat)
mercurial
2% (11 szavazat)
perforce
1% (4 szavazat)
rcs
0% (2 szavazat)
subversion
10% (69 szavazat)
team foundation server
1% (9 szavazat)
Összes szavazat: 663

( Boobek | 2017. 12. 15., p – 15:04 )

Ezt a szavazast jovore el lehetne hagyni, ha csak valami nem tortenik..

( trey | 2017. 12. 17., v – 09:53 )

"cvs"

Theo de Raadt, te vagy?

--
trey @ gépház

( manfreed (nem ellenőrzött) | 2017. 12. 17., v – 20:42 )

Vajon aki gitre szavaz azért teszi, mert azt ismeri/használja, vagy mert tényleg azt tartja a legjobbnak?

Én hajlottam rá, hogy a mercurialt megnyomjam, mert amiket hallottam róla az alapján sokkal szimpatikusabb mint a git (annak ellenére, hogy az utóbbit ismerem jobban, és azt vagyok kénytelen használni)

SVN-t sokkal tobbet hasznaltam (elozo 2 munkahelyemen is az volt a repo), es nem szerettem. A gitet kevesebbet hasznaltam, alap szinten ismerem csak, de nekem jobban megfelel, szoval azt jeloltem be.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Tényleg jó a Mercurial, cégnél azt használjuk. A TortoiseHg Workbench crossplatform, és tök egyértelmű, jól használható felülete van. Eddig akármelyik Git GUI-t próbáltam (GitHub desktop kliense, SourceTree, Tower, GitKraken), mindegyikkel sikerült fél percen belül lábon lőjem magam egy egyszerű submodule-os repóval, úgy hogy konzolból kellett helyreállítani.

+1
Parancssoros használatra tervezett programhoz GUI-t használni szerintem csak arra jó, hogy összezavard magad. Ha nagy gáz van úgyis a parancssorhoz kell nyúlni szóval azt is ismerni kell, akkor meg minek megtanulni pluszba egy GUI-t ami *soha* nem fogja ugyanazt tudni mint a parancssor?
Max akkor látom értelmét a GUI-nak ha nem akarsz valamit megtanulni és nagyon ritkán használod.
--
:wq

Nyilván érdemes a CLI-t minél jobban ismerni (főleg az alapokat), de szerintem messze nem ennyire fekete-fehér a dolog. A verziókezelés pont az a témakör, ahol egy-egy jó GUI-s reprezentáció jelentősen meg tudja gyorsítani a munkavégzést.

Én pl. jellemzően Mercurialt használok, általában parancssorból. De eszembe nem jutna a branchek közötti kapcsolatokat, history-t vagy éppen commit előtt a módosított fájlokat (pláne a diffeket vagy rosszabb esetben merge conflictokat) CLI-ben turkálni, ha nem muszáj. Sokkal kényelmesebb (és számomra gyorsabb) egyes részfeladatokra a GUI használata a fa-nézetekkel, side-by-side diffekkel és hasonlókkal. Egyszerűen jobban átlátom, hogy mit csinálok. Minden másra meg ott a CLI. Ja, és olyan nagyon azért nem zavartam össze magam ezzel a megközelítéssel. :)

Lehet csak engem zavarnak össze ennyire a parancssoros programokra ráhúzott GUI-k. Mindig úgy érzem, hogy korlátoznak a lehetőségekben és körülményes módokon kell megtegyem azt ami amúgy parancssorban nagyon egyszerű.

A grapfikus megjlenítés (fa nézet, diffek) az teljesen mást tál tészta. Az emberek egyszerűen sokkal jobbak egy kép értelmezésében mint a szövegében. Ha nagyon durva merge-conflictom van én is meld-hez nyúlok, vagy bonyolult history megtekintéséhez is néha előveszem a gitk-t (habár egyre ritkábban).
--
:wq

Ezek nem parancssoros programokra ráhúzott UI-k. Hanem ugyanazon dolog fölé más-más interfész kerül.
Van mögötte egy library halmaz, amely library halmaz által ajánlott képességekből valaki GUI-t épít, valaki meg CLI-t. Nem a CLI fölé épül a GUI normális esetben ám.

"Ezek nem parancssoros programokra ráhúzott UI-k" - esete válogatja. Most gyorsan megnéztem 3 különböző eszközt, ami Mercurial "fölé" kéznél volt (SourceTree, Tortoise, IntelliJ), és ebből bizony kettő úgy oldja meg, hogy egy hg.exe processt spawnol a megfelelő parancssori argumentumokkal (a hg kimenete elég jól testre szabható). :) (A Tortoise valami mást trükközik.) Persze itt is lenne egy halom más lehetőség is (főleg, hogy full pyhton az egész Mercurial), de azért ez sem egyértelmű.

Ez baromi megoldás, hiszen szövegkimenetet kell parzolni a GUI-hoz. Ami eléggé költséges, és fontosabb: törékeny dolog. Egy hg kimenete nem változhat meg, mert akkor eltörnek a rá épülő eszközök.
Pedig a kimenet csak egy szöveges reprezentációja annak, amit a program valójában csinál. Pedig aztán a kimeneti formátumnak semmi köze ahhoz, hogy a repositoryban valójában mi történik.

HA nincs a Mercurialhoz nem hg alapú frontend, mert nincs library hozzá, csak szöveges parzolás van, akkor a Mercurial egy baromira rossz eszköz.
Most egy kicsit utánanéztem: az ajánlott mód a CommandServer, aminél az van, hogy kell egy folyamatosan futó processz (daemon), amivel egy repository menedzselhető.
https://www.mercurial-scm.org/wiki/CommandServer
És ez is egy hg.exe-t indít.
Az API az nem ajánlott. Sőt, a CLI az ajánlott.
https://www.mercurial-scm.org/wiki/MercurialApi
"For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface. Alternately, use the CommandServer or the libraries which are based on it to get a fast, stable, language-neutral interface."

Na hát jó. Ezek alapján a szememben a Mercurial egy rossz eszköz, úgy néz ki. A CLI maga a stabil API. Istenem...hát nem tenném mögé a forráskódon alapuló toolingomat (CI, review, meg más, forrást használó munkafolyamatok)

most egy kicsit threadgyalázok, szerintem pont nem:

The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable than Porcelain level commands, because these commands are primarily for scripted use. The interface to Porcelain commands on the other hand are subject to change in order to improve the end user experience.

innen

(s a fentebbi linken sem találok ilyen infot, hogy a porcelain commandok stabil apit garantálnának, sőt, még csak ilyen kapcsoló sincs, szerintem)

Azt nem tudom, hogy történetileg miért pont ez lett az ajánlás. Én sem így tervezném, ebben egyetértek, de gyakorlatilag semmit nem tudok az architektúrával kapcsolatos döntéseik hátteréről.

Az viszont tagadhatatlan előnye ennek a megközelítésnek, hogy gyakorlatilag minden nyelv/platform alatt rendelkezésre állnak processzindítási és/vagy parancsfuttatási lehetőségek, így nincs az, hogy C-lib meg Java-lib meg még kismillió, gyakorlatilag egyetlen API-t kell visszafelé kompatibilis módon karbantartaniuk, mégpedig azt, amit a mezei user is használ a parancsok kiadására. Szóval szerintem lehet mellette is érvelni.

(Egyébként ha nagyon mélyen bele akarnék folyni valamilyen hg-közeli eszköz fejlesztésébe, akkor talán pythonban próbálkoznék.)

"Pedig aztán a kimeneti formátumnak semmi köze ahhoz, hogy a repositoryban valójában mi történik." - ezért ad lehetőséget arra, hogy a legtöbb parancs kimenetét totál testre lehessen szabni olyan formátumra, ami a hívónak kényelmes.

A költségességben is van igazság (ha normál in-proc API-hívásokkal vetjük össze), de a legtöbb esetben a GUI-ra kivezetendő műveletek nem annyira kis granularitásúak, hogy ez gyakorlati problémát jelentsen.

Másfelől: a hg-t csak példának akartam hozni arra, hogy vannak olyan esetek, ahol nem igaz a kvázi klasszikusnak tekinthető "GUI-k/CLI-k egy adott libet hívogatnak" elv. Biztosan van egy halom más is, ami így működik, hirtelen ez ugrott be. :)

"Ezek nem parancssoros programokra ráhúzott UI-k"

Én ezt inkább úgy értelmezem, hogy a gui más workflow-t ad, mint a cli. Az egy implementation detail, hogy a gui a cli-s commandokat hívja, vagy egy lib függvényeit, a felhasználónak ez egyáltalán nem érdekes.

Pl. git cli-vel először hozzáadod a commitolandó filejaidat a staging area-hoz, aztán commitolsz, a guin ezt a két lépést össze lehet vonni egy lépésbe.

"Lehet csak engem zavarnak össze ennyire a parancssoros programokra ráhúzott GUI-k" - nem feltétlen, ez nyilván azon is múlik, hogy mennyire sikerül jól megcsinálni a GUI-absztrakciót az alapfogalmak fölé. Nem mindig találják el jól sajnos.

"Mindig úgy érzem, hogy korlátoznak a lehetőségekben" - a legtöbb esetben ez részben cél is szerintem (mármint hogy a gyakori feladatokra legyen egyszerűen megfogható, használható, a többire meg lehet CLI-zni). Illetve nagy előnyük szerintem, hogy akit egy parancssor esetleg elrettent egy-egy hatékony eszköz használatától, azt talán könnyebb rávenni az ismerkedésre egy jó GUI-val.

"A grapfikus megjlenítés (fa nézet, diffek) az teljesen mást tál tészta." - szerintem nem teljesen, mert ebben az esetben ezek is ugyanannak a fejlesztői munkafolyamatnak a részét képezik.

"Az emberek egyszerűen sokkal jobbak egy kép értelmezésében mint a szövegében." - igen, ezért hatékonyabb azokra a részfeladatokra, ahol ilyesmire van szükség. (Persze, embere válogatja.) :)

"Ha nagyon durva merge-conflictom van én is meld-hez nyúlok, vagy bonyolult history megtekintéséhez is néha előveszem a gitk-t" - na, ez az a rész, ahol én az utóbbi években igyekszem egy kvázi standard folyamatot használni. Azaz nincs "durva merge-conflict" vagy "egyszerű merge-conflict" (nálam), hanem merge-conflict van, amit ugyanazzal az eszközzel oldok meg. Nem azért, mert képtelen lennék alkalmazkodni ahhoz, hogy az egyik helyzetben ezt, a másikban meg azt használjam, hanem egyszerűen úgy érzem, hogy nem éri meg a minimális plusz befektetett energiát sem, hogy miközben fejben már félig a következő részfeladat megoldásán (vagy épp a conflict "jó" feloldásán) gondolkodom, akkor eltérítsen az, hogy most épp milyen eszközt használjak a diffre vagy a 3-way merge-re. Ez megy szinte gépiesen, így talán több kraft marad a lényegre. :)

Én elég durva submodulosdit játszom gittel, de a jó öreg `git gui` és `gitk` páros még nem hagyott cserben az elmúlt években. Na jó. van egy kis scriptem, ami a superprojectnél megnézi a git statust és pusholja a submodule-okat, hogy ne mások által nem látható hasht pusholjak.

A GUI-t leginkább arra használom, hogy átnézzem, mi az, amit pusholnék (elő review) és esetleg a nem kellő kódsorokat vagy fájlokat kidobom a stage-ből.

mondjuk én szívesen kipróbálnám egyszer a mercurial-t is céges környezetben (még nem volt hozzá szerencsém sehogy) - s ha legalább olyan kényelmes, mint a git, akkor nincs ellenérzésem vele szemben.

az svn egyszerűen kényelmetlen egy 2+ fős projekten.
az eclipse ugyanez, nem valós alternatívája az intellij-nek.

A Best tools that money can buy-ből pedig nem szeretnék lejjebb adni, nemhiába volt már 17 éve ez a minimum.

A céges környezetben nem tudok segíteni, de ha érdekel a dolog, akkor érdemes átfutni Joel Spolsky Mercurial-bevezetőjét (hginit.com), elég jól magyarázza. Nekem valahogy sosem állt rá az agyam igazából a gitre, de valószínűleg csak azért, mert sosem voltam igazán rákényszerülve, hogy nagyobb, hosszabb feladatokra használjam. Ezzel szemben a Hg (persze megfelelő mennyiségű utánaolvasással, meg úgy általában a DVCS-fogalmak, -mechanizmusok áttanulmányozásával megtámogatva) egész hamar a barátom lett (SVN-ből jöttem anno). :)

Mercurialhoz van mondjuk olyan jó tooling, mint a Gitlab? Code review, merge request, védett branchek, jogosultságkezelés azon a repon, amiből majd a CI buildel?
Egy elosztott verziókezelő lényege a jó csoportmunka-támogatás. Lehet tök fasza a backend, de ha nincs meg a megfelelő folyamat- és csapattámogató tooling, akkok nem fogja senki használni.

Mi Bitbucketet (cloud változat) használunk privát repókkal. Tudom, hogy nem on-premise (arra van a BB Server, de az csak Gitet támogat), ami sok helyen ki is lövi ezt a lehetőséget, viszont az általad említett funkciókat (is) tudja, és kis csapatoknak még ingyenes is (de nagyobb csapatok estén sem vészes). Szerintem elég fasza.

A többi megoldást nem igazán ismerem, de elvileg van (lista még).

Az egyértelmű, hogy Githez több jó eszköz van (már csak azért is, mert nagyobb a közönsége), de szerintem a Hg sincs annyira lemaradva ezen a téren. Plusz IntelliJ platformra épülő IDE-k is fullosan támogatják, én ezt a lehetőséget is sokat használom.

No akkor rendben vagyunk, mert én ugyanezt gondolom viszont ;)
Bár itt hamar kisebbségben leszek a szavazás eredménye alapján, közvetlen céges környezetemben előbbi osztatlan utálatnak örvend, utóbbiról vegyes vélemények alakultak ki. 1-nél nagyobb létszámú team esetében mindenki a netet túrja válaszok után az elcseszett CLI miatt és a "nemlineáris történet" kezelésével kapcsolatban, a GUI toolok mindegyike katasztrófa, és folyamatosan megy az agyalás, hogy vajon amit látnak az a valóság, történelem, vagy a klasszikust idézve "valami úgy volt, hogy majd bekövetkezik veled a múltban, még mielőtt sikerült volna elkerülnöd azáltal, hogy két napot előreugrottál az időben, csak azért, hogy elkerüld a dolog bekövetkeztét".

De röviden csak annyit, hogy ha egy hétköznapi használatra szánt eszközről az elvileg indokolatlan nagy mennyiségű dokumentáció, magyarázat, elemzés, tutorial ellenére még mindig nagyságrendekkel többet kérdeznek a stackoverflow-n a többihez képest, akkor az az eszköz nem segít.

A gittel az a helyzet, hogy amíg nem érted meg az alapokat addig nagyon nehéz használni, folyton guglizni kell minden problémára.
Én mióta végre felfogtam a működési alapelveit egyáltalán nem kell guglizzak. Max a man-page-t nézem meg, hogy milyen flag kell ahhoz amit csinálni szeretnék.
És egy olyan cégnél dolgozok, ahol linux kernel stílúsú munkafolyamat van, szóval az átlagos "commit, pull, push" folyamatot el lehet felejteni.

Az a helyzet, hogy le kell ülni és RTFM. Ehhez a legtöbb fejlesztő lusta, inkább nyomják a három parancsot amit ismernek ész nélkül.
--
:wq

"Az a helyzet, hogy le kell ülni és RTFM. Ehhez a legtöbb fejlesztő lusta, inkább nyomják a három parancsot amit ismernek ész nélkül."

Ez sajnos igaz. De azért a git is hibás a dologban, amiért sokkal inkább hasonlít egy alacsony szintű api-ra mint egy normális cli-re. Persze van néhány porcelain parancs (pl. git pull), de néhány magasabb szintű parancs sokat dobna a cli használhatóságán.

Ezek szerint akkor nagyon kevesen értik, vagy tudják megjegyezni a részleteket. Ettől nem lesz ez a réteg automatikusan hülye hozzá, inkább az eszköz nem elég használható. Baromira gáz, ha a napi munka adminisztratív része ekkora probléma. Pláne úgy, hogy előzménye volt bőven, ami néhány speciális esettől eltekintve tökéletesen ellátja a feladatát, jóval kevesebb ráfordítással.

Én nem azt mondtam, hogy hülye, hanem hogy lusta. :P
Én még sehol nem tapasztaltam azt, hogy hatalmas probléma lenne a gittel napi szinten. Amikor meg tényleg sikerül valamit nagyon összebogozni akkor odamész a guruhoz (általában mindig van egy) és ő kisegít, vagy nézegeted ezt a megoldás diagrammot.
De ez nem csak a git sajátossága. Minden komoly eszközzel így van.
--
:wq

"az esetek nagy százalékában nem lenne szükség a DVCS feature-ökre"

Ez lehet igaz, de milyen hátrány ér belőle, ha ezek elérhetőek? Az ellenkezőjére tudok példát mondani: ha egy project csak GitHubra dolgozik (nem DVSC jellegű a felhasználás), de leáll a GitHub, nem áll meg emiatt minden.

Talán meg kéne kérdezni az apache foundation-t, hogy ezt hogyan managelik. Enterprise környezetben nyilván van replikáció, a lokális repository meg lényegében ismét nem tesz hozzá sokat a dologhoz, ha a team nem egyfős.

A hátrány nem az, hogy "elérhető" a DVCS feature, hanem ami ebből következik, a többlépéses műveletek, feleslegesen komplex workflow, strict version history hiánya, szinkronizációs problémák.

Én nem akarlak meggyőzni. Csak csodálkozok, hogy hogy ragaszkodhat bárki is a régi rendszerekhez. Egy hasonlattal élve a CVS(SVN, stb) olyan mint egy írógép és a git mint egy számitógép. Persze az SVN-nel csak két parancsot kell megtanulni és instans produktív vagy de nagyon lekorlátoz és könnyű úgy elcseszni hogy onnan nincs visszaút. A git viszont - bár nehezebb megtanulni - elképesztő flexibilitást ad és nincs olyan helyzet ahonnan nincs recovery. Gyakorlatilag minden workflow-ot meg lehet vele valósítani. Csak megjegyzésként a lineáris history-t is (sugás: --squash). Persze emiatt jóval bonyolultabb is. Meredek a tanulási görbéje de szerintem abszolút megéri.

Egy előző cégnél elvesztettünk egy klienst mert valaki be-checkin-elt valamit a CVS-be ami miatt egy hónapig nem ment a feature amit el akartunk adni és nem voltak hajlandóak revertelni mert CVSben olyan marha bonyolult (ha lehet egyáltalán). Arról nem is beszélve, hogy CVS-ben doktorid kell legyen, hogy egy branchot létrehozz, szóval nem igazán bátorít a kísérletezésre. Egy régi verzió előtúrása se éppen egy leányállom. A history bogus (nemlétező). Ha backupot akarsz akkor külön tool kell, míg gittel csak egy +remote.

Szóval lehet neked jó a CVS/SVN habár nem bírom felfogni, hogy hogy de én többet olyan céghez nem megyek dolgozni ahol ilyen kőkorszaki toolokat használnak.
--
:wq

Sztem gitnel is eleg par parancs az svn-nel megegyezo felhasznalashoz. Ha valami komolyabb kell, ahhoz meg eleg, ha 1-2 wizard ert a csapatbol. Azzal a par paranccsal viszont itt is rogton produktiv lehetsz.
(bash history szerint ezeket adtam ki valaha: clone, commit, diff, status, log, info, add, init, remote, branch, checkout, merge, mergetool, stash.. ebbol nehany kell rendszeresen)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

A CVS-t szerintem hagyjuk, mert tényleg elavult sok szempontból. Elcseszett backend, storage és még tranzakciók sincsenek... bár még mindig jobb, mint a VSS :)

Hogy az SVN-el mi a problémád, azt eddig sem sikerült kifejteni. Egy faék egyszerű a logikája, amire tetszőlegesen komplex workflow-t is tudsz építeni, strukturáltan, hook-okkal, replikációval, miegymás. Lassan már szórakoztató, hogy olyanokat terjesztenek róla git ventilátorok, hogy nem tud branch-elni, rollback-elni, stash-elni, lassú, a githez képest nagyságrendekkel nagyobb helyen tárol stb. és szépen terjed is a hülyeség, mint a lapos föld elmélet.
Egy hátránya van, hogy a szervert nem kenyérpirítón kell üzemeltetni, bár az a git push/fetch esetében is idegölő lenne.

Szóval nem bírom felfogni, hogy mi az a munkafolyamat, amire kell egy jóval összetettebb, problémásabb rendszer, és SVN-nel nem lehet megoldani ;) Ne érts félre, nem akarom elvenni tőled a lehetőséget, hogy a gitet használd, csak nem értem ezt a rajongást és az ezzel párhuzamos lenézést.

> ezzel párhuzamos lenézést
Pontosan.

Nem vagyok (hivatásos) fejlesztő, csapatban nem dolgoztam még, tehát a véleményem is így értendő.
Eleinte git-et használtam (apróbb kis programocskák, szkriptek, konfigok, latex-fájlok), mivel mindenki azt használja, de nemigen jött át a logikája (valószínűleg csapatban jobban láttam volna). Utána (néhány hónapja) az svn-t néztem meg - lényegesen egyszerűbb a munkamenet, a paraméterek elnevezései valahogy logikusabb(nak tűnik) - sokkal jobban megfelel a gondolkodásomnak (meg persze a könyv is igen jó).
Amire nekem kell, arra az svn bőven elegendő, felesleges a DVCS jelleg és a vele járó előnyök és hátrányok.

>Egy faék egyszerű a logikája
Pontosan: faék egyszerű logika amire (szerintem) csak faék egyszerű munkamenetet lehet felépíteni.
De hogy fejtsem ki pontosan is:
* Ha SVN repót akarok kell hozzá szerver. Ha kezdek egy hobbi projektet (amiből lehet nem lesz soha semmi jelentős de lehet hogy mégis) akkor kénytelen vagyok beüzemelni egy szervert ehhez. Gittel csak létrehozok egy local repot és később egyetlen parancsal tudok hozzá adni remote szervereket tetszés szerint. A remote szerver lehet akár ugyanazon a gépen egy másik lemezen. De beszéljünk munkáról. Kezdeni akarok egy új repót valami új libnek vagy toolnak ami egyelőre kísérleti. SVN: el kell menni a rendszergazdához és kérni egy új repot. Git: local repo, meg lehet osztani a kollégákkal, ha befut lehet neki új szerver a "felhőbe" on-demand.
* Ha meg akarod osztani a módositásaidat akkor fel kell tedd a központi szerverre, mindeki kénytelen használni. Push based munkamenet. A gittel ez pull based (de a push-based is támogatott). Kitolod a módosításokat egy saját helyre (mondjuk privát fork a githubon) és megosztod a linket a kollégákkal. Akit érdekel lehúzhatja. De ha van ssh hozzáférés akkor ki se kell told sehova, a kolléga lehúzza tőled direkt.
* Branching. Tudom, hogy támogatott de fényévekre van a git féle teljesen erőlködésmentes, villámgyors branchingtól. A git féle branching model támogatja a kísérletezést, semmibe se kerül létrehozni egy új branchot és eldobni egy fél óra/nap/hónap után ha mégse jön be. Az egész két(!) parancs. De ha bejön és csak részlegesen akkor triviális kimazsolázni a jó részeket és eldobni azt ami nem az. Triviális visszamenőleg(!) kitisztítani a kódot és gatyába rázni a commit üzeneteket majd megosztani a tiszta verziót.
* Single point of failure. Tudom, hogy enterprise backup meg minden de a ménkű beüt néha.
* Hatalmas projektek ahol a változások egy fa-alakú maintainer rendszeren keresztül kerülnek be a repoba (á lá Linux). Ezt az SVN egyáltalán nem tudja. De nem kell a projekt hatalmas legyen. A mi cégünknél is maintainer rendszer van és csak egy pár embernek van push joga. A változtatásokat a saját privát repo-nkból osszuk meg a maintainerekkel akik ha tetszik a review után behúzzák. De behúzhatják csak kisérleti jelleggel, hogy lefuttassák a teszteket mielőtt(!!) bekerülne a main repoba ahol mindeki szív ha valami nem megy. Minden teljesen integrált, nem kell semmilyen third party cucc. Hogy oldod meg ezt SVN-nel?

Ezek csak amik hirtelen eszembe jutottak. És ezek nem komplex munkamenetek (abból csak egyet hoztam fel, a Linux projektet), hanem egyszerű dolgok amik nélkül én minden nap egy kicsit bosszankodnák ami egy idő után általános elégedetlenségbe csapna át a munkahelyem iránt.
--
:wq

És a hab a tortán. A git teljesen támogatja az SVN féle munkamenetet opcionális bővitési lehetőséggel igény szerint. Persze ilyenkor is több parancsot kell írni mint SVN-nél de erre megoldást jelenthetne mondjuk egy `simplegit` eszköz ami a eltakarná a git bonyolultságát. Az, hogy ez nincs azt mutatja, h vszleg nincs rá igény mert a az a plusz amit a git nyújt valós előnyőket ad.
--
:wq

> Ha SVN repót akarok kell hozzá szerver.
file:// is működik.

> SVN: el kell menni a rendszergazdához és kérni egy új repot. Git: local repo, meg lehet osztani a kollégákkal
SVN esetében is megosztható, akár a file:// segítségével is.

> semmibe se kerül létrehozni egy új branchot és eldobni egy fél óra/nap/hónap után ha mégse jön be
SVN alatt is.

>> Ha SVN repót akarok kell hozzá szerver.
>file:// is működik.
Induljunk mi abból, hogy a kliens fel van téve.
SVN: fel kell telepíteni az SVN szervert, be kell állítani, kell fusson.
GIT: git init . - egyetlen parancs, semmi extra nem szükséges.

>> SVN: el kell menni a rendszergazdához és kérni egy új repot. Git: local repo, meg lehet osztani a kollégákkal
>SVN esetében is megosztható, akár a file:// segítségével is.
Mennyire egyszerű forkolni egy létező repot (git: egyetlen parancs)? Mennyire egyszerű szinkronizálni két repot (git: egyetlen parancs, na jó lehet kettő ha még nem tudtak egymásról)?

A többire nem is válaszoltál. De nem is akarom ezt a vitát folytatni mert a két rendszer annyira különböző, hogy kb annyi értelme van őket összehasonlítani mint a MySQL-t az Apache Cassandra-hoz. Teljesen más igényeket szolgálnak ki. Én miután megismerkedtem azzal amit a git nyújt pluszba ezek alap igényekké váltak számomra, nekem az SVN már sohasem lesz elég jó. De nem is célom, hogy meggyőzzelek, hogy válts, csak arra szerettem volna rámutatni, hogy igenis *van* amivel a git és a DVCS többet nyújt, a többlet nagyonis *jelentős* és igenis van erre valós igény. A git nem csak egy bonyolultabb és nehezebben használható SVN ami csak a divat miatt van felkapva. Ezt szerettem volna ha átmegy.
--
:wq

Nem kell svn szerver, csak akkor, ha a repositoryt ki akarod ajánlani más kliensek felé is.
Egy kliens tökéletesen tud local-only repositoryt működtetni.
Ja, és gitnél is így van ez: szerver akkor kell, ha a repositorydat ki akarod ajánlani más kliensek felé, amúgy local-only az egész.

"Mennyire egyszerű forkolni egy létező repot (git: egyetlen parancs)? Mennyire egyszerű szinkronizálni két repot (git: egyetlen parancs, na jó lehet kettő ha még nem tudtak egymásról)?"
DVCS-t ne akarj nem DVCS-sel összehasonlítani, hiszen CVCS alatt nem létezik olyan, hogy két repo összeszinkronizálása.
Olyan ez, mintha azt kérdeznéd, hogy mivel az Excel meg a Calculator is össze tud adni számokat, milyen nehéz Calculator alatt Pivot Table-t csinálni.


>DVCS-t ne akarj nem DVCS-sel összehasonlítani, hiszen CVCS alatt nem létezik olyan, hogy két repo összeszinkronizálása.
>Olyan ez, mintha azt kérdeznéd, hogy mivel az Excel meg a Calculator is össze tud adni számokat, milyen nehéz Calculator alatt Pivot Table-t csinálni.

Nem is akarom összehasonlítani és ezt léírtam a fenti hozzászólásomban is (lásd MySQL vs. Apache Cassandra hasonlat). Ami mellett én érvelek az az, hogy a DVCS több mint a CVCS és erre a többre van valós igény, a DVCS nem a CVCS-nek egy fölöslegesen bonyolult de divatos változata. A bonyolultság indokolt azzal a többlettel amit nyújt. Aki ezt nem hajlandó belátni, vagy nem hajlandó a további bonyolultságot kibogozni, esetleg nem igénye az maradjton tőllem az SVN-nél, én nem bánom.
--
:wq

>> Ha SVN repót akarok kell hozzá szerver.
>file:// is működik.
Induljunk mi abból, hogy a kliens fel van téve.
SVN: fel kell telepíteni az SVN szervert, be kell állítani, kell fusson.

Épp ezt magyarázom, hogy nem. Kb. ennyi: 

svnadmin create /var/svn/repos/foo
svn checkout file:///var/svn/repos/foo

És lehet is dolgozni. A file:// protokoll (remélem, ez a megfelelő szakkifejezés) nem igényel futó svn-szervert (svnserve).

> Mennyire egyszerű forkolni egy létező repot (git: egyetlen parancs)?
Erről nem tudok nyilatkozni. Írtam, milyen esetben használom az svn-t, ott nincs igazán forkolás.

> Mennyire egyszerű szinkronizálni két repot (git: egyetlen parancs, na jó lehet kettő ha még nem tudtak egymásról)?
Ez az svn esetén értelmezhetetlen kérdés, hiszen az egész központosított. Van a központi tároló, és vannak a checkout-ok. Minden commit az egyetlen központi tárolóba megy. Más (nem jobb, nem rosszabb) elv.

> A többire nem is válaszoltál.
Igen, mert azokra nem tudok válaszolni - nem azt jelenti, hogy nem lehetséges a megoldás, csak nekem a one-man-show projekteimben ilyen igények nem merülnek fel.

> két rendszer annyira különböző, hogy kb annyi értelme van őket összehasonlítani
Pontosan, én is így gondolom. Adott célra adott eszközt.

> igenis *van* amivel a git és a DVCS többet nyújt, a többlet nagyonis *jelentős* és igenis van erre valós igény
Ezt nem is vitattam. Viszont ha nekem nincs igényem DVCS-re, akkor miért erőltessem? :) Ahogy írtam, az én gondolkodásomnak valahogy jobban megfelel az SVN.

>> semmibe se kerül létrehozni egy új branchot és eldobni egy fél óra/nap/hónap után ha mégse jön be
> SVN alatt is.

SVN alatt még mindig az a branchelés, hogy lemásolom a teljes `trunk`-ot (vagy amit akarok) a `branches` alá? Azért egy komolyabb projektnél ezek után csak az IDE-t tutujgatnám fél órát, hogy úgy legyen beállítva, ahogy én akarom. (én nem vagyok a híve a `.idea` mappa verziókezelésének)

SVN alatt sosem volt ez a branchelés. Ezért mondom azt, hogy fél- (vagy negyed-) információk alapján sarkos véleményt mondani kicsit necces.

Lehet azt mondani, hogy "bár igazi indokom nincsen rá, de nekem sokkal szebb a git cli színes outputja, és jobban elvarázsol, mint a karácsonyfa esti ragyogása". Lehetne ezzel vitatkozni...?

Nem.
"Subversion does not have special commands for branching or tagging, but uses so-called “cheap copies” instead. Cheap copies are similar to hard links in Unix, which means that instead of making a complete copy in the repository, an internal link is created, pointing to a specific tree/revision. As a result branches and tags are very quick to create, and take up almost no extra space in the repository."

engem a google://svn branches ide vitt: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html

Namost, ha jól értem:
- sikerült megoldani, hogy a _szerveren_ ne legyen ez sok hely (ami alapvetően egy olcsó erőforrás)
- de a gépemre húzzam ki újra (ami még mindig olcsó, de talán egy kicsit nemannyira) + idő
- és újra konfigjam rá az IDE-t, ami már kurva drága, de legalább sokáig tart. És minden új branch kezdésekor.

Ebből az első egyáltalán nem fáj (ahol nincs pénz diszkre, oda nemmennék, ty!), a második még mindig nem annyira, a harmadik viszont eléggé.

> de a gépemre húzzam ki újra (ami még mindig olcsó, de talán egy kicsit nemannyira) + idő
Nem egészen értem, mire gondolsz, de nem kell, hogy az összes tízmillió branch a gépeden legyen. Az svn switch segítségével viszonylag gyorsan lehet ugrálni a branch-ek között. Ha meg legalább öt branch-nek a gépeden kell, hogy legyen, akkor a git esetében is valahogy le kell azokat szedni.

> és újra konfigjam rá az IDE-t
Nehéz konfigolni az IDE-t => az svn rossz.

Miért kéne IDE-t konfigurálni? svn switch és csá, máris másik branchen van a working copy-d.
"Be sure to read the section called “Traversing Branches” later in this chapter: the svn switch command is an alternative way of creating a working copy of a branch."
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.switchwc.html

A workflow a következő:
1. A szerveren létrehozod a branchet. Tök olcsó művelet.
2. A kliensen svn switch, és máris rajta vagy azon a branchen. Nincs semmiféle IDE-konfigurálgatás.

De hát ismerni kéne az eszközöket.

Mi környezeti+feature branchinget használunk. Szerettem volna commit hookokat is üzembe állítani, de nem volt rá igény a PM/PO-nál. Ez szvsz nem faék, bár ahogy vesszük... a kollégák elég szimpla dolgokat csinálnak anélkül, hogy attól kéne tartani, hogy összebarmolnák/átírnák a már meglévő history-t.

Az általad felsoroltak egy része félrevezető, vagy szubjektív.
- Kétségtelen, hogy SVN local repo-ból megosztani nem egy parancs, de nem kell hozzá diploma.
- Nem kénytelen mindenki használni azt a branchet, amit én és pár kollégám használunk, ellenben egyből látják a változásokat, mert nem felejtem el push-olni commit után, és minden babrálás nélkül bárki át tudja venni tőlem a melót, és még hétvégén sem kell rámtelefonálnia.
- Branching: hacsak nem potato szervered van, nem tudom mi a problémád. Nem kell külön megosztanod a branchedet másokkal, és tartanod szinkronban.
- A ménkű beüt néha. Bár a mostani cégemnél 12 éve dolgozom, erre egyszer sem volt példa, nem oldott volna meg semmit, ha a magam kis repository-ját tutujgatom. Szerintem
- Bár nem vagyok híve a dolognak, jelenleg bazinagy repo-kat használunk elég sok projektre. Amin most dolgozok ott 150000-felé közelít a revision number, de nemrég néztem az apache foundation repository-ját, ott 1.8 millió fölött járnak, működik, gyors, és van kapcsolat a projektek között is.
Ami nekem baromira hiányzik a git repo esetében, az a hierarchikus felépítés. Van párezer branched, és találd meg amelyiket keresed, gúdlákk, pláne ha még le sem szedted a központi repoból, amit a kollégád elfelejtett megosztani. A git esetében a strukturált branchek használata nem létező dolog, azokon keresztül tökéletesen kezelhető az általad vázolt probléma is.

A git CLI output meg katasztrófa, bár a paraméterei is.

Mindegy, örülök, hogy neked bejön ez a trend, de nekem kissé gagyinak tűnik a hozzá társuló érvrendszer és felfogás.

Egyetértünk abban, hogy nem értünk egyet. Nekem az SVN-hez ragaszkodó érvek és felfogás tűnik gagyinak. De ez nem gond, elég nagy a világ, elfér mind a kettő. Mi ketten szerintem soha nem fogunk egy csapatban dolgozni szóval mi is elférünk a világon egymás mellett. :D
--
:wq

> Persze az SVN-nel csak két parancsot kell megtanulni és instans produktív vagy

nahát meg is válaszoltad a saját kérdésed :)

tbh a valóságban nincs arra igény, hogy "akármilyen" workflow menjen: van 1 db workflow, amihez szökőévente egyszer kell hozzányúlni, és (ideális esetben) ehhez választanak egy toolt

az általam látott fejlesztési projektek nagy része simán elfért SVN-ben, így aztán teljesen felesleges lett volna a programozókat (csillagászati óradíjak kifizetése mellett) lökdösni a meredek tanulási görbe mentén

Én nem azokról az esetekről beszélek amikor a munkamenethez "szökőévente egyszer kell hozzányúlni" hanem ami szervesen része. Nekem olyasmik hiányoznak az SVN-ből amik a *mindennapi* munkamenetem szerves részét képezik.

>az általam látott fejlesztési projektek nagy része simán elfért SVN-ben, így aztán teljesen felesleges lett volna a programozókat (csillagászati óradíjak kifizetése mellett) lökdösni a meredek tanulási görbe mentén
Ezzel egyetértek de nem is szeretnék egy ilyen fejlesztési csapatnak a részese lenni az biztos. :D Megvannak a sztereotípáim (múltbéli tapasztalatok alapján) arról, hogy hogy megy a munka az ilyen csapatokban. Nem azt mondom, hogy mindenhol így van de egy intő jel számomra.
--
:wq

De ezzel te a ritkább projektekbe tartozol. Egy átlagos embernek a gitről elég azt tudnia, hogy checkout <branch>, pull [--rebase], commit, push origin master. Ha gerritben tárolt patchsethez akarsz új verziót beküldeni, akkor ez kiegészül két másik paranccsal, nagyon elkúrni meg nem tudod, mert mindig ott a git reset. :D
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( raavi | 2017. 12. 19., k – 12:29 )

Rational Team Concert - Lemaradt a listából.

Persze, mert nem hallott róla senki. És igazából ez a legnagyobb baj vele, elég kevés dolog támogatja. (Na meg az, hogy closed source, az IBM fejleszti, és akad benne 1-2 idegesítő bug.) Pedig amúgy egész érdekes a modellje, véleményem szerint egy enterprise fejlesztéshez jobban is illik mint a git.
Amúgy pár éve szerepelt a szavazásban, összesen kapott vagy 3 szavazatot, de lehet, hogy még ezzel is sokat mondok.

( deje | 2017. 12. 19., k – 21:23 )

Akkor ismét ellövöm, mint minden évben: jó ez a git, egymilliárd légy nem tévedhet...

Az eddigi tapasztalataim szerint azért a git az elterjedt, mert erről hallottak a népek, a mercurial-ról meg nem.
Sokat használtam mindkettőt, és a gitet a mai napig útálom. Nem érek rá megtanulni, linuxra nincs normális gui, stb. Mercurial ezzel szemben kézreáll, jó a gui és fut mindenen. Bármit kell csinálni, mercuriallal könnyebb. Ha meg a parancssor kell, az is van. Gittel a toolok bénasága miatt rendszeresen futok bele valami szarba, a másinkál ilyen nincs.
Már ott tartok, hogy a céges git repókat is mercuriallal fogom használni (hg-git extension), miután alaposan leteszteltem.

Nem mindenkinek igénye a GUI van aki ráér megtanulni mert megéri neki a nagyobb flexibilitás. Ilyen alapon a C++-t is ki kéne hajítani mert bonyolult, nincs rendes build-system és különben is Javaban mindent könnyebb megoldani.
Én most nem a mercurial-t akarom blamálni mert nem ismerem de szerintem nem csak azért elterjedt a git mert mindenki arról hallott. A git tényleg jó. Persze biztos van egy csomó cég ami nem azért használja mert felmérték, hogy ez a legjobb eszköz a célra, hanem csak mert "cool".
--
:wq

Az első résszel egyetértek. A második résszel is, azonban szerintem sokkal nagyobb a divat-hatás, mint gondolod. Eddig akárkit kérdeztem, hogy miért a gitet választotta, vagy az volt a válasz, hogy jobb, mint az svn, vagy hogy mert mindenki ezt használja. Senkitől bem hallottam, hogy akár csak megnézték volna a mercurial-t, nemhogy összehasonlították volna.

( GerzSonka | 2017. 12. 20., sze – 22:13 )

Használtam ClearCase-t. Mégis mi az isten baja van annak, aki rányomott? :P
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( asch v | 2018. 01. 09., k – 10:57 )

Arra is git-et használok, amire nem való :-).

Csináltunk vele verziózott Internet mirrort: https://github.com/qgears/repocache

Csináltam olyan adatbázisra épülő GUI-t is, amit offline is lehet használni, és amikor online megy a kliens, akkor automatikusan merge-eli be-ki az adatbázist. Úgy van kitalálva, hogy soha nincsenek konfliktusok, ha egyszerre szerkesztenek, akkor duplikálás történik, amit az egységsugarú user is tud kezelni utólag a GUI-n ha szükséges (például törli a nemtetsző változatot).

( tselmeci | 2018. 01. 09., k – 12:18 )

Az én kedvencem a fossil, mert kicsi, kompakt és majdnem pont azt tudja, amire nekem általában szükségem van. Munkahelyen gitet használunk, de nem szeretem.

( crown v | 2018. 01. 09., k – 16:44 )

perforce?! teatyauristen. erre ki szavazott?!