[devel] I: about storing tarballs

[devel] I: about storing tarballs

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3151 bytes --]

Hi,

Информация к размышлению на тему хранения исходного кода,
по мотивам короткого обсуждения в офисе.

$ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.bz2 nmap.delta
$ ls -logS nmap*
-rw-r--r-- 1 1897778 Мар  4 07:32 nmap-4.02Alpha1.tar.bz2
-rw-r--r-- 1 1896625 Мар  9 01:42 nmap-4.02Alpha2.tar.bz2
-rw-r--r-- 1 1885642 Апр 20 00:00 nmap.delta
Подтверждение известного факта: несильно отличающиеся пожатые bzip'ом
файлы отличаются настолько сильно, что xdelta неэффективна.

$ xdelta delta -9 nmap-4.02Alpha{1,2}.tar nmap.delta
$ ls -logS nmap*
-rw-r--r-- 1 10485760 Мар  4 07:32 nmap-4.02Alpha1.tar
-rw-r--r-- 1 10485760 Мар  9 01:42 nmap-4.02Alpha2.tar
-rw-r--r-- 1    28612 Апр 20 00:00 nmap.delta
Ну xdelta она и есть xdelta.

$ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.gz nmap.delta
$ ls -logS nmap*
-rw-r--r-- 1 2377616 Мар  4 07:32 nmap-4.02Alpha1.tar.gz
-rw-r--r-- 1 2376325 Мар  9 01:42 nmap-4.02Alpha2.tar.gz
-rw-r--r-- 1   28621 Апр 20 00:00 nmap.delta
Напоминание о том, что xdelta по умолчанию распаковывает файлы,
пожатые gzip'ом, прежде чем вычислять дельту.

$ git --version
git version 1.3.0
$ git-init-db
defaulting to local storage area
$ git-add nmap-4.02Alpha1.tar
$ git-commit -a -m 'added nmap-4.02Alpha1.tar'
Committing initial tree 85258d162dda0117f7708bccf5d1e9349c99a1c6
$ git-rm nmap-4.02Alpha1.tar
$ git-add nmap-4.02Alpha2.tar
$ git-commit -a -m 'replaced nmap-4.02Alpha1.tar with nmap-4.02Alpha2.tar'
$ du -ksc .git/objects/*
2332    .git/objects/02
8       .git/objects/14
8       .git/objects/21
8       .git/objects/7f
8       .git/objects/85
2332    .git/objects/a5
4       .git/objects/info
4       .git/objects/pack
4704    итого
Отсюда видно, что git, как и следовало ожидать, хранит объекты
в пожатом gzip'ом виде.
$ git-repack -a -d -q
Pack pack-2bfd07a53828de0ec93e61d6382c3cd650da97d5 created.
$ du -ksc .git/objects/*
8       .git/objects/info
2372    .git/objects/pack
2380    итого
Отсюда видно, что в упакованном виде объекты занимают примерно столько же
места, что и nmap-4.02Alpha1.tar.gz+nmap.delta; это наводит на мысль об
используемом алгоритме; RTFS эту мысль подтверждает.

$ git-init-db
defaulting to local storage area
$ git-add nmap-4.02Alpha1.tar.gz
$ git-commit -a -m 'added nmap-4.02Alpha1.tar.gz'
Committing initial tree 4233a782960e126094163106d204074388745589
$ git-rm nmap-4.02Alpha1.tar.gz
$ git-add nmap-4.02Alpha2.tar.gz
$ git-commit -a -m 'replaced nmap-4.02Alpha1.tar.gz with nmap-4.02Alpha2.tar.gz'
$ du -ksc .git/objects/*
8       .git/objects/12
8       .git/objects/16
2324    .git/objects/18
8       .git/objects/42
8       .git/objects/45
2328    .git/objects/d9
4       .git/objects/info
4       .git/objects/pack
4692    итого
$ git-repack -a -d -q
Pack pack-8d8d591db747584462d34e3b6a8bc6fa498a5f20 created.
$ du -ksc .git/objects/*
8       .git/objects/info
4656    .git/objects/pack
4664    итого
Отсюда видно, что с файлами, пожатыми gzip'ом, экономии в git не получается.
Таким образом, в git лучше класть непожатые файлы, тогда при желании
их можно будет хранить экономно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] I: about storing tarballs

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

On 02:56 Thu 20 Apr, Dmitry V. Levin wrote:
> Hi,
> 
> Информация к размышлению на тему хранения исходного кода,
> по мотивам короткого обсуждения в офисе.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.bz2 nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 1897778 Мар  4 07:32 nmap-4.02Alpha1.tar.bz2
> -rw-r--r-- 1 1896625 Мар  9 01:42 nmap-4.02Alpha2.tar.bz2
> -rw-r--r-- 1 1885642 Апр 20 00:00 nmap.delta
> Подтверждение известного факта: несильно отличающиеся пожатые bzip'ом
> файлы отличаются настолько сильно, что xdelta неэффективна.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 10485760 Мар  4 07:32 nmap-4.02Alpha1.tar
> -rw-r--r-- 1 10485760 Мар  9 01:42 nmap-4.02Alpha2.tar
> -rw-r--r-- 1    28612 Апр 20 00:00 nmap.delta
> Ну xdelta она и есть xdelta.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.gz nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 2377616 Мар  4 07:32 nmap-4.02Alpha1.tar.gz
> -rw-r--r-- 1 2376325 Мар  9 01:42 nmap-4.02Alpha2.tar.gz
> -rw-r--r-- 1   28621 Апр 20 00:00 nmap.delta
> Напоминание о том, что xdelta по умолчанию распаковывает файлы,
> пожатые gzip'ом, прежде чем вычислять дельту.
А добавить такое же поведение для bzip2 возможно? Или это не целесобразно
из соображений совместимости?

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

<vsu> ммать... какая $#$$#$%@ в incoming ядро wks залила.... неподписанное...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] I: about storing tarballs

[Anton Farygin]

Dmitry V. Levin wrote:
> Hi,
> 
> Информация к размышлению на тему хранения исходного кода,
> по мотивам короткого обсуждения в офисе.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.bz2 nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 1897778 Мар  4 07:32 nmap-4.02Alpha1.tar.bz2
> -rw-r--r-- 1 1896625 Мар  9 01:42 nmap-4.02Alpha2.tar.bz2
> -rw-r--r-- 1 1885642 Апр 20 00:00 nmap.delta
> Подтверждение известного факта: несильно отличающиеся пожатые bzip'ом
> файлы отличаются настолько сильно, что xdelta неэффективна.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 10485760 Мар  4 07:32 nmap-4.02Alpha1.tar
> -rw-r--r-- 1 10485760 Мар  9 01:42 nmap-4.02Alpha2.tar
> -rw-r--r-- 1    28612 Апр 20 00:00 nmap.delta
> Ну xdelta она и есть xdelta.
> 
> $ xdelta delta -9 nmap-4.02Alpha{1,2}.tar.gz nmap.delta
> $ ls -logS nmap*
> -rw-r--r-- 1 2377616 Мар  4 07:32 nmap-4.02Alpha1.tar.gz
> -rw-r--r-- 1 2376325 Мар  9 01:42 nmap-4.02Alpha2.tar.gz
> -rw-r--r-- 1   28621 Апр 20 00:00 nmap.delta
> Напоминание о том, что xdelta по умолчанию распаковывает файлы,
> пожатые gzip'ом, прежде чем вычислять дельту.

<skip>

> Отсюда видно, что с файлами, пожатыми gzip'ом, экономии в git не получается.
> Таким образом, в git лучше класть непожатые файлы, тогда при желании
> их можно будет хранить экономно.

а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
неупакованные tar'ы ?

Rgds.
Rider

Re: [devel] I: about storing tarballs

[Anton D. Kachalov]

On Thu, Apr 20, 2006 at 01:33:18PM +0400, Anton Farygin wrote:
> а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
> неупакованные tar'ы ?
ну да. зачем их паковать, если потом снова распаковывать :)

--
mouse

Re: [devel] I: about storing tarballs

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Anton D. Kachalov пишет:
> On Thu, Apr 20, 2006 at 01:33:18PM +0400, Anton Farygin wrote:
>   
>> а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
>> неупакованные tar'ы ?
>>     
> ну да. зачем их паковать, если потом снова распаковывать :)
>   

Пропущено ключевое слово: паковать и распаковывать *дважды* ;)

Теоретически, от этого можно получить дополнительные бенефиты при 
выполнении нескольких дополнительных условий:

- в rpm кладутся неупакованные tar'ы (сейчас это не так)
- cpio внутри rpm сжимается при помощи gzip (это вроде бы так сейчас у нас)
- используемый gzip/zlib пропатчен на предмет создания rsync-friendly 
архивов (это не так, где-то в багзилле есть патчи)

после этого, теоретически, может быть что-нибуть да и полчится в плюсе :)

-- 
Best regards,
Sviatoslav Sviridov
--
In English, every word can be verbed.  Would that it were so in our
programming languages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] I: about storing tarballs

[Ildar Mulyukov]

On Fri, Apr 21, 2006 at 10:49:22AM +0300, Sviatoslav Sviridov wrote:
> Anton D. Kachalov пишет:
> >On Thu, Apr 20, 2006 at 01:33:18PM +0400, Anton Farygin wrote:
> >>а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
> >>неупакованные tar'ы ?
> >ну да. зачем их паковать, если потом снова распаковывать :)
> Пропущено ключевое слово: паковать и распаковывать *дважды* ;)
> 
> Теоретически, от этого можно получить дополнительные бенефиты при 
> выполнении нескольких дополнительных условий:
> 
> - в rpm кладутся неупакованные tar'ы (сейчас это не так)
Однако в этом случае ломается следующее:
    Также желательно формировать тег Source таким образом, чтобы он
    образовывал действующий адрес файла (тарбола), по которому его можно
    автоматизированно получить*. В простейшем случае подходит
    Source: %url/%name-%version.tar.bz2
(взято с http://wiki.sisyphus.ru/devel/SpecTips/PackageUrl?v=cle)

Хотя если уж выбирать между новшеством и этой закорючкой, конечно 
лучше первое.

--
Ildar  Mulyukov, 
  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] I: about storing tarballs

[Michael Shigorin]

On Thu, Apr 20, 2006 at 01:33:18PM +0400, Anton Farygin wrote:
> > Отсюда видно, что с файлами, пожатыми gzip'ом, экономии в git
> > не получается.  Таким образом, в git лучше класть непожатые
> > файлы, тогда при желании их можно будет хранить экономно.
> а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
> неупакованные tar'ы ?

А при чём тут RPM?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: about storing tarballs

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Wed, Apr 26, 2006 at 11:14:41AM +0300, Michael Shigorin wrote:
> On Thu, Apr 20, 2006 at 01:33:18PM +0400, Anton Farygin wrote:
> > > Отсюда видно, что с файлами, пожатыми gzip'ом, экономии в git
> > > не получается.  Таким образом, в git лучше класть непожатые
> > > файлы, тогда при желании их можно будет хранить экономно.
> > а упаковывать перед сборкой ? Или вообще в RPM пакет класть 
> > неупакованные tar'ы ?
> 
> А при чём тут RPM?

А что делать на время перехода?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] I: about storing tarballs

[Michael Shigorin]

On Wed, Apr 26, 2006 at 02:30:43PM +0400, Dmitry V. Levin wrote:
> > > Или вообще в RPM пакет класть неупакованные tar'ы ?

(с одной стороны, двойное(?) сжатие src.rpm действительно
бессмысленно, с другой -- git на сейчас экспериментальный,
а %_topdir/SOURCES -- реальность для всех)

> > А при чём тут RPM?
> А что делать на время перехода?

Не ломать существующее?  Заморозить обработку пакетов на неделю 
или две ради спокойного переезда -- думаю, реально.  По факту
от таких случаев вроде никто ещё не умер.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: about storing tarballs

[Genix]

Michael Shigorin wrote:

>>> А при чём тут RPM?
>> А что делать на время перехода?
> 
> Не ломать существующее?  Заморозить обработку пакетов на неделю 
> или две ради спокойного переезда -- думаю, реально.  По факту
> от таких случаев вроде никто ещё не умер.

а совместить два метода возможно? заливка src.rpm и работа с jit



-- 
У каждого в башке свои тараканы...

Re: [devel] I: about storing tarballs

[Michael Shigorin]

On Wed, Apr 26, 2006 at 05:33:54PM +0400, Genix wrote:
> >>> А при чём тут RPM?
> >> А что делать на время перехода?
> > Не ломать существующее?  Заморозить обработку пакетов на
> > неделю или две ради спокойного переезда -- думаю, реально.
> > По факту от таких случаев вроде никто ещё не умер.
> а совместить два метода возможно? заливка src.rpm и работа с jit

По крайней мере для этого придётся писать разбиралку и коммитилку 
от имени майнтейнера.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: about storing tarballs

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Wed, Apr 26, 2006 at 03:24:49PM +0300, Michael Shigorin wrote:
> On Wed, Apr 26, 2006 at 02:30:43PM +0400, Dmitry V. Levin wrote:
> > > > Или вообще в RPM пакет класть неупакованные tar'ы ?
> 
> (с одной стороны, двойное(?) сжатие src.rpm действительно
> бессмысленно, с другой -- git на сейчас экспериментальный,
> а %_topdir/SOURCES -- реальность для всех)

Одно другому не мешает, можно в git хранить несжатые тарболлы, а в
%_topdir/SOURCES - сжатые.  Я недавно пример со strace'ом приводил.

> > > А при чём тут RPM?
> > А что делать на время перехода?
> 
> Не ломать существующее?  Заморозить обработку пакетов на неделю 
> или две ради спокойного переезда -- думаю, реально.  По факту
> от таких случаев вроде никто ещё не умер.

Если можно не ломать, то не надо ломать.
Я думаю, что можно не ломать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] I: about storing tarballs

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

Dmitry V. Levin пишет:
> Hi,
>
> Информация к размышлению на тему хранения исходного кода,
> по мотивам короткого обсуждения в офисе.
> ...
> Отсюда видно, что с файлами, пожатыми gzip'ом, экономии в git не получается.
> Таким образом, в git лучше класть непожатые файлы, тогда при желании
> их можно будет хранить экономно.
>   

Кстати, это утверждение можно считать верным для любой системы 
управления версиями, которая умеет хранить изменения между различными 
версиями файлов (при правильном использовании). imho.

-- 
Best regards,
Sviatoslav Sviridov
--
UNIX enhancements aren't.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]