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

 ( trey | 2012. november 20., kedd - 9:34 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

--
NetBSD - Simplicity is prerequisite for reliability

+1

Mesélj! :)

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

egy git fsck --full parancs remlik valami teljesen trivialis utan (SIGINT pull kozben talan?)

--
NetBSD - Simplicity is prerequisite for reliability

Még az a jó, hogy NetBSD-ben, és meg semmilyen más projektben, például az SVN-ben nem voltak ordas hibák...

*a wild git fanboy appears*

--
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.

"nem érdekel mit írsz"

Ilyen, amikor nem erdekel?

"Ezért tart itt az ország."

Ez feltétlen kellett bele és hitelessé tette az egész hozzászólásodat. Nem mintha anélkül lett volna bármi értelmes benne mondjuk.

+2π
Ráadásul a Git GPL licences ezért ideológiai okokból is ellenjavallt a használata. :D

plusz egy a kétpire

Szerencsére van jgit, ami BSD licenszes. :)

most git a "menő", majd jön valami új megint aztán minden faszagyerek szerint az lesz az über.
én még mindig svn-ezek, de nem igazán érzem hátrányát. persze legtöbbször max 30-50 emberrel dolgozom.

Valojaban mit szerettel volna kozolni?

É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! :)

Mondjuk a "nap végi commit" szerintem eleve nem normális SCM-től függetlenül. :)

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

Persze, de az SCM nem backup.

Dolgoztam én 100+ emberes cégnél (mondjuk kb. fele fejlesztő) és ők is CVS-eznek. Szánalom.

A git nem csak menő. Megszállott Visual Studio C++-osként mondom: A git és a Mercurial a két legjobban használható verziókövető rendszer. Pl: van normális branch kezelés, a cherry-pick nélkül meg lassan embert ölnék. :)
--
http://naszta.hu

Egy kis történelem arról, hogy Linus miért nem szereti a cherry picking-et: link.
:)

Mondjuk én no commit-tal tolom és átnézem commit előtt. Persze nem is kernel méretű dolgokkal dolgozom.
--
http://naszta.hu

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

Ez most hogy jött ide?
----
India delenda est.
Hülye pelikán

szerintem a RAD egesz hasznalhato.

Hát még egyetemen kellett használni valahova, és nekem a tetűlassú és az ostoba szavak ugranak be róla. Azt láttam, hogy jól össze lehet benne kattintgatni mindent, de egyéb előnyét nem nagyon.
----
India delenda est.
Hülye pelikán

clearcase-t nem az ibm fejlesztette fyi

--
NetBSD - Simplicity is prerequisite for reliability

Na de ha lett volna egy csepp eszük, nem vásárolják föl azt a rakás fost.
----
India delenda est.
Hülye pelikán

igazabol azokkal nincs valami rendben, akik a 21szd-ban meg fizetnek is erte

--
NetBSD - Simplicity is prerequisite for reliability

Ezt maximálisan aláírom, de azért érdekel, hogy a fájlonkénti verziókezelés vajon kinek jutott eszébe, hogy jó ötlet lesz.
----
India delenda est.
Hülye pelikán

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

Kérdés, hogy az a dolog, ami segíti a fejlesztést, de nem épül bele a termékbe, az hozzá tartozik-e a licenc-körkérdéshez? Emlékszünk még arra hogy mi vezetett a git kifejlesztéséhez?

--
http://neurogadget.com/

Én pontosan emlékszem rá, de beszélhetünk róla.

Larry McVoy és a BitMover Inc. visszavonta az ingyenesen használható BitKeeper-t és helyette egy megnyomorított nyílt forrású klienset tett elérhetővé:

http://hup.hu/node/8502
http://hup.hu/node/8347

--
trey @ gépház

Apropo, mi lett ezzel a ceggel? A honlapjuk alapjan nem tul aktivak.

tompos

ui.: Es mi lett a fo-fo patent trollal? Arrol mar regota nem volt cikk, hehe.

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

Hat ez tenyleg nehezen megallapithato dolog...

http://mercurial.selenic.com/about/

Amugy GPLv2

A subversion meg apache licences bar hogy az hogy aranylik a BSDL-hez azt nem tudom...

A Chris Rees által említett BSDL-t én sehol sem láttam. Márpedig nekik csak az jó.

--
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."

"új király", miközben se bisect, se rebase?

Mondjuk a git rebase azert egy kicsit veszelyes jatekszer... Szoval azert nem biztos, hogy konnyeket hullajtanek...

A konyhakés is veszélyes, mégis ott van szinte minden háztartásban. Oké, gyerek kezébe nem adjuk és kicsit jobban odafigyelünk, ha használjuk.

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

En konnyet nem, de epelme pontokat biztosan hullatnek rebase nelkul.

--
|8]

Veszélyesnek akkor nevezném, ha valaki nem tudja használni, tökéletes volt a konyhakéses hasonlat.

--
http://neurogadget.com/

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.

A veracity egy fos, a konyv semmi masrol nem szol, csak arrol, hogy toljon valami kisebb szekeret a veracity ala.

--
|8]

Írtam, gyanús, hogy az író ott dolgozik. De szélesítettem a látókört. :-) Én személy szerint git-et használok, nekem bőven megfelel.


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

A doksi egy kalap fost sem ér, a gitben is minden commit immutable, maximum egyes műveletek hatására új commitok keletkeznek, a régiek pedig a felületes néző számára eltűnnek (nem).
Szerk.: de van ipad client! Óje!

--
http://neurogadget.com/

Neked nagyon kimostak az agyad ottan gittel. :)

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

Én csak annyit mondtam hogy a doksi hazudik amikor azt állítja hogy a git commit mutable. :)

--
http://neurogadget.com/

Én azt nem értem, hogy az svn+hg / svn+git kombinációk miért nem elég jók az embereknek? Megmarad a központi repo, plussz aki akar, az játszik saját dvcs-el.
--
blog: en | hu

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! :)

Az svn legnagyobb előnye, hogy egyszerű, mint a faék. Ez sokszor fontos, amolyan legnagyobb közös nevező.
----
India delenda est.
Hülye pelikán

> 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! :)

Ertem en, en meg felhoztam a megoldasokat a mindig felmerulo, egyebkent nem letezo problemakra ;)

--
|8]

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! :)

SVN eseten lehet csak mappat checkoutolni ezt git eseten nem lehet.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

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

http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7

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

Jó tudni :)
----
India delenda est.
Hülye pelikán

http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

tompos

ui.: Szemely szerint nem vagyok egyik mellett sem.

Ó, 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

"De tényleg, nem egyszer veszítettünk el teljes svn repót mert valaki félrenyomott valamit."

Azt hogy sikerült? :) Mármint anélkül, hogy magába a repóba kézzel beletúrjon valaki valamit?

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

Nem tudom, a srác aki adminolta, branchelni akart, erre törölte a repót. Igen, ehhez különösen figyelmetlennek kell lenni, de azért előfordul.
----
India delenda est.
Hülye pelikán

De most őszintén, egy copy funkcióval hogy lehet kiüríteni egy egész repot?

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

Nem tudom, de a kedvedért lehet megkérdem a kollégát, hogy sikerült a baleset.
----
India delenda est.
Hülye pelikán

Felesleges bonyolítás, nagyjából ennyi vele a probléma.

--
http://neurogadget.com/

http://www.freebsd.org/doc/en/articles/p4-primer/index.html ez sem tunik BSDL -nek.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Amig nem GPL, addig nem gond!"

--
</troll|8]>