"A FreeBSD-nek szüksége van a Git-re, hogy biztosítani tudja a repo integritását"

FreeBSD

Többek közt a freebsd-security listára is beküldésre került az a levél, amelynek szerzője szerint a FreeBSD projektnek git-re kellene váltania, hogy biztosítani tudja forráskódtárolójának integritását. A "grarpamp" néven vitát indító listatag szerint minden nagyobb nyílt forrású projektnek szüksége van egy olyan tárolóra, amely nyomon követhető, ellenőrizhető és beépített kriptografikus authentikációval rendelkezik.

Ugyan a levelet beküldő azzal kezdte, hogy a témaindítása nem a nemrég bekövetkezett biztonsági incidensről szól, levele azonban biztonsággal összefüggő kérdéseket feszeget.

Grarpamp a FreeBSD projekt git-re váltásában látná a megoldást. Ahogy az lenni szokott, az ötletfelvetésnek lettek pártolói és ellenzői is. Az ellenzők közt volt olyan, aki azzal érvelt, hogy a FreeBSD projektnek van (SVN-ből exportált) publikus git tárolója, aki azt szeretné használni, használhatja. Valaki megjegyezte, hogy valóban van git repo, de azzal problémák vannak.
Volt aki szerint a git nem felelne meg a bejáratott munkafolyamatokhoz. Más szerint megfelelne. Volt, aki szerint a git órási visszalépés lenne. A szálban természetesen megjelentek a BSDL-zelóták is, akik szerint a git-tel licencbeli problémák vannak.

A szálból a vita mellett azért értelmes infók is kinyerhetők a FreeBSD fejlesztését szorosan nem követők számára. Például az, hogy ugyan létezik jelenleg még git, SVN és CVS repó is, de az igazi repó az SVN. A CVS az SVN-ből exportált, a git szintén. A CVS meg fog szűnni.

Továbbá, az üzemeltetők minden igyekezete ellenére csak az SVN tekinthető minden időpillanatban naprakésznek. Akárhogy is igyekeznek, a git és CVS repók naprakészen tartásával, az nem megy mindig, minden körülmények közt.

A szál itt kezdődik.

( Replaced | 2012. 11. 20., k – 09:32 )

git es repo integritas egy mondatban? :D
troll level ez, semmi mas

--
NetBSD - Simplicity is prerequisite for reliability

te már bizonyítottan troll vagy, nem érdekel mit írsz. Egyébként én személy szerint nem használom a git-tet, csak, mint felhasználó. Az általánosítás, meg az 1 hiba alapján minden szar, kicsit véresszájú megközelítése nem tetszett. Az ilyen véresszájú dolog a gyengék fegyvere. Hiányzik az ilyen dolgokból a stílus, ez a stílus a móriczi ösztönlény, és a kádári kisember fröcsögő gyűlölete, az jön csak le ebből. Ezért tart itt az ország.

Én ismerek olyan céget idehaza, ahol kb. 20 dolgoznak és CVS-t használnak még mindig. Igaz csak naponta egyszer commitolnak, a munkanap végén. Na és? Nem normálisak mindenhol vannak. :)

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

Bár még sosem cherry pickeltem, de a kezdeti szkeptikusság után ("minek egy új, bonyolultabb verziókezelő, amikor az svn mindent tud" (ami amúgy teljesen ugyanaz a gondolatsor volt, amit a winampról vittem, amíg nem találkoztam a foobarral)) teljesen beleszerettem. Ez már egész úgy néz ki, ahogy egy verziókezelőnek ki kell néznie. Mondjuk lehet azért gondolok rá ilyen pozitívan, mert amúgy emellett kellett elkezdenem a ClearCase használatát is, és hát éles a kontraszt. Az IBM-nél miért nem tudnak szoftvert fejleszteni? Az egész Rationale úgy szar ahogy van.
----
India delenda est.
Hülye pelikán

( tetra | 2012. 11. 20., k – 10:42 )

A szakmai részéhez nem is kívánok hozzászólni, mert vallási vita (ez meg oximoron), de úgy tudtam a BSD fejlesztés egyik alapköve a licensz. Na most ha a git licensze nem megfelelő, akkor egyértelmű a dolog (feltéve, hogy az Subversioné jobb).
----
India delenda est.
Hülye pelikán

Az alaprendszerben levő dolgok licencén szoktak szűkölni. Az SVN tudtommal nincs az alaprendszerben. Ennyi erővel semmilyen nem BSDL-es szoftvert se használjanak.

Jelzem, a DragonFly projekt git-et használ és nem lett tőle problémájuk. A FreeBSD-t BSD-s körökben eddig is Free???BSD-nek hívták. Szóval ez nem hiszem, hogy érv akkora érv lenne.

--
trey @ gépház

A mercurial miert nem merul fel soha sem mint svn alternativa? Mi git-et hasznalunk a cegnel es bar ketsegtelenul egy nagyon fejlet scm de mondjuk intuitivnak szerintem egy csoppet sem nevezheto. Valaki hasznalt mar mercurialt "ipari" kornyezetben es meg tudna mondani, hogy miert jo /nem jo?

"A mercurial miert nem merul fel soha sem mint svn alternativa?"

Odáig jutottak, hogy az egyik okos szerint a Mercurial licence BSDL, a másik szerint LGP míg a harmadik szerint GPLv2.

http://marc.info/?l=freebsd-questions&m=135336052019813&w=2
http://marc.info/?l=freebsd-hackers&m=135336050819457&w=2

--
trey @ gépház

Ha már alternatíva, Veracity, szép nagy összehasonlító táblázattal: http://veracity-scm.com/

Ezt http://www.ericsink.com/vcbe/ meg lehetett ingyen rendelni nyomtatott formában, meg is tettem és ebben azt írja, hogy a Veracity az új király. Mondjuk ront a képen, hogy a fejlesztőknél dolgozik az író, így objektívnek nem nevezhető. De alternatíva. :-)

"Belépés díjtalan, kilépés bizonytalan."

A konyhakes tenyleg tokeletes hasonlat. Jelentkezzen, aki meg nem vagta el egyszer sem a kezet. Amugy meg tenyleg hasznos tud lenni, ha az ember eltoltott mar par honapot git elott. Viszont itt kerdeznem meg, hogy biztos ugyan arrol beszelunk-e, mert en nem vagyok nagy Git guru. En a magam reszerol a rebase -i altal elerheto localis repozitory editalo funkciora gondoltam es nem arra, hogy mondjuk a pull kozben megerkezo commit-okat rebase-elem. Az utobbi nyilvan egy nagyon jo dolog. Ez elobbi meg nagyon elegans es konyhakes jellegu.

Ha pullolsz, és az upstream frissült, de mondjuk a lokális master branch 1 vagy több committal előbbre jár, és a változtatásaidat felpakolja az új állapot tetejére, akkor az fast-forward (belül valószínűleg ugyanaz történik mint mikor rebase -kor pl. megcserélsz két commitot).

A rebase amúgy érdekes kérdés, mert "általában" azt jelenti, hogy a commitokat szabadon mozgathatod, viszont a git rebase alá több parancs is tartozik, pl. egy régebbi commit reword -je (ami ugye maga után vonja a gyerek commitok sha-újraszámolását is). Nem tudom, hogy más scm -eknél mi tartozik a rebase körébe, de gitnél egyértelműen tágabb a halmaz. Valószínűleg azért vontak egybe egy csokor parancsot a rebase alá, mert már egyébként is több tucat főparancs volt a githez.

--
http://neurogadget.com/

Igen, megvágtam már a kezem késsel. És? Megmostam, fertőtlenítettem, beragasztottam, aztán aprítottam tovább, mert az ebédnek csak el kell készülnie.
A rebase-nél még ennyit se kell csinálni, bármikor vissza lehet állni a rebase-t megelőző állapotra, elvégre ezért van a reflog.

Az informatika már csak ilyen veszélyes üzem. Jobbklikket nyomsz egy file-ra, aztán ott a "Törlés" a menüben, borzalom.

Egyrészt lassú, másrészt meg minek akkor az SVN? Git-ben és Hg-ben is lehet központi repó, csak mellette megvannak a helyi másolatok is. Én amúgy toltam így, nehézkesnek tűnt.

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

Az SVN központi repó előnye az egyszerű revision számozás, ami jelentősen könnyebb a build-felelősöknek és/vagy az üzemeltetésnek (főleg ha több verzió is futhat a programból, és vissza kell tudni nézni valamit). Én az svn+hg kombinációt használtam, az elviselhető sebességű volt - mondjuk én nem csináltam ötpercenként brancheket...
--
blog: en | hu

A git előnye ott jön nagyon elő, amikor több verziót kell egyszerre életben tartanod egy programból. Ilyenkor azt csinálod, hogy a main line (master) a fejlesztési ág, és a verziók branchek. Az egyes frissítések pedig cherry-pick-kel szépen, egyszerűen visszacsorognak a régi verziókra. Valjuk be egymás közt: a branch kezelés elég fájdalmas SVN-ben.
--
http://naszta.hu

A branch-kezelés és a branchek közötti váltás tényleg fájdalmas, de ahogyan a hg/git is klónoz egy repo-t, úgy igazából az SVN repo-t is lehet klónozni, és hasonló hatékonyságot el lehet érni vele. Igazából mindig az a kérdés, hogy milyen workflowban szeretnél dolgozni, és van amikor az svn dolgozik alád jobban, van amikor a másik megközelítés. Én azért pártolom az svn+hg / svn+git kombót, mert ugyan egy kicsit tényleg bonyolultabb mint a homogén választások, de össze lehet úgy rakni, hogy ki tudod használni mindkét technológiának az előnyeit, és a hátrányok inkább tompulnak.
--
blog: en | hu

de ahogyan a hg/git is klónoz egy repo-t, úgy igazából az SVN repo-t is lehet klónozni, és hasonló hatékonyságot el lehet érni vele.

Ahhoz, hogy több branch-em legyen, ahhoz nem kell klónozni a repot ha git-et használsz. Egyetlen tree-ben lehet akármennyi branch, egyszerre. És egy pillanat alatt tudsz váltani köztük. Hogyan lehet ezt a hatékonyságot elérni SVN-nel?

van amikor az svn dolgozik alád jobban, van amikor a másik megközelítés.

Konkrétan mi az a feladat, amire az SVN jobb?

hogy ki tudod használni mindkét technológiának az előnyeit

Mik az SVN előnyei?

Azért van az SVN-nek is előnye, bár tény, hogy nem sok.

Pl. valamilyen okból nem akarok a fejlesztőknek teljes hozzáférést adni, akkor hasznos lehet, hogy tudtommal a letöltött anyagból nem lehet reprodukálni az eredeti repót, a letöltött anyag használatához szükség van az eredeti repóra. (Ez persze lehet, hogy nem így van, régen SVN-eztem és akkor sem túl sokat.)
A másik előnye, hogy ha a repository nagy, akkor nem kell a fejlesztőnek letölteni mindent, pl. olyan ágat, ami nem is érinti. Azért a Git-ben egy nagyobb repónál, míg minden commit lejön, el tud tartani egy ideig.
Plusz elméletileg több program támogatja a kezelését, IDE-k stb.

Mindent összevetve azért én sem használnék SVN-t már.

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

> A másik előnye, hogy ha a repository nagy, akkor nem kell a fejlesztőnek letölteni mindent

git clone --depth ebben lehet felmegoldas (pusholni nem lehet a shallow clonebol, pl). A GitHub lehet egy masik megoldas, mert githubon minden repo egyben SVN repo is: 


$ svn checkout https://github.com/algernon/libmongo-client/branches/stable lmc-stable

> Azért a Git-ben egy nagyobb repónál, míg minden commit lejön, el tud tartani egy ideig.

Igen, de ezt csak egyszer kell eljatszani, es mivel a git repo eleg kompakt, egy full git checkout igen sok esetben elenyeszoen tart csak tobb ideig, mint egy svn checkout. Es gitnel meg az is meg lesz, hogy ha netan megis szuksege van az embernek egy masik branchre, akkor az rogton ott van keznel.

> Plusz elméletileg több program támogatja a kezelését, IDE-k stb.

Kb minden ami el es mozog, es tamogat SVN-t, az altalaban gitet is. A "nagyok" mind.

--
|8]

Engem nem kell meggyőznöd, mert már régóta Git-et használok és élvezem. :) Csak azokat az érveket hoztam fel, amelyekkel gyakran találkozok, ha valahol felmerül a git-re migrálás. :)

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

Amúgy egy ideig használtam Bazaar-t is (sőt, azon kezdtem az elosztott verziókezelőkkel való ismerkedést) és egész kellemes. Egyszerűbb, mint a git és (szerintem) többet tud, mint az SVN.

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

Persze, git esetén nem tudsz checkoutolni. Teljesen értelmetlen az összehasonlítás. Ha arra gondolsz, hogy önállóan verziókezelhető részeket leszaggatni belőle, akkor való igaz, ez mondjuk következik abból is, hogy vannak ilyenek, hogy git mv. De félmegoldás van: submodule.
----
India delenda est.
Hülye pelikán

Ó, ez egy nagyon buta poszt :(

"1. Complex information model"

Ez igaz, de ez "and you need to know all of it." már nem. Tehát gyakorlatilag nem hátrány. A komplex modell meg előfeltétele a komplex működésnek. És a distributed mindig is bonyolultabb lesz, mint a centralizált, bármiről is legyen szó.

"2. Crazy command line syntax"

Ezt aláírom.

"3. Crappy documentation"
"They describe the commands from the perspective of a computer scientist, not a user."

Azt hittem verziókezelni jellemzően a programozók szoktak. Én ezzel teljesen elégedett vagyok, mármint a git dokumentáltságával, bármilyen problémámra első találat általában megfelelő.

"4. Information model sprawl"

Ez ugyanaz, mint az első poszt, és Google még mindig a barátom. Az információs modell bonyolultsága meg nem bug, hanem fícsör.

"5. Leaky abstraction"

Ugyanaz, mint a 2.

"6. Power for the maintainer, at the expense of the contributor"

Részben igaz, valóban bonyolultabb egy fokkal, mint az svn. De a hasonlata nagyon jó: "Git is a 4 handle, dual boiler espresso machine – when all they need is instant." Igen, és egy profi gépen talán nehezebben találod meg a gombot, de ugyanolyan könnyű megnyomni és utána nyomkodni amíg csak kávéra van szükséged.

"7. Unsafe version control"

ÚRISTEN TÖNKRE LEHET TENNI EGY REPÓT MÁSHOL EZ LEHETETLEN :::::!!!:!!444
De tényleg, nem egyszer veszítettünk el teljes svn repót mert valaki félrenyomott valamit. Nabumm. A gitnél az a szerencsés helyzet áll fennt, hogy ha valakinek a localjából vissza tudjátok állítani, akkor megmarad a history is.

"8. Burden of VCS maintainance pushed to contributors"

Ugyanaz, mint a 6.

"9. Git history is a bunch of lies"

Ez hülyeség. LEHET módosítani, de amíg nem pusholod valahova, addig az a te belügyed, utána pedig már nem illik.

"10. Simple tasks need so many commands"

Ez a példa meg szándékosan torzít.
----
India delenda est.
Hülye pelikán