HOVD 2018 - Kedvenc verziókezelő rendszer

HUP

bazaar
1% (4 szavazat)
clearcase
1% (4 szavazat)
cvs
2% (10 szavazat)
git
82% (474 szavazat)
gnu arch
0% (2 szavazat)
mercurial
2% (12 szavazat)
perforce
0% (2 szavazat)
rcs
0% (2 szavazat)
subversion
11% (63 szavazat)
team foundation server
1% (5 szavazat)
Összes szavazat: 578

( joco01 v | 2018. 12. 28., p – 13:00 )

Kb. mindig az, amivel épp dolgozom. Most épp Mercurial. A git-hez képest nekem kicsit jobban érthető.

Ugye jól gondolom, hogy az egymással összehasonlított github és bitbucket most már nem különböző verziókezelő rendszeren fut, hanem mindkettő alatt git van?

A másik: feltételezem, hogy amit nagy különbségnek ír, hogy külön parancs van különböző funkciókra, azt alias-okkal git felett is meg lehetne oldani. Vagy nem ilyen egyszerű?

(Egyikkel sincs tapasztalatom)

BitBucketen hg és git repót is létre lehet hozni, GitHubon erre nincs lehetőség.

De, lehet aliasokat definiálni, kapcsolókkal és minden egyébbel együtt, tehát elvileg ezek megvalósíthatóak. Viszont ez nem a végfelhasználó dolga lenne, hanem a fejlesztőké. A problémát én abban látom, hogy a git kliens nem nyújt absztrakciókat ezekre a gyakran használt műveletekre, hanem kiajánlja a belső adatstruktúráin végrehajtható műveleteit, ezért a felhasználónak is ismernie kell a belső felépítését hogy hatékonyan tudjon dolgozni vele.

"A problémát én abban látom, hogy a git kliens nem nyújt absztrakciókat ezekre a gyakran használt műveletekre"

Ó, amikor ilyeneket olvasok az interneten, mindig eszembe jut, hogy miért próbálom elkerülni jó messzire a CLI-s git klienst és, hogy mekkora egy rák használni.

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

"hogy mekkora egy rák használni"

Én 7 éve napi szinten git cli-zek. Nem állítom hogy a világ legegyszerűbb dolga használni, de elég hamar megtanultam és nekem mindenfajta grafikus eszköz büdös erre célra.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

git checkout

Zűrös dolog a checkout és reset. A funkcióikat tekintve legalább felerészben átfedés van közöttük. Például mindkettő változtatja a HEAD-et, mindkettő változtatja az indexet, változtatja a wt-t. Kapcsolók sokaságával lehet szabályozni, mikor mely fájlokra terjedjen ki a hatásuk, melyekre ne. Jól össze lehet keverni. De nem csak a resettel van átfedésben, hanem a branch-csel is, meg még merge-t is végez, meg még ki tudja mit. Őszintén szólva az alkalmazástervezés csődjének látszik.

--
ulysses.co.hu

A reset alapfunkciója (értelme), hogy a HEAD-et a megadott commmithoz viszi. Ha nincs megadva commit, akkor annak a defaultja maga a HEAD, tehát ilyenkor a HEAD valóban nem változik. Ahogy a+0==a.

Az egyszerű eseteket meg lehet jegyezni, vagy tudja őket a frontend. Komplikáltabb eseteknél azonban még azt sem lehet kitalálni, hogy melyik parancs 500-600 soros man-jában kell kezdeni a kutatást.
--
ulysses.co.hu

+1

Bár ha gittel kell dolgoznom, akkor is a Mercurial inkább, csak sajnos (?) az előbbi lett a de-facto standard a nyílt forrású világban. A TortoiseHg egy tökéletesen használható grafikus frontend a Mercurial-hoz, git-hez még nem láttam hasonlót, pedig próbáltam sokat (Tower, Github for Desktop, SourceTree, Sublime Merge, GitKraken - talán még ez utóbbi a leghasználhatóbb).

A Mercurial-ban a branch-ek ténylegesen létező entitások, nem csak egy pointer valahol a gráfban, ami automatikusan mozog commit esetén. Emiatt a repo klónjai is ugyanazokat a branch-eket tartalmazzák, nincs szükség remote tracking branch-re. Minden commit része maga a branch is, ez hasznos tud lenni, amikor évekkel ezelőtt szarrá branch-elt history-t kell átnézni és értelmezni. Ráadásul pont ezért branch nem törölhető utólag (lezárni lehet őket, és ezután nem jelennek meg a head-ek között), így ez az információ nem tud elveszni-módosulni.

Nekem az a tapasztalatom, hogy mercurial-al könnyebb sok branch-es fejlesztést menedzselni, kevesebb a probléma a fejlesztőkkel.

A git-féle branch kezelés létezik a mercurial-ban is, bookmark-nak hívják, és pont ugyanazt tudja.

( Joejszaka v | 2019. 01. 01., k – 17:49 )

Mondjuk az fura, hogy 8 ember 2018-ban a CVS-re szavaz, és 33 a subversion-re... :)

"CVS-nek van bármi előnye SVN-hez képest? Bármi, ami miatt jobban lehet szeretni?"

Miért ne lehetne valakinek az a kedvence? :D

"Van esetleg olyan platform, ahol CVS van de SVN nincs?"

Vannak olyan legacy cuccok, amelyek abban vannak, de nincs értelme migrálni.

--
https://iotguru.live

( zeller | 2019. 01. 02., sze – 14:21 )

Van valami fsvs-hez hasonló újabb eszköz? Mert igény az volna rá... :-D

( nevergone v | 2019. 01. 12., szo – 19:48 )

Aki Bazaar-t használ, az miért? Én is azzal kezdtem anno a komolyabb verziókezelést, de gyakorlatilag minden manapság használt VCS elhaladt mellette, miközben a fejlesztése szinte nem is halad.
http://bazaar.canonical.com/en/

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

( NewC | 2019. 01. 24., cs – 09:29 )

git is awesome
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-