Használjunk git-et a konfigfájljaink kezelésére!

Szerszám

A Linux.com-on Joe 'Zonker' Brockmeier arról ír cikkében, hogy milyen előnyei vannak annak, ha konfigfájljainkat verziókezelő rendszerrel, azon belül is git-tel kezeljük. A cikk itt olvasható.

( Cajga | 2012. 03. 11., v – 19:12 )

Valahogy elfelejti megemliteni, hogy ez a megoldas miert jobb mint a configuracio management system-ek amiket erre talaltak ki... (puppet, cfengine etc.)

Szerk.: Es persze ugy ertem, hogy puppet+git/svn/whatever

+1, ahogy olvastam a cikket ez jutott eszembe, hogy a git "fő" három előnye, miszerint elosztott, meg hűdejó merge képességekkel bír, és milyen kényelmesen lehet vele pull requesteket kezelni, egy hangyányit sem érvényesül, helyette csak a lokális repositori 3 részből áll, és 8 parancs kell a megtanulásához. Ellenebn egy svn file:// protokollal 3 paranccsl bőven elvezérelhető, lokális, és mivel párhuzamosan kevés a commit, annyi conflictot az svn "gyenge" merge képességgel is lekezel. Elismerem a git fennhatóságát számos területen, de pont itt ágyúval verébre.

-
Weak és Soft referenciák a Javaban

Persze, a gitet is lehet úgy használni, mint az svn-t, akkor csak annyi a különbség, hogy add, commit, push kell a sima commit helyett. De akkor emiatt felesleges volt az elosztott verziókezelő. Erre a feladatra tökéletes az svn egyszerű működése, felesleges az elosztott verziókezelés, és ez sok feladatra igaz. Ezért használnak még a mai napig ilyen verziókezelőket (no meg mert az iparnak nagy a tehetetlensége).
----
Hülye pelikán

svn architekt: working copy -> repository
svn folyamat: checkout -> add -> commit

git architekt: workspace -> index -> local repository -> remote repository
git folyamat: fetch -> checkout -> add -> commit -> push (mivel nem vagyok expert lehet, hogy itt-ott lehet belőle lecsípni)

Nem látom értelmét a folyamatot bonyolítani bizonyos developer szám fölött, vagy nem opensource projekt esetén, nem nyújt semmi olyat, amit a faék svn pl nem tud. Ne felejtsük el, hogy a topic hogyan verziózzuk a konfigfájljainkat, ahol ritka a párhozamos változtatás, 1-2 user használja csak, azok is ritkán egyszerre. Persze ha valaki csak ebben jártas hülyeség lenne megtanulni valami mást, ettől függetlenül van egyszerűbb módszer is.
-
Weak és Soft referenciák a Javaban

Így is lehet gitet használni, de ez az svn-es munkafolyamat rákényszerítése a git-re. A lényeg az, hogy nem pusholgatsz folyton a közösnek kinevezett repoba, hanem csak mondjuk a nap végén. Viszont nap közben a saját repodba annyit és úgy commitolgatsz, ahogy kényelmes. Aztán a végén feltolod a közösbe. És igen, a remek merge miatt ez közel sem jár annyi fejfájással, mint svn esetében. Az én workflow-m így néz ki:

pull->stage/add->commit
Majd a nap végén push (esetleg némi rebase-es takarítás). Ez már azért nem hangzik annyira másmilyennek.

Ezen kívül rendszerint feature brancheken dolgozom, amiket merge-ölök vagy rebase-elek naponta többször.

Könyörgöm, én ezt értem, de jelen esetben szaros, lineárisan szerkesztett, ritkán változó konfigfájlokról beszélünk, és pont ezt magyarázom, hogy nincs szükség "pull->stage/add->commit -> Majd a nap végén push" workflowra, mert ebből a szemszögből ez egy túlbonyolított megoldás, és sokkal egyszerűbb eszközökkel is elérhető ugyanez a funkcionalitás.
-
Weak és Soft referenciák a Javaban

Nyilván, ízlések és pofonok. Szerintem azért érdemes erre a feladatra gitet használni SVN-nel szemben, mert nem kell hozzá szerver. Csak csinálsz egy repot és kész is vagy, minden localban megy.

Bár tudom, sokaknak nem jön be a git, többnyire azt látom mögötte, hogy nem igazán értik, miről szól az elosztott verziókezelés. Ha kísérletezős kedvedben vagy és szeretnél valami nem-gitet megtanulni, nézd meg ezt a tutorialt: http://hginit.com/

Lehet lenne ertelme elolvasni a cikket mielott megmondod a tutit.
Eloszor is kezdokhoz szolt. Masodszor a home alatt levo sajat configokat rendezgeti. Erre a puppet vagy a cfengine akkora overkill hogy...

De ha igazan erdekel en megmondom miert jobb ez a megoldas mint a config management rendszerek: mert egyszeru.

Valoban nem olvastam el a teljes cikket csak a Getting Started elotti reszt. Ennyi eleg volt, utana abbahagytam mert baromsagnak tartom. (Mielott postoltam a hsz-emet rakerestem a puppet es a cfengine szora, hogy ne irjak valotlant)

"Eloszor is kezdokhoz szolt."
Pont ez a baj az ilyen cikkekkel, hogy tul sok kezdohoz jut majd el es meg sem emliti a valoban erre a celra hasznalando megoldasokat! Bemutat egy megoldast ami mukodik, hasznalhato bizonyos feltetelek kozott de messze nem optimalis. Kinevel majd sok pistiket (es ebben az esetben nem ok lesznek a hibasak mert a linux.com-on olvastak es eselyt sem kaptak megtudni, hogy lenne jobb megoldas).

"Masodszor a home alatt levo sajat configokat rendezgeti."
Ha tenyleg csak a /home-ra korlatozodik, akkor hatalmas segitseg egy szerver konfiguralasanal. Implementalhat egy masik megoldast a tobbi config fajlhoz, vagy azok mar nem is fontosak?

"Typically I use Dropbox to sync my files for work, but Dropbox isn't a good solution for files under /etc or .config type files under your home directory."
Engem az a /etc zavart meg ebben a mondatban, de azon se lepodnek meg ha a /etc lenne a home-ja.

Attol hogy nem neked szol meg nem feltetlenul baromsag. Ha az ember sokat mozog kulonbozo gepek kozott eleg kenyelmes egy repobol lehuzni a tipikus configokat (vim, bash stb). (en is reszben ezt csinalom mar regota)

puppet/cfengine/chef stb. teljesen mas vilag. Iszonyat nagy rendszer mindegyik, rengeteg energia elindulni veluk, csak akkor eri meg ha sok gepre (puppet: nehany 10, chef nehany 100, cfengine-t nem hasznaltam) kell configot pakolni.

"Ha tenyleg csak a /home-ra korlatozodik, akkor hatalmas segitseg egy szerver konfiguralasanal. Implementalhat egy masik megoldast a tobbi config fajlhoz, vagy azok mar nem is fontosak?"

Ezt a mondatodat nem ertem. Ha en installalok egy szervert akkor az elso dolgom hogy bash/vim configot reszelek mert ezek nelkul sokkal tovabb tart minden mas.

Szerintem félre érted. Esetemben ez egy tök jó megoldás, mert minden szerverünkön van git, viszont nem én vagyok az admin minden szerveren. így most tudom hordozni a kis hülye bash scriptjeimet az acc-ok között.. Eddig volt rá egy "movein" scriptem, amivel időközönként "beköltöztem."

"Kinevel majd sok pistiket" - Mert azok a linux.com-on nevelődnek :-)

Nem olvastam el a cikket, viszont kapasbol eszembe jut 1 alapveto kulonbseg. Ezt a szerverrol inditja (akar ott is tarolja), mig a puppet is tarsait jellemzoen egy kozponti helyrol igazgatja.
Kb. annyi a kulonbseg, mint a pull es a push backup kozott. Persze van meg az overkill, meg a egyszeruseg vs. bonyolultsag stb. De a lenyeg szerintem ezen van.

Nem jobb, hanem mas.
Sot, akar masik, egymas mellett a ketto. Persze ez mar talan eroltetett.

udv,
tamas

puppet es baratai nem zarjak ki a verziozast, igazabol ajanlott a fileok valami repoban tartasa.

Aki valaha probalt mar puppet-et vagy chef-et hasznalni az pontosan tudja hogy nincs az az atyauristen hogy egy vim config miatt osszerakjon egy teljes infrastukturat alajuk. Finoman szova is komplex rendszerekrol beszelunk amiknek illik legalabb egy dedikalt szervert adni. Igazad van, mas, nagyon mas a ket dolog.

( Replaced | 2012. 03. 11., v – 19:42 )

lol, linux

--
NetBSD - Simplicity is prerequisite for reliability

( bastya_elvtars | 2012. 03. 11., v – 19:58 )

cp és diff parancsokról hallott-e? :D
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

( Erendis42 | 2012. 03. 11., v – 20:21 )

emlékszem, valamelyik előadáson mondta valaki hogy egy író arra használt ilyen verziókezelőt, hogy az épp aktuális műve fejezeteiben a változásokat tudja vele követni. (GOTO kalapács :))

"Mutasd meg egy zsebtolvajnak Buddhát és csak zsebeket fog látni."

( uzsolt v | 2012. 03. 11., v – 21:58 )

Szerintem egy rdiff-backup erre sokkal jobb módszer (cron-nal beállítva X időközönként). Egyrészt sokkal automatikusabb, másrészt (magamból kiindulva) úgyse commit-tol mindig minden változtatást - siet, elfelejti, egy idő után meg elege van, hogy mindig changelog-ot írjon.
Az rdiff-backup-pal pedig az inkrementális (vagy hogy hívják) backup miatt régebbi verziók is elérhetőek. Sőt, az rdiff-backup-fs segítségével még bűvös parancsokat (revert, stb.) se kell bemagolni, hogy a különböző verziók között bogarásszon az ember.

Igen. Meg nem.
Igen, cron-ba azt rak bele az ember, amit akar.
Viszont ha a git cron-ba kerül, nemigen lesznek "értelmes" changelog-ok (gondolom, a git nem annyira értelmes, hogy egy-két változtatásból intelligensen kitalálja, hogy a commitlog az az "Egy kicsit megpróbálom máshogy" :)).

Biztosan jó ez a git, de nem látom, hogy ugyanarra a dologra miért kellene két programot használnom, két szkriptet "karbantartanom". Ui. az rdiff-backup nálam azt csinálja, ami a neve is: backup-ot. Backup-ot csinálok a LaTeX-fájljaimról, katalógusokról, stb., és többek között a "fontos" konfigfájlokról is.
Egy szkript - a hiba legfeljebb egy helyen van :)

De mondj egy olyan dolgot, ami miatt a git jobb (lenne), mint a mostani megoldásom, és ígérem, megcsinálom.
Csak egy példa: egyszer egy konfigban egy bizonyos részletet kerestem, ami közben "eltűnt" (nem volt rá szükségem). Mennyire egyszerű ez git-ben, hogy mittomén az echo "helloworld"-öt tartalmazó verziót megtaláljam? rdiff-backup-fs: egyszerű grep -r, és jó napot.

Én nem mondom, hogy jobb, de nem is rosszabb (changelogot nem kapsz így se, úgy se a cron által futtatva, viszont mondjuk ha manuálisan commitolsz, akkor de). De teljesen igazad van, fölösleges a működő megoldásodat lecserélni, erről nem is akarlak meggyőzni :)

Git-ben így lehet keresni egyébként a korábbi verziók között: git log -g -Svalami vagy -Gregex

( Webappz | 2012. 03. 12., h – 09:55 )

Elöljáróban, nem olvastam végig a cikket, csak éppen belenéztem.
Nekem elsőre az etckeeper jutott az eszembe, ami tud a gittel és más elosztott verziókezelővel együttműködni, bár alapvetően "csak" helyileg tárolja az adatokat.
Van a yumhoz pluginja, így a csomagok karbantartásával kapcsolatos, /etc/* érintő változtatásokról is kapunk információt. Szerintem hasznos.

Webappz - http://webappz.hu/

( zsver v | 2012. 03. 13., k – 09:44 )

De most komolyan...
Egy beállitott desktop rendszeren ti milyen gyakran változtattok bármilyen konfig file-t? Tényleg olyan sűrűn, hogy ahhoz verziokezelő rendszer kell?
Egy uj rendszerre való átálláskor pedig tényleg git telepitése, stb. kell ahhoz, hogy átmásold az a _pár_ darab olyan konfig file-t amihez valóban hozzá lett nyúlva kézzel?

Nyilván attól függ milyen desktop és mire használod. XMonad/StumpWM, emacs/vim, Xresources, conkerorrc, van egy csomó alapvető program amit évek alatt jól személyre szabtam. Ezeket a configokat viszem melóhelyről melóhelyre, otthoni gép upgrade-elésekor. Githubra/BitBucketre/stb. felrakja az ember és leülhet bármilyen linux elé hamar otthonossá tudja varázsolni.
Épp a napokban döglött meg a merevlemezem, épp közeledett a határidő a munkámban, jól jött hogy csak feldobtam az új lemezre egy linuxot, git pull, és mehetett tovább a munka.