[devel] sandman vs. hasher+gear

[devel] sandman vs. hasher+gear

[Alexey I. Froloff]

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

Морально я уже почти готов перейти на связку gear+hasher, не
хватает только пары моментов.

В sandman есть такая штука, называется pocket.  Когда несколько
пакетов собираются в одном pocket'е, это аналог --with-stuff.  Но
кроме того sandman умеет по команде извлекать содержимое pocket'а
в каталог и удалять этот pocket.  Параллельно может использоваться
практически неограниченное количество pocket'ов.

Только что обнаружил, что аналогом sandcl -pocket foo будет
hasher --repo=foo ;-)  Остались вопросы, как достать всё из этого
repo и как этот repo убить чтобы не мешался?  Как-то не очень
интересно залезать руками внутрь path-to-workdir...

P.S.  А какой hook сработает на git-tag?  Хочу чтоб пакеты
автоматом собирались ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] sandman vs. hasher+gear

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 12:03:44AM +0400, Alexey I. Froloff wrote:
> Морально я уже почти готов перейти на связку gear+hasher, не
> хватает только пары моментов.
> 
> В sandman есть такая штука, называется pocket.  Когда несколько
> пакетов собираются в одном pocket'е, это аналог --with-stuff.  Но
> кроме того sandman умеет по команде извлекать содержимое pocket'а
> в каталог и удалять этот pocket.  Параллельно может использоваться
> практически неограниченное количество pocket'ов.
> 
> Только что обнаружил, что аналогом sandcl -pocket foo будет
> hasher --repo=foo ;-)  Остались вопросы, как достать всё из этого
> repo и как этот repo убить чтобы не мешался?  Как-то не очень
> интересно залезать руками внутрь path-to-workdir...

Я ничего сташного в этом не вижу, но если кого-то смущает, то
предлагайте синтаксис.

> P.S.  А какой hook сработает на git-tag?  Хочу чтоб пакеты
> автоматом собирались ;-)

У меня сформировалась привычка держать "чистовую копию" репозиториев в
другом месте файловой системы (защита от шаловливых рук).
Поэтому, когда я хочу выложить что-то, то выполняю git-push up что-то.
Так вот, в "чистовых" репозиториях настроены файлы hooks/update, с помощью
которых можно и changelog'и рассылать, и пакеты на сборку отправлять.
См. /usr/share/git-core/templates/hooks/update.


-- 
ldv

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

Re: [devel] sandman vs. hasher+gear

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [060510 14:10]:
> > Только что обнаружил, что аналогом sandcl -pocket foo будет
> > hasher --repo=foo ;-)  Остались вопросы, как достать всё из этого
> > repo и как этот repo убить чтобы не мешался?  Как-то не очень
> > интересно залезать руками внутрь path-to-workdir...
> Я ничего сташного в этом не вижу, но если кого-то смущает, то
> предлагайте синтаксис.
В принципе уже сделал вручную.  Но можно что-то вроде этого:

hsh-repo --repo=foo /path/to/workdir get /path/to/where
hsh-repo --repo=foo /path/to/workdir clear

get может складывать в /path/to/where/{RPMS,SRPMS} чтоб сразу на
sisyphus_add_new это отдавать.

> > P.S.  А какой hook сработает на git-tag?  Хочу чтоб пакеты
> > автоматом собирались ;-)
> У меня сформировалась привычка держать "чистовую копию" репозиториев в
> другом месте файловой системы (защита от шаловливых рук).
git-clone --bare .git /другое/место/name.git
chmod +x /другое/место/name.git/hooks/post-update

И потом это заливается в people ?

> Поэтому, когда я хочу выложить что-то, то выполняю git-push up что-то.
Как это /другое/место/name.git администрируется?  Какие hooks
используются?  Есть мнение, что в post-update вызывается не
только update-server-info (потому как в .git/objects/??/ пусто
обычно)...

Ну опиши пожалуйста примерный цикл работы с этим всем...

> Так вот, в "чистовых" репозиториях настроены файлы hooks/update, с помощью
> которых можно и changelog'и рассылать, и пакеты на сборку отправлять.
> См. /usr/share/git-core/templates/hooks/update.
Ага.  update.  Спасибо, буду смотреть...

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] sandman vs. hasher+gear

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 02:38:34PM +0400, Alexey I. Froloff wrote:
[...]
> > > P.S.  А какой hook сработает на git-tag?  Хочу чтоб пакеты
> > > автоматом собирались ;-)
> > У меня сформировалась привычка держать "чистовую копию" репозиториев в
> > другом месте файловой системы (защита от шаловливых рук).
> git-clone --bare .git /другое/место/name.git
> chmod +x /другое/место/name.git/hooks/post-update
> 
> И потом это заливается в people ?
> 
> > Поэтому, когда я хочу выложить что-то, то выполняю git-push up что-то.
> Как это /другое/место/name.git администрируется?  Какие hooks
> используются?

Это индивидуально.  Я пока использую только hooks/update (который авторам
лучше было бы назвать hooks/pre-update), но это может измениться.

Пока на серверной стороне нет git'а, выкладываю обычным rsync-over-ssh'ем.
hooks, кстати говоря, для readonly доступа можно не выкладывать.

> Есть мнение, что в post-update вызывается не
> только update-server-info (потому как в .git/objects/??/ пусто
> обычно)...

Нет,
git-prune && git-repack -a -d -q
я пока что запускаю вручную.  Ещё предстоит подумать, как это лучше
автоматизировать, может и post-update сгодится.

> Ну опиши пожалуйста примерный цикл работы с этим всем...

Да нет ещё сложившегося цикла, есть творческий поиск.


-- 
ldv

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

Re: [devel] sandman vs. hasher+gear

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [060510 15:01]:
> git-prune && git-repack -a -d -q
> я пока что запускаю вручную.
GIT_DIR=/path/to/project.git git-repack -a -d -q ?

> Ещё предстоит подумать, как это лучше автоматизировать, может и
> post-update сгодится.
В случае удалённого ssh:// репозитария, как я понимаю, это
решается только hook'ами?

Как в этом случае рулить этими hook'ами в удалённом репозитарии
(есть в git встроенный механизм для этого)?

> > Ну опиши пожалуйста примерный цикл работы с этим всем...
> Да нет ещё сложившегося цикла, есть творческий поиск.
Микроскопом удобно забивать гвозди.  Он тяжёлый, есть что-то типа
ручки.  Но есть люди, которые знают что микроскоп для этого не
очень предназначен, а гвозди забивать лучше молотком.  А кто
этого не знает - может привыкнуть к микроскопу и переучиваться на
молоток будет потом трудно...

Наличие техпаспорта у микроскопа и молотка это хорошо, можно
узнать все их параметры.  Но вот ещё бы книжку какую почитать,
как мальчик при помощи молотка построил дом или как девочка при
помощи микроскопа нашла холерную палочку в местном водоёме и
спасла жителей своего района...

/u/s/dic/git-*/howto* хорошо, но мало ;-)

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] sandman vs. hasher+gear

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 03:36:36PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060510 15:01]:
> > git-prune && git-repack -a -d -q
> > я пока что запускаю вручную.
> GIT_DIR=/path/to/project.git git-repack -a -d -q ?

Возможно, что GIT_DIR переопределять не надо.

> > Ещё предстоит подумать, как это лучше автоматизировать, может и
> > post-update сгодится.
> В случае удалённого ssh:// репозитария, как я понимаю, это
> решается только hook'ами?

Видимо.

> Как в этом случае рулить этими hook'ами в удалённом репозитарии
> (есть в git встроенный механизм для этого)?

hook'и не являются частью того репозитория, который они обслуживают.
Я не слышал о таких механизмах.


-- 
ldv

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

Re: [devel] sandman vs. hasher+gear

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 04:21:01PM +0400, Dmitry V. Levin wrote:
> On Wed, May 10, 2006 at 03:36:36PM +0400, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@> [060510 15:01]:
> > > git-prune && git-repack -a -d -q
> > > я пока что запускаю вручную.
> > GIT_DIR=/path/to/project.git git-repack -a -d -q ?
> 
> Возможно, что GIT_DIR переопределять не надо.

Да, достаточно одной строчки:
git-prune && git-repack -a -d


-- 
ldv

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

Re: [devel] sandman vs. hasher+gear

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [060510 16:59]:
> > > > git-prune && git-repack -a -d -q
> > > > я пока что запускаю вручную.
> > > GIT_DIR=/path/to/project.git git-repack -a -d -q ?
> > Возможно, что GIT_DIR переопределять не надо.
> Да, достаточно одной строчки:
> git-prune && git-repack -a -d
Стоя в /path/to/project.git или в рабочей копии и потом это
push'нется ?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] sandman vs. hasher+gear

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 05:07:52PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060510 16:59]:
> > > > > git-prune && git-repack -a -d -q
> > > > > я пока что запускаю вручную.
> > > > GIT_DIR=/path/to/project.git git-repack -a -d -q ?
> > > Возможно, что GIT_DIR переопределять не надо.
> > Да, достаточно одной строчки:
> > git-prune && git-repack -a -d
> Стоя в /path/to/project.git или в рабочей копии и потом это
> push'нется ?

Нет, в post-update, перед exec'ом.


-- 
ldv

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

Re: [devel] git-prune/git-repack costs

[Dmitry V. Levin]

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

On Wed, May 10, 2006 at 05:28:24PM +0400, Dmitry V. Levin wrote:
> On Wed, May 10, 2006 at 05:07:52PM +0400, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@> [060510 16:59]:
> > > > > > git-prune && git-repack -a -d -q
> > > > > > я пока что запускаю вручную.
> > > > > GIT_DIR=/path/to/project.git git-repack -a -d -q ?
> > > > Возможно, что GIT_DIR переопределять не надо.
> > > Да, достаточно одной строчки:
> > > git-prune && git-repack -a -d
> > Стоя в /path/to/project.git или в рабочей копии и потом это
> > push'нется ?
> 
> Нет, в post-update, перед exec'ом.

Сейчас у меня в post-update написано так:
git-prune && git-repack -a -d && git-update-server-info

Должен заметить, что на репозитории packages/gcc3.4.git размером 42M
(в нём все 13 сборок пакета gcc3.4) эта операция (git-prune + git-repack)
потребляет заметное количество ресурсов.  Сервер, выполняющий сейчас
обязанности devel.altlinux.org, ляжет очень быстро, если каждый мантейнер
будет выполнять эту операцию по своему разумению.

Да, это новая редакция репозитория, в котором все тарболлы были развёрнуты
при импорте утилитой git-srpmimport.  На прежней редакции, в которой
хранились тарболлы, git-repack -a -d потреблял гораздо больше ресурсов при
обработке столь больших репозиториев.


-- 
ldv

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

Re: [devel] git-prune/git-repack costs

[Sergey Vlasov]

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

On Sat, May 27, 2006 at 01:02:21AM +0400, Dmitry V. Levin wrote:
> On Wed, May 10, 2006 at 05:28:24PM +0400, Dmitry V. Levin wrote:
> > On Wed, May 10, 2006 at 05:07:52PM +0400, Alexey I. Froloff wrote:
> > > * Dmitry V. Levin <ldv@> [060510 16:59]:
> > > > > > > git-prune && git-repack -a -d -q
> > > > > > > я пока что запускаю вручную.
> > > > > > GIT_DIR=/path/to/project.git git-repack -a -d -q ?
> > > > > Возможно, что GIT_DIR переопределять не надо.
> > > > Да, достаточно одной строчки:
> > > > git-prune && git-repack -a -d
> > > Стоя в /path/to/project.git или в рабочей копии и потом это
> > > push'нется ?
> > 
> > Нет, в post-update, перед exec'ом.
> 
> Сейчас у меня в post-update написано так:
> git-prune && git-repack -a -d && git-update-server-info
> 
> Должен заметить, что на репозитории packages/gcc3.4.git размером 42M
> (в нём все 13 сборок пакета gcc3.4) эта операция (git-prune + git-repack)
> потребляет заметное количество ресурсов.  Сервер, выполняющий сейчас
> обязанности devel.altlinux.org, ляжет очень быстро, если каждый мантейнер
> будет выполнять эту операцию по своему разумению.

Вообще-то обычно делают git-repack -a -d && git-prune-packed.
git-prune - действительно очень ресурсоёмкая операция, но она нужна
только в том случае, если в репозитории по каким-то причинам появились
объекты, на которые нет ссылок.  Кроме того, необходимо, чтобы при
выполнении git-prune никто не писал в репозиторий (иначе только что
добавленные объекты могут быть удалены, поскольку в этот момент на них
ещё нет ссылок).

На самом деле даже git-prune-packed может помешать выполняющимся
параллельно операциям с репозиторием (если в момент начала операции
git-repack ещё не успел создать новый pack-файл, а через некоторое
время потребовались объекты, которые были помещены в новый pack и
удалены git-prune-packed).

Кроме того, если постоянно выполнять git-repack -a -d, нужно делать
доступ через git daemon - нормально работать через http или rsync в
таких условиях невозможно (при каждом git fetch всё будет скачиваться
заново).

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

Re: [devel] git-prune/git-repack costs

[Dmitry V. Levin]

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

On Sat, May 27, 2006 at 12:24:27PM +0400, Sergey Vlasov wrote:
[...]
> Вообще-то обычно делают git-repack -a -d && git-prune-packed.

Я так понимаю, что если git-repack запускается с ключами -a -d, то
git-prune-packed уже запускать незачем.

> git-prune - действительно очень ресурсоёмкая операция, но она нужна
> только в том случае, если в репозитории по каким-то причинам появились
> объекты, на которые нет ссылок.  Кроме того, необходимо, чтобы при
> выполнении git-prune никто не писал в репозиторий (иначе только что
> добавленные объекты могут быть удалены, поскольку в этот момент на них
> ещё нет ссылок).

git-repack -a -- тоже очень ресурсоёмкая операция, особенно на больших
файлах типа gcc-4.1.1-20060525.tar;  видимо, алгоритм реализован
неоптимально с точки зрения потребляемых ресурсов.

> Кроме того, если постоянно выполнять git-repack -a -d, нужно делать
> доступ через git daemon - нормально работать через http или rsync в
> таких условиях невозможно (при каждом git fetch всё будет скачиваться
> заново).

Это безусловно так.

Но с git-daemon (равно как и с git-shell) есть одна проблема:
$ grep -rw strcpy git-1.3.3 |wc -l
112
$ grep -rw sprintf git-1.3.3 |wc -l
129
Один только exec_cmd.c чего стоит...  Я в шоке.


-- 
ldv

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

Re: [devel] git-prune/git-repack costs

[Sergey Vlasov]

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

On Sun, May 28, 2006 at 03:31:47AM +0400, Dmitry V. Levin wrote:
> On Sat, May 27, 2006 at 12:24:27PM +0400, Sergey Vlasov wrote:
> [...]
> > Вообще-то обычно делают git-repack -a -d && git-prune-packed.
> 
> Я так понимаю, что если git-repack запускается с ключами -a -d, то
> git-prune-packed уже запускать незачем.

Нет, git-prune-packed как раз нужен - git-repack -a -d удаляет только
старые pack-файлы, но не трогает неупакованные объекты, которые как
раз и занимают кучу места.

> > git-prune - действительно очень ресурсоёмкая операция, но она нужна
> > только в том случае, если в репозитории по каким-то причинам появились
> > объекты, на которые нет ссылок.  Кроме того, необходимо, чтобы при
> > выполнении git-prune никто не писал в репозиторий (иначе только что
> > добавленные объекты могут быть удалены, поскольку в этот момент на них
> > ещё нет ссылок).
> 
> git-repack -a -- тоже очень ресурсоёмкая операция, особенно на больших
> файлах типа gcc-4.1.1-20060525.tar;  видимо, алгоритм реализован
> неоптимально с точки зрения потребляемых ресурсов.

Вообще этот алгоритм пытались править - сейчас в ветке master всё это
сильно переписано.

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

Re: [devel] git-prune/git-repack costs

[Dmitry V. Levin]

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

On Sun, May 28, 2006 at 12:35:12PM +0400, Sergey Vlasov wrote:
> On Sun, May 28, 2006 at 03:31:47AM +0400, Dmitry V. Levin wrote:
> > On Sat, May 27, 2006 at 12:24:27PM +0400, Sergey Vlasov wrote:
> > [...]
> > > Вообще-то обычно делают git-repack -a -d && git-prune-packed.
> > 
> > Я так понимаю, что если git-repack запускается с ключами -a -d, то
> > git-prune-packed уже запускать незачем.
> 
> Нет, git-prune-packed как раз нужен - git-repack -a -d удаляет только
> старые pack-файлы, но не трогает неупакованные объекты, которые как
> раз и занимают кучу места.

Не знаю, может manpage и написан таким образом, но по факту по окончанию
git-repack -a -d ни одного неупакованного объекта не остаётся.

> > > git-prune - действительно очень ресурсоёмкая операция, но она нужна
> > > только в том случае, если в репозитории по каким-то причинам появились
> > > объекты, на которые нет ссылок.  Кроме того, необходимо, чтобы при
> > > выполнении git-prune никто не писал в репозиторий (иначе только что
> > > добавленные объекты могут быть удалены, поскольку в этот момент на них
> > > ещё нет ссылок).
> > 
> > git-repack -a -- тоже очень ресурсоёмкая операция, особенно на больших
> > файлах типа gcc-4.1.1-20060525.tar;  видимо, алгоритм реализован
> > неоптимально с точки зрения потребляемых ресурсов.
> 
> Вообще этот алгоритм пытались править - сейчас в ветке master всё это
> сильно переписано.

Вот когда master превратится в maint, тогда я буду "всё это" тестировать.


-- 
ldv

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

Re: [devel] git-prune/git-repack costs

[Sergey Vlasov]

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

On Sun, May 28, 2006 at 06:11:34PM +0400, Dmitry V. Levin wrote:
> On Sun, May 28, 2006 at 12:35:12PM +0400, Sergey Vlasov wrote:
> > On Sun, May 28, 2006 at 03:31:47AM +0400, Dmitry V. Levin wrote:
> > > On Sat, May 27, 2006 at 12:24:27PM +0400, Sergey Vlasov wrote:
> > > [...]
> > > > Вообще-то обычно делают git-repack -a -d && git-prune-packed.
> > > 
> > > Я так понимаю, что если git-repack запускается с ключами -a -d, то
> > > git-prune-packed уже запускать незачем.
> > 
> > Нет, git-prune-packed как раз нужен - git-repack -a -d удаляет только
> > старые pack-файлы, но не трогает неупакованные объекты, которые как
> > раз и занимают кучу места.
> 
> Не знаю, может manpage и написан таким образом, но по факту по окончанию
> git-repack -a -d ни одного неупакованного объекта не остаётся.

Хм, действительно.  Просто по -d автоматом вызывается git-prune-packed (и
в свежем мане это уже документировано).

Но в любом случае git-prune по каждому чиху - это перебор.

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

Re: [devel] git-prune/git-repack costs

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [060527 01:51]:
> Сейчас у меня в post-update написано так:
> git-prune && git-repack -a -d && git-update-server-info
У меня будет просьба личного характера.  Пока не появился git://
или ssh://, можно убрать -a из git-repack?  Ну очень не хочется
при каждом изменении тянуть всё по новой...

P.S. Просьба ко всем.

-- 
Regards,
Sir Raorn.

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