Bup – efektivní verzování velkých blobů v Gitu (diskuse)

[pavlix]

Tak on Git není v ukládání velkých dat o nic horší než většina jiných systémů. Takže tímhle může vzniknout nová komparativní výhoda.

[JS]

Neni? Ja myslel, ze Git uklada kazdou novou verzi jako cely soubor, a ne jako rozdil, jak to delaji nektere jine VS. Coz muze byt vyhoda i nevyhoda, zalezi na pohledu.

[alblaho]

Jo, ale starší revize kompresuje. Repozitář s kompletní historií bývá v gitu leckdy menší než jednoduchý SVN checkout.

[pavlix]

Neni? Ja myslel, ze Git uklada kazdou novou verzi jako cely soubor, a ne jako rozdil, jak to delaji nektere jine VS.

To je právě jenom konceptuální pohled. V reálu ty celé soubory komprimuje pomocí binárních rozdílů.

Git je v tomhle zprvu o něco složitější na pochopení, jak už jednoduché a elegantní věci bývají :). Optimalizace se v něm řeší opravdu... jako optimalizace a ne jako jádro problému (což není), jako se to dělá jinde.

[A]

Konecne - toto som presne potreboval...

[pc2005]

average size of 8192 bytes

Kdyby to mělo 8MB chunky, tak by to moc k použití nebylo, osobně tak 10x8MB binárky snad ani nemám (flight-gear má sice asi 250MB komprimovanou instalačky, ale to jsou vše textury).

Jinak imho by bylo efektivnější oba soubory od sebe odečíst a na místech rozdílu získat tímto nenulové hodnoty. Nulové by se jednoduše odřízly nebo zkomprimovaly něčím triviálním jako RLE. Osobně se mi ale zdá, že binárka se bude blbě diffovat, protože se i drobnou změnou mění celé adresy skoků dále v souboru. Lepší je imho gitovat zdrojáky .

[dustin]

Binárka bude spíše častěji obrázek, PDF, video.

[pc2005]

Jo aha, já jsem asi zblblej z projektu, kde používám zhusta objdump -O binary ... U videa by to bylo pochopitelný i když používat git na video není imho efektivní metoda.

[dustin]

To samozřejmě není, ale když se provádí aktualizace ostrého webu z devel prostředí přes git, občas je potřeba tam strčit i něco jiného než zdrojáky či malé obrázky. Aktualizace je pak triviální.

Tomuto směru držím palce.

[pc2005]

No u kopírovanejch novejch videí bude potřeba to video tam nakopírovat celý tak jako tak, takže rozdělení na chunky nebude stačit. Pro editaci nějakýho video projektu bych spíš použil nějakej nelineární střihový editor a ukládal změny v konfiguraci těch střihů.

Jinak rozhodně takový vývojový systém se bude používat víc a víc. Možná by bylo výhodnější dělat snapshoty celýho disku .

[Nicky726]

Jujda :-[, opraveno.

[Věroš]

No, včera jsem natlačil do gitu 30 GB obrázek. V takovém případě si dokážu docela dobře představit využití 8MB chunků.

PS: Ale mám takové podezření, že ten kdo pracuje s gigabajtovými obrázky, tak velikost disku nejspíš neřeší.

[pc2005]

A ten obrázek byl změněnej? Pokud byl novej, tak se stejně uloží celej.

[pavlix]

PS: Ale mám takové podezření, že ten kdo pracuje s gigabajtovými obrázky, tak velikost disku nejspíš neřeší.

Tak to pozoor. ono se to dlouho přetahuje po síti, a hrozně blbě se to ve velkých kvantech zálohuje.

[Mandarinka]

Rozumím tomu, že při změně bitu se sice změní jenom jeden úsek, ale při vložení bitu se změní všechny následující (viz jak fungují torrenty)? To mi až zas tak šikovné nepřijde.

[Jindřich Makovička]

Vtip je v tom, že délka těch úseků se určuje na základě obsahu. Podobný trik používá gzip --rsyncable nebo rsyncrypto.

[dustin]

Jasně, to by bylo k ničemu, kdyby posun o jeden bit rozhodil všechny chunky :)

[Milan Vančura]

Popis designu je sice dost dlouhý, ale na druhou stranu poměrně čtivý. Na začátku obsahuje popis základních algoritmů a v následujících kapitolách reálné problémy a jejich řešení. Přišlo mi to zajímavé i jako jiný pohled na git (kde má slabiny, proč tam jsou a jak je obejít atp.)

[dustin]

Jo, ty kluci jsou fakt dobrý.

[Bedňa]

Použiť to na všetkú muziku DRUM & BASS a podobných ptákovín, možno by postačilo 20 MB v Bup.