ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
HOVD 2018 - Kedvenc verziókezelő rendszerbazaar 1% (4 szavazat) clearcase 1% (4 szavazat) cvs 2% (10 szavazat) git 82% (426 szavazat) gnu arch 0% (2 szavazat) mercurial 2% (11 szavazat) perforce 0% (2 szavazat) rcs 0% (2 szavazat) subversion 11% (57 szavazat) team foundation server 1% (4 szavazat) Összes szavazat: 522
»
|
KeresésNavigációBelépésÚj Világ NKft. állásajánlatokÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
Kb. mindig az, amivel épp dolgozom. Most épp Mercurial. A git-hez képest nekem kicsit jobban érthető.
Ugyan már, a git könnyen érthető, csak el kell olvasni a manualt: https://git-man-page-generator.lokaltog.net
hehe
http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
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™
Úgyis az a vége. Sok GUIs git kliensnél is van egy pont amikor, CLI elő, és hajrá. Mondjuk persze a munka 99%ához elég a GUI.
Azért meglehetősen ritkán jön el az a pont. Csak az a kár, hogy az igazán jó GUI kliensekből nincs Linuxos verzió.
SmartGit elég jó, csak fizetős.
---------------------------
Oszt jónapot!
GitExtensions
"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
Jó, nem mondom, hogy ne lehetne megszokni, de a fene se akarja, ha van jobb és átláthatóbb megoldás.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
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
Egyetértek, rosszul lett megtervezve, de elég egyszer megtanulni és megszokni.
--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene
Meg lehet szokni azt is, hogy mindig mellészarsz és beleteszed.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
:-D Ezt lopom :-)
Ha meg lenne helyette legalább nyolc dedikált parancs, akkor meg az lenne baj, hogy a fene se jegyez meg ennyit.
A git reset nem feltétlenül változtatja a HEAD-et.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
A checkout se feltétlenül, de ne vesszünk el a részletekben :)
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).
Porbald ki a GitExtensions-t.
+1
gitk
Nem kicsit. Nagyon.
Érdekelne, hogy mi az, ami nem érthető a Gitben, de érthető a Mercurialban és az átlag felhasználó szokta használni?
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Branchek. Érthető persze a git hozzáállása is, de a hg intuitívabb.
----
India delenda est.
Hülye pelikán
Kifejtenéd bővebben nekem? Nem használtam még Mercurialt, azért kérdezem.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
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.
> évekkel ezelőtt szarrá branch-elt history
hát, ez inkább a dev workflow problémája, bármilyen eszközzel vagy módszertannal lehet káoszt csinálni :)
Sajnos igen, de nincs mindig lehetőség jól csinálni, főleg legacy rendszereknél, ahol az ügyfél is kellőképpen nehezíti a dolgot.
Közben ez jött szembe:
https://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Mondjuk az fura, hogy 8 ember 2018-ban a CVS-re szavaz, és 33 a subversion-re... :)
Hát én is fogom a fejem miben évben látva hogy emberek a ClearCase-re nyomnak ;)
+1 :)
(marmint neked, nem nekik! :) )
Na most sokan Gitet használnak, de kb. úgy, mintha SVN lenne, szóval... :)
Egyébként megvan még az SVN-nek is a helye, bár tény, hogy szoftvert már én sem kezdek el SVN-ben.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mindegyiknek megvan a helye... :)
--
https://iotguru.live
CVS-nek van bármi előnye SVN-hez képest?
Bármi, ami miatt jobban lehet szeretni?
Van esetleg olyan platform, ahol CVS van de SVN nincs?
"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
2019-ben eddig 1 ill. 11 :)
Van valami fsvs-hez hasonló újabb eszköz? Mert igény az volna rá... :-D
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…