Re: [devel] Как сделать репозиторий в git

[Anton Farygin <rider@altlinux.com>]

Dmitry V. Levin wrote:
> On Wed, Apr 26, 2006 at 10:46:06PM +0400, Anton Farygin wrote:
>> Интересно было бы взглянуть на:
>> 1) формат buildspec
> 
> Тот формат, который сформировался на сегодняшний день, устроен следующим
> образом.
> 
> buildspec - простой текстовый файл, обрабатываемый построчно.
> Каждая строка имеет вид "директива: параметры"
> Директивы такие: spec, copy, gzip, bzip2, tar, tar.gz, tar.bz2
> - т.е. кажется всё, что нужно для извлечения из репозитория.
> 
> Параметр spec: путь_к_файлу
> Параметры copy|gzip|bzip2: glob_pattern..
> Параметры tar|tar.gz|tar.bz2: путь_к_каталогу [options]
>   где options это
>     spec=путь_к_файлу - путь к specfile'у, из которого можно извлечь имя
>       и/или версию для тарболла;
>     name=имя_архива - имя для тарболла;
>     version=версия_архива - версия для тарболла.
> 
> Фраза "spec-файл, из которого можно извлечь имя" означает, что команда
> sed '/^Name:[[:space:]]*/!d;s///;q' <spec-файл
> выводит нормальное имя.  Имя называется нормальным, если не содержит
> недопустимых символов.
> Аналогично трактуется и фраза про версию.
> 
> Примеры я уже приводил в этом треде.  Могу ещё придумать, если нужно.

Вопрос: если я правильно понял, то .buildspec будет распарсиваться неким 
скриптом на стороне сервера (или локально?)

А можно ли предложить какой-то инструмент, для сборки пакета из 
локальной копии репозитария, минуя hasher ?

Т.е. - я очень много собираю без hasher'а, прямо в локальной системе.
> 
>> 2) типовой набор команд для того, что бы с этим работать
> 
> $ git2tar -h
> git2tar - make tarball from git package repository.
> 
> Usage: git2tar [options] <path-to-git-directory> <output-tarball-name>
> 
> Options:
>   -b, --buildspec=FILENAME          buildspec file name;
>   --bzip2                           compress output archive using bzip2;
>   --gzip                            compress output archive using gzip;
>   -t, --tree-ish=ID                 tree, commit or tag object name;
>   -q, --quiet                       try to be more quiet;
>   -v, --verbose                     print a message for each action;
>   -V, --version                     print program version and exit;
>   -h, --help                        show this text and exit.
>     
> Т.е. есть простая утилита, у которой на входе git-репозиторий и tree-ish
> (по умолчанию --tree-ish=HEAD) и на выходе tarball специального вида, из
> которого hasher скоро научится собирать пакеты.
> 
> Ещё раз обращаю внимание: собирать пакеты надо из того, что есть в
> репозитории, а не из неза'commit'енного checkout'а.  Те, кто хоть немного
> представляют себе, как устроен git, согласятся, что это не создаст
> дополнительных сложностей.  Зато появится одно полезное свойство - вряд ли
> удастся забыть за'commit'ить нужное изменение.
> 
>> - если я правильно понял, то предполагается каждый пакет держать в 
>> отдельном GIT репозитарии.
> 
> Несомненно.  Я не вижу других вариантов.
> 
>> Вопрос собственно простой: каким образом
> 
> Я пока не определился, как именно будет устроен центральный репозиторий
> для Sisyphus.  Тут есть варианты, надо понять, на чём остановиться.
> Я сейчас занимаюсь доработкой попакетного репозитория, объединительные
> репозитории - это следующий этап.

Ясно. Меня в большей степени интересует вопрос с объединением. И с 
правами доступа к каждому из пакетов (желательно что бы права доступа 
были в достаточной мере открыты - что-то вроде teams по интересам).

> 
>> 1) скачать все пакеты
> 
> Скачать список всех пакетов.
> Скачать (git-clone, git-fetch, etc) каждый пакет из списка.
> 
>> 2) добавлять пакеты в центральный репозиторий
> 
> Видимо примерно так же, как и обновлять их (git-push).
> 
>> 3) удалять пакеты из центрального репозитория
> 
> Не думаю что удалить каталог это проблема. :)
> 
>> 4) обновлять весь центральный репозиторий (можно конечно сделать for i 
>> in *;do... done, то на мой взгляд в этом случае мы не отследим 
>> добавление/удаление пакетов.
> 
> Весь репозиторий - это каталог с репозиториями.  Можно использовать
> какой-нибудь dumb transport (e.g. rsync), можно прочитать список и сделать
> git-pull для каждого.
> 


И ещё пока вспомнил: крайне желателен инструмент, позволяющий закачивать 
  в git большие тарболлы минуя commit (или каким-то средством на стороне 
сервера).

Поясню:

например есть необходимость положить в git приложение, исходник которого 
в распакованном виде занимает 600Mb (например - openoffice.org).

в случае с тарболлом, который нужно из локального репозитария залить на 
сервер - трафик составит 600Mb исходящий (если не использовать сжатие на 
уровне ssh).

При этом у мантейнера канал может быть достаточно дохлый (например модем 
или gprs).

Было бы очень здорово предоставить инструмент, который смог бы:
- выкачивать файл с заданного URL
- проверять md5sum
- распаковывать
- коммитить

Rgds,
Rider