[devel] gear -- создание тарбола из другого branch

[devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

Можно ли с помощью gear создавать тарболл по тэгу, например, а не из
каталога? Это позволило бы избавиться от каши, когда приходится в одном
пакете использовать несколько svn-репозиториев.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Это вам не шуточки, такие изменения тестировать надо по полной программе.
		-- ldv in devel@

Re: [devel] gear -- создание тарбола из другого branch

[Alexey Tourbin]

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

On Thu, Sep 21, 2006 at 11:20:20PM +0400, Денис Смирнов wrote:
> Можно ли с помощью gear создавать тарболл по тэгу, например, а не из
> каталога? Это позволило бы избавиться от каши, когда приходится в одном
> пакете использовать несколько svn-репозиториев.

Что ты хочешь сделать?

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

On Fri, Sep 22, 2006 at 09:57:17AM +0400, Алексей Турбин wrote:

>> Можно ли с помощью gear создавать тарболл по тэгу, например, а не из
>> каталога? Это позволило бы избавиться от каши, когда приходится в одном
>> пакете использовать несколько svn-репозиториев.
AT> Что ты хочешь сделать?

Паковать asterisk.
В svn он лежит прямо в корне. Соответственно в ветке master я вынужден
делать на все файлы git mv. При каждом очередном переименовании или
добавлении новых файлов я имею геморрой.

Я хочу прекратить использовать git mv для смены расположения файлов в
репозитории.

Кроме того астериск собирается сразу их 3-х репозиториев -- mxml,
menuselect и asterisk. Их надо раскладывать по разным каталогам. Я бы
предпочел делать это уже в spec-файле.

В настоящий момент использовать gear для формирования тарболлов мне куда
менее удобно, чем иметь отдельный svn репозиторий, с которого бы простым
скриптом формировать тарболы.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Некоторые, между прочим, и buildreq в hasher'е запускают. :)
		-- ldv in sisyphus@

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Fri, Sep 22, 2006 at 02:44:27PM +0400, Денис Смирнов wrote:
> On Fri, Sep 22, 2006 at 09:57:17AM +0400, Алексей Турбин wrote:
> 
> >> Можно ли с помощью gear создавать тарболл по тэгу, например, а не из
> >> каталога?

Нет, это уже обсуждалось, когда Raorn предлагал.
К сожалению, это нарушило бы главное свойство gear - воспроизводимость:
из того же самого commit object после изменения тэга будет собран другой
тарболл.

> Это позволило бы избавиться от каши, когда приходится в одном
> >> пакете использовать несколько svn-репозиториев.
> AT> Что ты хочешь сделать?
> 
> Паковать asterisk.
> В svn он лежит прямо в корне. Соответственно в ветке master я вынужден
> делать на все файлы git mv. При каждом очередном переименовании или
> добавлении новых файлов я имею геморрой.
> 
> Я хочу прекратить использовать git mv для смены расположения файлов в
> репозитории.

Это вполне логичное желание.
Если asterisk лежит в svn прямо в корне, то в git его тоже можно хранить
прямо в корне.  Хотя иногда это ограничивает возможности.

> Кроме того астериск собирается сразу их 3-х репозиториев -- mxml,
> menuselect и asterisk. Их надо раскладывать по разным каталогам. Я бы
> предпочел делать это уже в spec-файле.

Как это из 3-х репозиториев - из 3-х тарболлов?

> В настоящий момент использовать gear для формирования тарболлов мне куда
> менее удобно, чем иметь отдельный svn репозиторий, с которого бы простым
> скриптом формировать тарболы.

Только эти тарболлы ничего не связывает, поскольку они получены из разных
репозиториев.  Надо найти способ импортировать их в один репозиторий.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

On Sat, Sep 23, 2006 at 03:37:40AM +0400, Dmitry V. Levin wrote:

DVL> Нет, это уже обсуждалось, когда Raorn предлагал.
DVL> К сожалению, это нарушило бы главное свойство gear - воспроизводимость:
DVL> из того же самого commit object после изменения тэга будет собран другой
DVL> тарболл.

Ясно :( И логично :(

Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
Но я не представляю себе какие side effects могут быть от такого.

>> Я хочу прекратить использовать git mv для смены расположения файлов в
>> репозитории.
DVL> Это вполне логичное желание.
DVL> Если asterisk лежит в svn прямо в корне, то в git его тоже можно хранить
DVL> прямо в корне.  Хотя иногда это ограничивает возможности.

Как тогда его паковать с помощью gear? Когда в отдельном каталоге все
понятно, а когда нет? Получается что .gear-rules и spec будут лежать в том
же каталоге где все остальное?

>> Кроме того астериск собирается сразу их 3-х репозиториев -- mxml,
>> menuselect и asterisk. Их надо раскладывать по разным каталогам. Я бы
>> предпочел делать это уже в spec-файле.
DVL> Как это из 3-х репозиториев - из 3-х тарболлов?

Хуже. У них 3 репозитория: asterisk, menuselect и mxml. Они используют
друг-друга (menuselect это доморощеный аналог menuconfig при сборке ядра,
mxml используемая им библиотека). Соответственно в svn у них используется
svn:external тэг. git-svn его, судя по всему, игнорирует. Поэтому
раскладывать мне приходится ручками.

>> В настоящий момент использовать gear для формирования тарболлов мне куда
>> менее удобно, чем иметь отдельный svn репозиторий, с которого бы простым
>> скриптом формировать тарболы.
DVL> Только эти тарболлы ничего не связывает, поскольку они получены из разных
DVL> репозиториев.  Надо найти способ импортировать их в один репозиторий.

Самое ещё веселое, что в svn:external по крайней мере сейчас у них лежит
ссылка не на тэг, а на транк этих библиотек, что делает процесс
объединения этого безобразия ещё более увлекательным.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Как обычно новое еще допиливать придется.
		-- zerg in devel@

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 12:40:03PM +0400, Денис Смирнов wrote:
> On Sat, Sep 23, 2006 at 03:37:40AM +0400, Dmitry V. Levin wrote:
> 
> DVL> Нет, это уже обсуждалось, когда Raorn предлагал.
> DVL> К сожалению, это нарушило бы главное свойство gear - воспроизводимость:
> DVL> из того же самого commit object после изменения тэга будет собран другой
> DVL> тарболл.
> 
> Ясно :( И логично :(
> 
> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.

Можно было бы указывать sha1-имя, но этим не очень удобно было бы
пользоваться.

> >> Я хочу прекратить использовать git mv для смены расположения файлов в
> >> репозитории.
> DVL> Это вполне логичное желание.
> DVL> Если asterisk лежит в svn прямо в корне, то в git его тоже можно хранить
> DVL> прямо в корне.  Хотя иногда это ограничивает возможности.
> 
> Как тогда его паковать с помощью gear? Когда в отдельном каталоге все
> понятно, а когда нет? Получается что .gear-rules и spec будут лежать в том
> же каталоге где все остальное?

Да, с простым правилом вроде
tar: .

> >> Кроме того астериск собирается сразу их 3-х репозиториев -- mxml,
> >> menuselect и asterisk. Их надо раскладывать по разным каталогам. Я бы
> >> предпочел делать это уже в spec-файле.
> DVL> Как это из 3-х репозиториев - из 3-х тарболлов?
> 
> Хуже. У них 3 репозитория: asterisk, menuselect и mxml. Они используют
> друг-друга (menuselect это доморощеный аналог menuconfig при сборке ядра,
> mxml используемая им библиотека). Соответственно в svn у них используется
> svn:external тэг. git-svn его, судя по всему, игнорирует.

Я слабо разбираюсь в git-svn, но по умолчанию брать из svn:external,
наверное, не надо.

> Поэтому раскладывать мне приходится ручками.

Можно скрипт написать.

> >> В настоящий момент использовать gear для формирования тарболлов мне куда
> >> менее удобно, чем иметь отдельный svn репозиторий, с которого бы простым
> >> скриптом формировать тарболы.
> DVL> Только эти тарболлы ничего не связывает, поскольку они получены из разных
> DVL> репозиториев.  Надо найти способ импортировать их в один репозиторий.
> 
> Самое ещё веселое, что в svn:external по крайней мере сейчас у них лежит
> ссылка не на тэг, а на транк этих библиотек, что делает процесс
> объединения этого безобразия ещё более увлекательным.

И недетерминированным. :)


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

On Sat, Sep 23, 2006 at 12:48:25PM +0400, Dmitry V. Levin wrote:

>> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
DVL> Можно было бы указывать sha1-имя, но этим не очень удобно было бы
DVL> пользоваться.

Можно и обертку к этому прикрутить (вроде "взять из тага"). Или ещё
интереснее -- класть в gear-rules и таг, и sha1-имя. Причем второе будет
автоматом обновлять gear, а в случае если уже есть, и не совпадает,
ругаться нехорошими словами при сборке.

А обновлять можно в том же gear-commit.

Таким образом будет удобно и человеку, и gear, и будет обеспечена
совместимость.

Только вот есть ли гарантия, что объект на который ссылаемся не будет по
какой-либо причине в будушем удален?

>> Как тогда его паковать с помощью gear? Когда в отдельном каталоге все
>> понятно, а когда нет? Получается что .gear-rules и spec будут лежать в том
>> же каталоге где все остальное?
DVL> Да, с простым правилом вроде
DVL> tar: .

То бишь в tar будет и spec с .gear-rules, так?

Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.

>> Хуже. У них 3 репозитория: asterisk, menuselect и mxml. Они используют
>> друг-друга (menuselect это доморощеный аналог menuconfig при сборке ядра,
>> mxml используемая им библиотека). Соответственно в svn у них используется
>> svn:external тэг. git-svn его, судя по всему, игнорирует.
DVL> Я слабо разбираюсь в git-svn, но по умолчанию брать из svn:external,
DVL> наверное, не надо.

По-умолчанию согласен. А не по-умолчанию? Я не нашел у него как это
включить.

>> Поэтому раскладывать мне приходится ручками.
DVL> Можно скрипт написать.

Я не представляю себе как это сделать.

Вот git-svn скачивает 3 репозитория. Их надо раскладывать по разным
каталогам. В них есть одинаковые имена (configure, например|. Я и ручками
после git pull из них трех не разберусь, как это сделать скриптом?

Плюс, как я уже говорил, я не до конца понимаю как отрабатывает pull если
в своей ветке я делал переименование, а в оригинальной оно так же было
произведено. Получается конфликт, который непонятно как разруливать не
смотря глазами в то, что должно было быть в svn.

Я пока вынужден использовать старую схему сборки тарбола из отдельного
svn-снапшота, вместо git :(

> >>> В настоящий момент использовать gear для формирования тарболлов мне куда
> >>> менее удобно, чем иметь отдельный svn репозиторий, с которого бы простым
> >>> скриптом формировать тарболы.
> DVL>> репозиториев.  Надо найти способ импортировать их в один репозиторий.
>> Самое ещё веселое, что в svn:external по крайней мере сейчас у них лежит
>> ссылка не на тэг, а на транк этих библиотек, что делает процесс
>> объединения этого безобразия ещё более увлекательным.
DVL> И недетерминированным. :)

Ага, оттого и увлекательным :) Я все-таки надеюсь что они сделают хотя бы
бранчи, и, соответственно, ссылки на них. Иначе я совсем с ума сойду.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Я - за. Но я знаю людей, которые будут против. ;-(
		-- rider in devel@

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 01:19:57PM +0400, Денис Смирнов wrote:
> On Sat, Sep 23, 2006 at 12:48:25PM +0400, Dmitry V. Levin wrote:
> 
> >> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
> DVL> Можно было бы указывать sha1-имя, но этим не очень удобно было бы
> DVL> пользоваться.
> 
> [...]
> Только вот есть ли гарантия, что объект на который ссылаемся не будет по
> какой-либо причине в будушем удален?

К сожалению, гарантии нет, что сводит всю идею на нет.

> >> Как тогда его паковать с помощью gear? Когда в отдельном каталоге все
> >> понятно, а когда нет? Получается что .gear-rules и spec будут лежать в том
> >> же каталоге где все остальное?
> DVL> Да, с простым правилом вроде
> DVL> tar: .
> 
> То бишь в tar будет и spec с .gear-rules, так?
> 
> Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.

Некрасиво?  Почему?  Кто на этот tar будет смотреть?

[...]
> >> Поэтому раскладывать мне приходится ручками.
> DVL> Можно скрипт написать.
> 
> Я не представляю себе как это сделать.
> 
> Вот git-svn скачивает 3 репозитория. Их надо раскладывать по разным
> каталогам. В них есть одинаковые имена (configure, например|. Я и ручками
> после git pull из них трех не разберусь, как это сделать скриптом?

Да, с подкаталогами было бы удобнее.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sat, Sep 23, 2006 at 06:07:47PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 23, 2006 at 01:19:57PM +0400, Денис Смирнов wrote:
> > On Sat, Sep 23, 2006 at 12:48:25PM +0400, Dmitry V. Levin wrote:
> > 
> > >> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
> > DVL> Можно было бы указывать sha1-имя, но этим не очень удобно было бы
> > DVL> пользоваться.

Либо завести рядом с .gear-rules файл .gear-tags, в который класть
записи вида "sha1 name", и при разборе .gear-rules использовать только
имена из этого файла.  Причём, кроме этих имён в чистом виде, хорошо
бы разрешить и конструкции вида treeish:some/path (а, возможно, и
ссылки на родительские коммиты через ^ и ~ - правда, на них можно
повлиять через .git/info/grafts).

> > Только вот есть ли гарантия, что объект на который ссылаемся не будет по
> > какой-либо причине в будушем удален?
> 
> К сожалению, гарантии нет, что сводит всю идею на нет.

Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
(через git-pull -s ours) мержить бранчи, содержащие реальные
исходники; тогда гарантировать наличие нужных объектов будет связь
между коммитами.

В этом случае неплохо было бы, чтобы gear проверял наличие этой связи;
тогда придётся в параметре опции -t требовать не просто treeish, а
commitish[:path].

> > То бишь в tar будет и spec с .gear-rules, так?
> > 
> > Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.
> 
> Некрасиво?  Почему?  Кто на этот tar будет смотреть?

А когда у нас по плану уничтожение src.rpm?  Пока это не произойдёт,
смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
может содержать непонятно что вместо оригинальных исходников.

> > Вот git-svn скачивает 3 репозитория. Их надо раскладывать по разным
> > каталогам. В них есть одинаковые имена (configure, например|. Я и ручками
> > после git pull из них трех не разберусь, как это сделать скриптом?
> 
> Да, с подкаталогами было бы удобнее.

Теоретически можно было бы написать собственную стратегию для merge,
но тогда надо как-то передавать ей параметры, а нормальных средств для
этого не предусмотрено (разве что SOME_VAR=... git-pull -s my ...).

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> On Sat, Sep 23, 2006 at 06:07:47PM +0400, Dmitry V. Levin wrote:
> > On Sat, Sep 23, 2006 at 01:19:57PM +0400, Денис Смирнов wrote:
> > > On Sat, Sep 23, 2006 at 12:48:25PM +0400, Dmitry V. Levin wrote:
> > > 
> > > >> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
> > > DVL> Можно было бы указывать sha1-имя, но этим не очень удобно было бы
> > > DVL> пользоваться.
> 
> Либо завести рядом с .gear-rules файл .gear-tags, в который класть
> записи вида "sha1 name", и при разборе .gear-rules использовать только
> имена из этого файла.  Причём, кроме этих имён в чистом виде, хорошо
> бы разрешить и конструкции вида treeish:some/path

Это всё сделать относительно несложно.

> (а, возможно, и
> ссылки на родительские коммиты через ^ и ~ - правда, на них можно
> повлиять через .git/info/grafts).

Это уже, наверное, перебор.

> > > Только вот есть ли гарантия, что объект на который ссылаемся не будет по
> > > какой-либо причине в будушем удален?
> > 
> > К сожалению, гарантии нет, что сводит всю идею на нет.
> 
> Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> (через git-pull -s ours) мержить бранчи, содержащие реальные
> исходники; тогда гарантировать наличие нужных объектов будет связь
> между коммитами.
> 
> В этом случае неплохо было бы, чтобы gear проверял наличие этой связи;
> тогда придётся в параметре опции -t требовать не просто treeish, а
> commitish[:path].

Точно.  Эта проверка просто необходима для поддержки .gear-tags.

По моему, идея выглядит вполне живой.

> > > То бишь в tar будет и spec с .gear-rules, так?
> > > 
> > > Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.
> > 
> > Некрасиво?  Почему?  Кто на этот tar будет смотреть?
> 
> А когда у нас по плану уничтожение src.rpm?

Как только перейдём на сборку из gear-репозиториев.  Насколько я понимаю,
srpm-пакеты из /i/S будут srpmimport'иться и с этого момента srpm-пакеты
выкладываться перестанут.

> Пока это не произойдёт,
> смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
> может содержать непонятно что вместо оригинальных исходников.

Вместо оригинальных исходников всегда можно положить что угодно.
Будем рассчитывать на здравый смысл, хотя было бы здорово найти способ
определения степени нативности (не tar-файлов, а содержимого
gear-репозитория).


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Aleksey Avdeev]

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

Dmitry V. Levin пишет:
> On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> 
...
>>Пока это не произойдёт,
>>смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
>>может содержать непонятно что вместо оригинальных исходников.
> 
> 
> Вместо оригинальных исходников всегда можно положить что угодно.
> Будем рассчитывать на здравый смысл, хотя было бы здорово найти способ
> определения степени нативности (не tar-файлов, а содержимого
> gear-репозитория).

  GPG подписи для commit`ов/тагов?

  Но это только для разработки в рамках git будет возможно, втянутое из
вне (svn/cvs) может подписать только втянувший, а не закоммитевший во
внешний источник.

-- 

С уважением. Алексей.


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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 08:04:22PM +0400, Aleksey Avdeev wrote:
> Dmitry V. Levin пишет:
> > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> ...
> >>Пока это не произойдёт,
> >>смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
> >>может содержать непонятно что вместо оригинальных исходников.
> > 
> > Вместо оригинальных исходников всегда можно положить что угодно.
> > Будем рассчитывать на здравый смысл, хотя было бы здорово найти способ
> > определения степени нативности (не tar-файлов, а содержимого
> > gear-репозитория).
> 
>   GPG подписи для commit`ов/тагов?

Это способ проверить авторство тэгов.
Под нативностью подразумевается соответствие с кодом, который выпускает
upstream.  Поскольку при помещении в gear-репозиторий идентичность
несколько утрачивается (как минимум не сохраняются даты модификации
файлов), стандартные механизмы проверки (upstream'ные .sig файлы) не
годятся, нужно найти что-то более подходящее.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Michael Shigorin]

On Sat, Sep 23, 2006 at 08:16:34PM +0400, Dmitry V. Levin wrote:
> Под нативностью подразумевается соответствие с кодом, который
> выпускает upstream.  Поскольку при помещении в gear-репозиторий
> идентичность несколько утрачивается (как минимум не сохраняются
> даты модификации файлов), стандартные механизмы проверки
> (upstream'ные .sig файлы) не годятся, нужно найти что-то более
> подходящее.

Проверять (выколупывать для проверки) до утраты?

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
[...]
> > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > исходники; тогда гарантировать наличие нужных объектов будет связь
> > между коммитами.

И, кстати, gitk при этом быстро отображает пустой diff (в отличие от
merge с переименованием в подкаталог, для которых он очень долго
формирует километровый diff).  Правда, если в этом же коммите
поменять, например spec, получается не совсем красиво - видимо, это
лучше делать отдельным коммитом без merge.

> > В этом случае неплохо было бы, чтобы gear проверял наличие этой связи;
> > тогда придётся в параметре опции -t требовать не просто treeish, а
> > commitish[:path].
> 
> Точно.  Эта проверка просто необходима для поддержки .gear-tags.
> 
> По моему, идея выглядит вполне живой.

Только получается, что в .gear-tags придётся писать ссылки именно на
commit - ссылку на объект типа tag написать уже нельзя.

> > А когда у нас по плану уничтожение src.rpm?
> 
> Как только перейдём на сборку из gear-репозиториев.  Насколько я понимаю,
> srpm-пакеты из /i/S будут srpmimport'иться и с этого момента srpm-пакеты
> выкладываться перестанут.

Ну и в каком виде пойдут исходники, например, в Uranus?

> > Пока это не произойдёт,
> > смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
> > может содержать непонятно что вместо оригинальных исходников.
> 
> Вместо оригинальных исходников всегда можно положить что угодно.

Проблема в том, что при использовании gear зачастую это "что угодно"
лежит в src.rpm под именем %name-%version.tar без всяких прочих
признаков того, что оно отличается от оригинала:

git $ git-diff --stat maint master
 .gear-rules                     |    1 
 Documentation/config.txt        |    2 
 Documentation/core-tutorial.txt |    2 
 Documentation/cvs-migration.txt |    2 
 Documentation/tutorial-2.txt    |    2 
 builtin-tar-tree.c              |    2 
 describe.c                      |    4 
 diff.c                          |   18 +-
 git.c                           |    4 
 git.spec                        |  360 ++++++++++++++++++++++++++++++++
 linkify.c                       |  444 +++++++++++++++++++++++++++++++++++++++
 merge-tree.c                    |    4 
 pager.c                         |    2 
 templates/hooks--update         |  149 +++++++++----
 14 files changed, 935 insertions(+), 61 deletions(-)


Не стоит ли в этом случае, например, называть этот файл
%name-%version-%release.tar?

(Хм, а git-tar-tree у нас ещё и нестандартный - в нём прибито гвоздями
umask 022, причём без возможности изменить это через tar.umask в
конфиге...   Не лучше ли, раз уж так хочется видеть такой umask,
просто изменить начальное значение tar_umask?  Да и документировано
это изменение только в changelog пакета.)

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> [...]
> > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > между коммитами.
[...]
> Только получается, что в .gear-tags придётся писать ссылки именно на
> commit - ссылку на объект типа tag написать уже нельзя.

Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
Похоже что заполнение .gear-tags вручную получается нереально сложным
занятием, так что потребуется вспомогательный инструмент.

> > > А когда у нас по плану уничтожение src.rpm?
> > 
> > Как только перейдём на сборку из gear-репозиториев.  Насколько я понимаю,
> > srpm-пакеты из /i/S будут srpmimport'иться и с этого момента srpm-пакеты
> > выкладываться перестанут.
> 
> Ну и в каком виде пойдут исходники, например, в Uranus?

Поскольку мои пакеты уже несколько месяцев собираются из
gear-репозиториев, соответствующие им srpm-пакеты уже не являются
полноценным источником исходного кода: собирать из них можно, а вот
извлечь pristine sources можно не во всех случаях.
Так что ответ один остаётся: gear-репозитории.
Или есть другие варианты?

> > > Пока это не произойдёт,
> > > смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
> > > может содержать непонятно что вместо оригинальных исходников.
> > 
> > Вместо оригинальных исходников всегда можно положить что угодно.
> 
> Проблема в том, что при использовании gear зачастую это "что угодно"
> лежит в src.rpm под именем %name-%version.tar без всяких прочих
> признаков того, что оно отличается от оригинала:
> 
> git $ git-diff --stat maint master
>  .gear-rules                     |    1 
>  Documentation/config.txt        |    2 
>  Documentation/core-tutorial.txt |    2 
>  Documentation/cvs-migration.txt |    2 
>  Documentation/tutorial-2.txt    |    2 
>  builtin-tar-tree.c              |    2 
>  describe.c                      |    4 
>  diff.c                          |   18 +-
>  git.c                           |    4 
>  git.spec                        |  360 ++++++++++++++++++++++++++++++++
>  linkify.c                       |  444 +++++++++++++++++++++++++++++++++++++++
>  merge-tree.c                    |    4 
>  pager.c                         |    2 
>  templates/hooks--update         |  149 +++++++++----
>  14 files changed, 935 insertions(+), 61 deletions(-)
> 
> 
> Не стоит ли в этом случае, например, называть этот файл
> %name-%version-%release.tar?

Стоит, наверное, это совсем несложно сделать.

> (Хм, а git-tar-tree у нас ещё и нестандартный - в нём прибито гвоздями
> umask 022, причём без возможности изменить это через tar.umask в
> конфиге...   Не лучше ли, раз уж так хочется видеть такой umask,
> просто изменить начальное значение tar_umask?

Лучше, наверное.

> Да и документировано это изменение только в changelog пакета.)

OK, я поправлю и документирую начальное значение tar_umask.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:

DVL> Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
DVL> Похоже что заполнение .gear-tags вручную получается нереально сложным
DVL> занятием, так что потребуется вспомогательный инструмент.

Дык а не подходит предложеный мною вариант, когда туда человек будет
писать tag, а уже сам gear будет править на sha1-имя, которое и будет
реально храниться вместе с tabname?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Это политический вопрос, я бы не хотел в него ввязываться.
		-- ldv in #7755

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 23, 2006 at 11:36:07PM +0400, Денис Смирнов wrote:
> On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> 
> DVL> Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
> DVL> Похоже что заполнение .gear-tags вручную получается нереально сложным
> DVL> занятием, так что потребуется вспомогательный инструмент.
> 
> Дык а не подходит предложеный мною вариант, когда туда человек будет
> писать tag, а уже сам gear будет править на sha1-имя, которое и будет
> реально храниться вместе с tabname?

Для того чтобы гарантировать целостность, sha1-имя commit-объекта,
являющегося предком, должно быть за'commit'ено.
Таким образом, нужен инструмент, который по commit-ish вычислит sha1-имя,
проверит отношение наследства и запишет необходимую информацию в .gear-tags.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> > [...]
> > > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > > между коммитами.
> [...]
> > Только получается, что в .gear-tags придётся писать ссылки именно на
> > commit - ссылку на объект типа tag написать уже нельзя.
> 
> Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.

Сам объект tag тоже может содержать информацию (хотя для сборки пакета
она вряд ли нужна).  Конечно, можно положить в .gear-tags и ссылку на
tag, но реально использовать её для сборки нельзя.

Кроме того, результат git-tar-tree зависит от того, какой именно
объект (tag, commit, tree) ему передали, даже в том случае, если
реально объект tree один и тот же.  Лучше передавать как минимум
commit, если это возможно - в этом случае в создаваемом архиве время
модификации файлов устанавливается по времени, взятом из commit, а не
по текущему.

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

Re: [devel] gear -- создание тарбола из другого branch

[Michael Shigorin]

On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> > Ну и в каком виде пойдут исходники, например, в Uranus?
> Так что ответ один остаётся: gear-репозитории.
> Или есть другие варианты?

SRPMS?

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> > [...]
> > > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > > между коммитами.
> [...]
> > Только получается, что в .gear-tags придётся писать ссылки именно на
> > commit - ссылку на объект типа tag написать уже нельзя.
> 
> Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.

На самом деле, если подумать, можно сделать и ссылку на tag.

Действительно, в объект типа commit или tree нельзя непосредственно
положить ссылку на объект типа tag.  Но никто не может запретить
прочитать содержимое объекта типа tag и положить его в объект типа
blob.  Таким образом, можно сделать .gear-tags не файлом, а каталогом,
куда складывать копии тегов.

Если ссылка указывала напрямую на commit, можно класть туда просто
sha1 (его всегда можно отличить от содержимого объекта tag).  Цепочку
объектов tag тоже можно сохранить - например, поместив второй и
последующие теги в цепочке под именами вида @<sha1> (символ '@' в
именах ссылок встречаться не может).

При сборке можно создать во временном каталоге репозиторий, записать в
.git/objects/info/alternates текущее значение $GIT_DIR, после чего
перенаправить GIT_DIR во временный репозиторий и восстановить там
сохранённые объекты тегов через git-hash-object.

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Tue, Sep 26, 2006 at 11:01:02PM +0400, Sergey Vlasov wrote:
> On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> > On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> > > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> > > [...]
> > > > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > > > между коммитами.
> > [...]
> > > Только получается, что в .gear-tags придётся писать ссылки именно на
> > > commit - ссылку на объект типа tag написать уже нельзя.
> > 
> > Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
> 
> На самом деле, если подумать, можно сделать и ссылку на tag.
> 
> Действительно, в объект типа commit или tree нельзя непосредственно
> положить ссылку на объект типа tag.  Но никто не может запретить
> прочитать содержимое объекта типа tag и положить его в объект типа
> blob.  Таким образом, можно сделать .gear-tags не файлом, а каталогом,
> куда складывать копии тегов.
> 
> Если ссылка указывала напрямую на commit, можно класть туда просто
> sha1 (его всегда можно отличить от содержимого объекта tag).  Цепочку
> объектов tag тоже можно сохранить - например, поместив второй и
> последующие теги в цепочке под именами вида @<sha1> (символ '@' в
> именах ссылок встречаться не может).

Похоже, проще оказывается складывать файлы с сохранённым содержимым
тегов не под оригинальными именами, а с именем, соответствующим их
sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
возиться с каталогами внутри .gear-tags).

В этом случае, если upstream также ведёт разработку с использованием
git, в release commit будут сохранены оригинальные теги (с подписями
GPG, если они там были).  Правда, на работу git-tar-tree это не влияет
(ссылка на тег всё равно сводится к commit даже в заголовке архива).

> При сборке можно создать во временном каталоге репозиторий, записать в
> .git/objects/info/alternates текущее значение $GIT_DIR, после чего
> перенаправить GIT_DIR во временный репозиторий и восстановить там
> сохранённые объекты тегов через git-hash-object.

Это в принципе работает (только подменять надо не GIT_DIR, а
GIT_OBJECT_DIRECTORY, чтобы не нужно было копировать .git/refs).
Правда, появляется ограничение - значение GIT_DIR не может содержать
символ '\n' (поскольку такой каталог невозможно записать в
objects/info/alternates).

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sat, Sep 30, 2006 at 11:30:55PM +0400, Sergey Vlasov wrote:
> On Tue, Sep 26, 2006 at 11:01:02PM +0400, Sergey Vlasov wrote:
> > On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> > > > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > > > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> > > > [...]
> > > > > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > > > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > > > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > > > > между коммитами.
> > > [...]
> > > > Только получается, что в .gear-tags придётся писать ссылки именно на
> > > > commit - ссылку на объект типа tag написать уже нельзя.
> > > 
> > > Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
> > 
> > На самом деле, если подумать, можно сделать и ссылку на tag.
> > 
> > Действительно, в объект типа commit или tree нельзя непосредственно
> > положить ссылку на объект типа tag.  Но никто не может запретить
> > прочитать содержимое объекта типа tag и положить его в объект типа
> > blob.  Таким образом, можно сделать .gear-tags не файлом, а каталогом,
> > куда складывать копии тегов.
> > 
> > Если ссылка указывала напрямую на commit, можно класть туда просто
> > sha1 (его всегда можно отличить от содержимого объекта tag).  Цепочку
> > объектов tag тоже можно сохранить - например, поместив второй и
> > последующие теги в цепочке под именами вида @<sha1> (символ '@' в
> > именах ссылок встречаться не может).
> 
> Похоже, проще оказывается складывать файлы с сохранённым содержимым
> тегов не под оригинальными именами, а с именем, соответствующим их
> sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
> возиться с каталогами внутри .gear-tags).

Если это будет не очень сложно, то можно сделать.
У кого-нибудь ещё есть мнения на эту тему?

> В этом случае, если upstream также ведёт разработку с использованием
> git, в release commit будут сохранены оригинальные теги (с подписями
> GPG, если они там были).  Правда, на работу git-tar-tree это не влияет
> (ссылка на тег всё равно сводится к commit даже в заголовке архива).
> 
> > При сборке можно создать во временном каталоге репозиторий, записать в
> > .git/objects/info/alternates текущее значение $GIT_DIR, после чего
> > перенаправить GIT_DIR во временный репозиторий и восстановить там
> > сохранённые объекты тегов через git-hash-object.
> 
> Это в принципе работает (только подменять надо не GIT_DIR, а
> GIT_OBJECT_DIRECTORY, чтобы не нужно было копировать .git/refs).
> Правда, появляется ограничение - значение GIT_DIR не может содержать
> символ '\n' (поскольку такой каталог невозможно записать в
> objects/info/alternates).

Я думаю, что это ограничение несущественно.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Wed, Oct 04, 2006 at 02:11:46AM +0400, Dmitry V. Levin wrote:
[...]
> > Похоже, проще оказывается складывать файлы с сохранённым содержимым
> > тегов не под оригинальными именами, а с именем, соответствующим их
> > sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
> > возиться с каталогами внутри .gear-tags).
> 
> Если это будет не очень сложно, то можно сделать.

Сделано:

git.alt:/people/vsu/packages/gear.git vsu/gear-tags-dir

Что сейчас в этом варианте можно делать в .gear-rules:

 - В директиве tar можно писать имя тега перед каталогом, в том числе
   с использованием подстановок:

	tar: @name@-@version@:.

   (добавлять ":.", если не нужно паковать только подкаталог,
   обязательно).  На самом деле в этом поле обрабатывается даже @dir@.

 - Добавлена директива diff:

	diff: @name@-@version@:. . name=@name@-@version@-@release@.patch

   Можно указывать commit:path и во втором параметре.  Также
   поддерживаются подстановки @old_dir@ и @new_dir@ (просто @dir@
   убрано, поскольку непонятно, к какому из имён относится этот
   вариант).  Значение name по умолчанию выбирается аналогично tar:

     - @new_dir@-@version@-@release@.patch - если @new_dir@ не '.';
     - @name@-@version@-@release@.patch - если в @new_dir@ '.' (так
       что в приведённом выше примере на самом деле не обязательно
       писать name).

   Также поддерживается опция spec.

Список имён заполняется утилитой gear-update-tag.  Если имена
соответствуют тегам, можно просто запустить gear-update-tag -ac (при
желании добавить -v) - при этом будут автоматически определены
используемые в .gear-rules имена, добавлены новые записи для них и
удалены устаревшие.  При необходимости можно обновлять теги и по
одному.

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Sun, Oct 15, 2006 at 08:08:18PM +0400, Sergey Vlasov wrote:
> On Wed, Oct 04, 2006 at 02:11:46AM +0400, Dmitry V. Levin wrote:
> [...]
> > > Похоже, проще оказывается складывать файлы с сохранённым содержимым
> > > тегов не под оригинальными именами, а с именем, соответствующим их
> > > sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
> > > возиться с каталогами внутри .gear-tags).
> > 
> > Если это будет не очень сложно, то можно сделать.
> 
> Сделано:
> 
> git.alt:/people/vsu/packages/gear.git vsu/gear-tags-dir

Спасибо.

$ git diff --stat master..vsu/gear-tags-dir
 Makefile              |    2 
 gear                  |  291 ++++++++++++++++--------
 gear-commit           |    6 -
 gear-sh-functions.in  |  388 ++++++++++++++++++++++++++++----
 gear-update-tag       |  585 +++++++++++++++++++++++++++++++++++++++++++++++++
 gear-update-tag.1.inc |   23 ++
 6 files changed, 1139 insertions(+), 156 deletions(-)

Ох, у меня, наверное, уйдёт целый день, чтобы всё это отсмотреть...


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Mon, Oct 16, 2006 at 02:21:34AM +0400, Dmitry V. Levin wrote:
> On Sun, Oct 15, 2006 at 08:08:18PM +0400, Sergey Vlasov wrote:
> > On Wed, Oct 04, 2006 at 02:11:46AM +0400, Dmitry V. Levin wrote:
> > [...]
> > > > Похоже, проще оказывается складывать файлы с сохранённым содержимым
> > > > тегов не под оригинальными именами, а с именем, соответствующим их
> > > > sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
> > > > возиться с каталогами внутри .gear-tags).
> > > 
> > > Если это будет не очень сложно, то можно сделать.
> > 
> > Сделано:
> > 
> > git.alt:/people/vsu/packages/gear.git vsu/gear-tags-dir
> 
> Спасибо.
> 
> $ git diff --stat master..vsu/gear-tags-dir
>  Makefile              |    2 
>  gear                  |  291 ++++++++++++++++--------
>  gear-commit           |    6 -
>  gear-sh-functions.in  |  388 ++++++++++++++++++++++++++++----
>  gear-update-tag       |  585 +++++++++++++++++++++++++++++++++++++++++++++++++
>  gear-update-tag.1.inc |   23 ++
>  6 files changed, 1139 insertions(+), 156 deletions(-)
> 
> Ох, у меня, наверное, уйдёт целый день, чтобы всё это отсмотреть...

Я посмотрел.  Всё выглядит логично, но код всё-таки стал существенно
сложнее для понимания.  Я не смог себя убедить в том, что gear не поведёт
себя странным образом, получив на входе репозиторий, содержащий .gear-rules
"специального вида", а это одна из двух основных характеристик gear.
Так что я смержил к себе в ldv/gear-tags-dir, осталось придумать способ
сделать код gear более доступным для анализа.  Может, разбить на более
мелкие файлы для изоляции взаимозависимых частей.


-- 
ldv

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

[devel] uranus

[Michael Shigorin]

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

> Ну и в каком виде пойдут исходники, например, в Uranus?

Кстати, на примере ряда фирм, так называвшихся, рекомендую
подумать над названием выпуска ещё немного.

Поскольку ICS пришлось менять название "Ай си эс",
а Uranus по телефону звучит как "ё анус".

PS: простите за.

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

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

Re: [devel] uranus

[Sergey Pinaev]

On Sun, 24 Sep 2006 01:55:09 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> > Ну и в каком виде пойдут исходники, например, в Uranus?
> 
> Кстати, на примере ряда фирм, так называвшихся, рекомендую
> подумать над названием выпуска ещё немного.
> 
> Поскольку ICS пришлось менять название "Ай си эс",
> а Uranus по телефону звучит как "ё анус".

Плутон там еще не реабилитировали? Если нет - давайте
"Pluto" обзовем? =)

-- 
mail="Sergey Pinaev <dfo@antex.ru>"
url="http://`echo $mail | sed 's/.* <\(.*\)@\(.*\)>/\1.\2/'`"

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> По моему, идея выглядит вполне живой.

Не вполне доделанная реализация выложена в
git.alt:vsu/packages/gear.git в бранч vsu/gear-tags; сейчас это
годится только для того, чтобы обругать.  Средства для обновления
.gear-tags, кроме /dev/hands, пока отсутствуют.

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Sun, Sep 24, 2006 at 11:14:10PM +0400, Sergey Vlasov wrote:
> On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > По моему, идея выглядит вполне живой.
> 
> Не вполне доделанная реализация выложена в
> git.alt:vsu/packages/gear.git в бранч vsu/gear-tags; сейчас это
> годится только для того, чтобы обругать.  Средства для обновления
> .gear-tags, кроме /dev/hands, пока отсутствуют.

Без описания никто даже смотреть не хочет?

Сейчас там сделано вот что:

 - Опция "-t ID" у gear теперь требует параметр в виде COMMIT[:PATH]
   (указание только объекта tree недостаточно - требуется ещё
   идентификатор соответствующего объекта commit).  Объект COMMIT
   используется при проверке допустимости ссылок на другие объекты.

 - Добавлена новая директива для .gear-rules:

     tags: PATH

   В параметре указывается путь к файлу тегов.  При отсутствии этой
   директивы файл тегов ищется под именем ".gear-tags".

 - Файл тегов состоит из строк в формате:

     SHA1 NAME

   Поддержки комментариев сейчас нет (и нужна ли она там?).

 - Для директив tar* доступна новая опция:

     tree=COMMIT[:PATH]

   При этом COMMIT может указываться в виде либо значения SHA-1, либо
   имени, присутствующего в файле тегов.  В значении опции могут
   использоваться элементы @name@, @version@, @release@, которые
   заменяются на соответствующую информацию, полученную из spec-файла.

 - Допустимость значений SHA1, указанных в файле тегов, сейчас
   проверяется по мере их использования; в принципе можно сделать и
   принудительную проверку всех SHA1 при обнаружении файла тегов.

Утилита для обновления .gear-tags всё ещё не написана, её
использование видится примерно таким:

  gear-update-tag [-r RULES] TAG [VALUE]

    В текущем каталоге ищется файл RULES (либо .gear-rules), по
    содержимому файла определяется имя файла тегов (либо используется
    файл .gear-tags).  В файл тегов добавляется новая запись (либо
    заменяется существующая) с именем TAG и значением SHA1,
    соответствующее коммиту VALUE (либо коммиту, на который указывает
    TAG в текущем репозитории).

  gear-update-tag [-r RULES] --all

    Для всех тегов, использующихся в файле правил, в файл тегов
    добавляются записи, соответствующие текущему состоянию тегов в
    репозитории.

  gear-update-tag [-r RULES] --clean

    Из файла тегов удаляются записи, не используемые в файле правил.

Во всех вариантах вызова gear-update-tag будут использоваться файлы из
рабочей копии, а не из репозитория.  Вероятно, при проверке
допустимости использования коммитов, помимо HEAD, стоит заглядывать и
в $GIT_DIR/MERGE_HEAD (на случай, если кто-то решил совместить merge с
обновлением файла тегов).

(Кстати, сейчас gear --commit портит MERGE_HEAD - можно попробовать
этого избежать, если вместо git-commit использовать напрямую
git-update-index, git-write-tree, git-commit-tree.)

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Mon, Sep 25, 2006 at 10:06:17PM +0400, Sergey Vlasov wrote:
> On Sun, Sep 24, 2006 at 11:14:10PM +0400, Sergey Vlasov wrote:
> > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > По моему, идея выглядит вполне живой.
> > 
> > Не вполне доделанная реализация выложена в
> > git.alt:vsu/packages/gear.git в бранч vsu/gear-tags; сейчас это
> > годится только для того, чтобы обругать.  Средства для обновления
> > .gear-tags, кроме /dev/hands, пока отсутствуют.
> 
> Без описания никто даже смотреть не хочет?

Я посмотрел код, мне в целом понравилось, тестировать не пробовал.

>    Поддержки комментариев сейчас нет (и нужна ли она там?).

Вряд ли.

>  - Допустимость значений SHA1, указанных в файле тегов, сейчас
>    проверяется по мере их использования; в принципе можно сделать и
>    принудительную проверку всех SHA1 при обнаружении файла тегов.

Можно, но вряд ли нужно.

>   gear-update-tag [-r RULES] TAG [VALUE]
> 
>     В текущем каталоге ищется файл RULES (либо .gear-rules), по
>     содержимому файла определяется имя файла тегов (либо используется
>     файл .gear-tags).  В файл тегов добавляется новая запись (либо
>     заменяется существующая) с именем TAG и значением SHA1,
>     соответствующее коммиту VALUE (либо коммиту, на который указывает
>     TAG в текущем репозитории).
> 
>   gear-update-tag [-r RULES] --all
> 
>     Для всех тегов, использующихся в файле правил, в файл тегов
>     добавляются записи, соответствующие текущему состоянию тегов в
>     репозитории.
> 
>   gear-update-tag [-r RULES] --clean
> 
>     Из файла тегов удаляются записи, не используемые в файле правил.
> 
> Во всех вариантах вызова gear-update-tag будут использоваться файлы из
> рабочей копии, а не из репозитория.  Вероятно, при проверке
> допустимости использования коммитов, помимо HEAD, стоит заглядывать и
> в $GIT_DIR/MERGE_HEAD (на случай, если кто-то решил совместить merge с
> обновлением файла тегов).

Логично.

> (Кстати, сейчас gear --commit портит MERGE_HEAD - можно попробовать
> этого избежать, если вместо git-commit использовать напрямую
> git-update-index, git-write-tree, git-commit-tree.)

Я вообще не знаю, зачем у меня выпрашивали gear --commit, когда существует
git-commit --amend.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Alexey I. Froloff]

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

* Sergey Vlasov <vsu@> [060925 22:13]:
>  - Для директив tar* доступна новая опция:
>      tree=COMMIT[:PATH]

Только есть одна маленькая и одна большая проблема ;-)

@@ -366,8 +366,8 @@ resolve_tree_name()
        local name="$1" && shift
 
        local commit_name path sha1
-       commit_name="${name##:*}"
-       path="${name%*:}"
+       commit_name="${name%%:*}"
+       path="${name#*:}"
        if [ "$path" = "$name" ]; then
                path=
        fi

Я это пофиксил в git.alt:/people/raorn/packages/gear.git в бранче
raorn/gear-tags.  Через некоторое время там появится поддержка
diff.

А большая проблема заключается в том, что gear:subst_keywords()
ругается на двоеточие.  С этим я не знаю что делать...

-- 
Regards,
Sir Raorn.

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

Re: [devel] gear -- создание тарбола из другого branch

[Alexey I. Froloff]

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

* Alexey I. Froloff <raorn@> [060926 21:40]:
> Через некоторое время там появится поддержка diff.
Ну собсно закоммитил.  Пример (нерабочий) использования:

$ cat .gear-rules 
copy: *.pamd
copy: *.sh
tar: ad name=xscreensaver-@version@-ad base=
tar: xscreensaver name=@name@-@version@ tree=upstream-@version@
diff: xscreensaver name=@name@-@version@-alt-fixes.patch orig=upstream-@version@:@dir@

По умолчанию имя diff'а @dir@-@version@-@release@.patch.

-- 
Regards,
Sir Raorn.

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

Re: [devel] gear -- создание тарбола из другого branch

[Anton Farygin]

Dmitry V. Levin wrote:
>>> Некрасиво?  Почему?  Кто на этот tar будет смотреть?
>> А когда у нас по плану уничтожение src.rpm?
> 
> Как только перейдём на сборку из gear-репозиториев.  Насколько я понимаю,
> srpm-пакеты из /i/S будут srpmimport'иться и с этого момента srpm-пакеты
> выкладываться перестанут.
> 

А вот здесь IMHO есть один недостаток.

Если кто-то знает, то пускай расскажет, каким образом можно 
склонировать/счекаутить git репозитарий без истории изменений (например 
- только последний коммит).

Т.е. - вопрос, как скачивать сорцы определённых версий пакетов ?

В Subversion есть для этого такая опция у checkout: -r.
Позволяет скачать всё начиная с определённого коммита.

Как это сделать в GIT ? Иначе траффик по download'у исходников пакетов с 
"нуля" будет колоссальный.

Rgds,
Rider

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Mon, Sep 25, 2006 at 12:09:04PM +0400, Anton Farygin wrote:
> Если кто-то знает, то пускай расскажет, каким образом можно 
> склонировать/счекаутить git репозитарий без истории изменений (например 
> - только последний коммит).
> 
> Т.е. - вопрос, как скачивать сорцы определённых версий пакетов ?
> 
> В Subversion есть для этого такая опция у checkout: -r.
> Позволяет скачать всё начиная с определённого коммита.

В Subversion используется совершенно другая модель репозитория - с
централизованным сервером, где такой проблемы просто не возникает.

> Как это сделать в GIT ? Иначе траффик по download'у исходников пакетов с 
> "нуля" будет колоссальный.

В настоящий момент в git реализована только возможность получить с сервера
tar-архив с файлами из произвольного дерева (git-tar-tree --remote=... на
клиенте, git-upload-tar на сервере; в ветке для разработчиков уже
переписано в виде git-archive --remote=... и git-upload-archive с целью
поддержки других форматов архивов, добавлена поддержка формата zip).
Правда, пользы от этого мало - средства для обновления такого архива путём
получения только изменений отсутствуют, к тому же tar передаётся без
сжатия (возможности докачки при обрыве соединения, естественно, тоже нет).

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

Кроме того, если обсуждаемая в этой ветке возможность использования в
.gear-rules ссылок на другие коммиты будет реализована, получится, что
наличия только одного коммита и соответствующего дерева с blob-ами будет
недостаточно для сборки пакета.

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Mon, Sep 25, 2006 at 05:31:13PM +0400, Sergey Vlasov wrote:
[...]
> Кроме того, если обсуждаемая в этой ветке возможность использования в
> .gear-rules ссылок на другие коммиты будет реализована, получится, что
> наличия только одного коммита и соответствующего дерева с blob-ами будет
> недостаточно для сборки пакета.

А как тогда собирать пакет?  Может быть существует способ более легально
встроить используемые в .gear-tags коммиты в дерево коммитов (например, в
parent'ы)?


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Tue, Sep 26, 2006 at 12:06:00AM +0400, Dmitry V. Levin wrote:
> On Mon, Sep 25, 2006 at 05:31:13PM +0400, Sergey Vlasov wrote:
> [...]
> > Кроме того, если обсуждаемая в этой ветке возможность использования в
> > .gear-rules ссылок на другие коммиты будет реализована, получится, что
> > наличия только одного коммита и соответствующего дерева с blob-ами будет
> > недостаточно для сборки пакета.
> 
> А как тогда собирать пакет?  Может быть существует способ более легально
> встроить используемые в .gear-tags коммиты в дерево коммитов (например, в
> parent'ы)?

Так они туда и встраиваются.  Тут пошёл разговор о shallow clone, когда
некоторые parent-ы могут отсутствовать - к сборке из нормального клона это
не относится.  Т.е., за наличием нужных parent-ов придётся следить тому,
кто решил экономить трафик путём использования shallow clone (если такую
возможность вообще когда-то приделают к git).

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Tue, Sep 26, 2006 at 12:42:16PM +0400, Sergey Vlasov wrote:
> On Tue, Sep 26, 2006 at 12:06:00AM +0400, Dmitry V. Levin wrote:
> > On Mon, Sep 25, 2006 at 05:31:13PM +0400, Sergey Vlasov wrote:
> > [...]
> > > Кроме того, если обсуждаемая в этой ветке возможность использования в
> > > .gear-rules ссылок на другие коммиты будет реализована, получится, что
> > > наличия только одного коммита и соответствующего дерева с blob-ами будет
> > > недостаточно для сборки пакета.
> > 
> > А как тогда собирать пакет?  Может быть существует способ более легально
> > встроить используемые в .gear-tags коммиты в дерево коммитов (например, в
> > parent'ы)?
> 
> Так они туда и встраиваются.

Конечно.  Наверное, я просто выпал из темы.

> Тут пошёл разговор о shallow clone, когда
> некоторые parent-ы могут отсутствовать - к сборке из нормального клона это
> не относится.

Не только к нормальному клону, но и к нормальному fetch'у по
refs/releases/sisyphus это тоже не относится.

> Т.е., за наличием нужных parent-ов придётся следить тому,
> кто решил экономить трафик путём использования shallow clone (если такую
> возможность вообще когда-то приделают к git).

Вот когда приделают, тогда и вернёмся к этой теме. :)


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Alex V. Myltsev]

On Mon, 25 Sep 2006 12:09:04 +0400
Anton Farygin wrote:
> Т.е. - вопрос, как скачивать сорцы определённых версий пакетов ?

У меня есть такое представление о том, как должен работать gear-release:

* Читает .gear-tags, в котором написано:
	branch1 path1
	branch2 path2
	...
* Из каждого бранча извлекает tree id посредством git-rev-parse и
  git-cat-file.
* Создаёт новое дерево следующим путём:
	{
		git-ls-tree HEAD
		for (tree, path) in .gear-tags:
			echo "040000 tree $tree $path"
	} >git-mktree
  То есть пришивает к текущему дереву деревья из нужных бранчей под
  нужными именами.
* Создаёт новый коммит1, который ссылается на новосозданное дерево, а
  родителем числит прошлый release commit. Создаёт новый коммит2,
  который ссылается на новосозданное дерево, но не имеет родителей.
* Создаёт и подписывает два тэга: release-$version с коммитом1 и
  release-$version-bare с коммитом2.

Теперь
- на новосозданные тэги можно применять gear в неизменённом виде.
- если .gear-tags пуст, то gear можно применять и на HEAD; если 
  .gear-tags непуст, то gear не найдёт в нём path* и отвалится.
  Это напоминание сборщику, что HEAD требует применения gear-release.
- наследственность тэгов вида release-$version по-прежнему можно
  проверять при входе в Сизиф, если считать, что майнтейнеры честны,
  хотя, может быть, забывчивы. (Если майнтейнеры нечестны, то проверка
  наследственности не помогает в любом случае.)
- тэги release-*-bare можно использовать, если нужно скачать все
  исходники какой-то версии, и только их. Специальной поддержки со
  стороны git не требуется. Соответствие $release и $release-bare
  проверяется тривиально.

(Прим.: HEAD всюду можно заменить на любой tree-ish.)

Re: [devel] gear -- создание тарбола из другого branch

[Alex V. Myltsev]

On Tue, 26 Sep 2006 14:14:25 +0400
Alex V. Myltsev wrote:
> - наследственность тэгов вида release-$version по-прежнему можно
>   проверять при входе в Сизиф
Это я, значит, соврал. Не получается. Жаль.

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Tue, Sep 26, 2006 at 02:14:25PM +0400, Alex V. Myltsev wrote:
> У меня есть такое представление о том, как должен работать gear-release:
> 
> * Читает .gear-tags, в котором написано:
> 	branch1 path1
> 	branch2 path2

branch1 - это имя, которое gear-release в момент запуска преобразует в
sha1?  В таком случае, даже если .gear-tags лежит в репозитории, это само
по себе ничего не значит, так как неизвестно, на что указывала ссылка с
указанным именем в момент запуска gear-release, следовательно, действия
мантейнера невозможно повторить (разве что попытаться найти, куда
показывала ссылка, по совпадению tree id, но в этом случае однозначный
результат не гарантируется)...

> 	...
> * Из каждого бранча извлекает tree id посредством git-rev-parse и
>   git-cat-file.
> * Создаёт новое дерево следующим путём:
> 	{
> 		git-ls-tree HEAD
> 		for (tree, path) in .gear-tags:
> 			echo "040000 tree $tree $path"
> 	} >git-mktree
>   То есть пришивает к текущему дереву деревья из нужных бранчей под
>   нужными именами.

...  Разве что модифицировать .gear-tags в этом дереве, добавив туда
реально использованные sha1 пришитых бранчей.

> * Создаёт новый коммит1, который ссылается на новосозданное дерево, а
>   родителем числит прошлый release commit. Создаёт новый коммит2,
>   который ссылается на новосозданное дерево, но не имеет родителей.

Откуда берётся прошлый release commit?  Придётся заводить для таких
коммитов какую-то специальную ветку.

У коммит1, если уж делать его в таком виде, нужно вторым родителем ставить
текущий коммит, иначе у того, что будет собираться, не будет никакой связи
с реальной историей разработки.  Впрочем, в gitk это всё равно будет
выглядеть отвратительно - либо мегапатч, либо мега-merge.

> * Создаёт и подписывает два тэга: release-$version с коммитом1 и
>   release-$version-bare с коммитом2.
> 
> Теперь
> - на новосозданные тэги можно применять gear в неизменённом виде.
> - если .gear-tags пуст, то gear можно применять и на HEAD; если 
>   .gear-tags непуст, то gear не найдёт в нём path* и отвалится.
>   Это напоминание сборщику, что HEAD требует применения gear-release.

Это неудобно - как минимум, нужен wrapper, позволяющий вызвать gear одной
командой (либо поддержка в самом gear).

Вообще предполагалось, что gear-release используется при направлении
окончательного релиза на сборку в Сизиф; в данном случае инструмент для
сшивания деревьев придётся применять существенно чаще - вероятно, это
должен быть не gear-release, а что-то другое.

> - наследственность тэгов вида release-$version по-прежнему можно
>   проверять при входе в Сизиф, если считать, что майнтейнеры честны,
>   хотя, может быть, забывчивы. (Если майнтейнеры нечестны, то проверка
>   наследственности не помогает в любом случае.)

> - тэги release-*-bare можно использовать, если нужно скачать все
>   исходники какой-то версии, и только их. Специальной поддержки со
>   стороны git не требуется. Соответствие $release и $release-bare
>   проверяется тривиально.

От такого release-*-bare пользы примерно столько же, сколько и от
git-archive --remote=... - при отсутствии связей между коммитами все
объекты всегда передаются полностью (точнее, только с gzip-сжатием каждого
объекта отдельно - количеством дельт между объектами одного дерева можно
пренебречь).

Экспериментальная проверка работы git с несвязанными коммитами на
репозитории linux-2.6 показала следующее:

 - Размер pack-файла bare/v2.6.17 - 58M.

 - Размер pack-файла bare/v2.6.18 - 59M.  Именно столько придётся вытянуть
   при получении bare/v2.6.18, не связанного с другими коммитами, даже при
   наличии в локальном репозитории bare/v2.6.17.

 - Размер pack-файла bare/v2.6.18, из которого исключены объекты, общие с
   деревом bare/v2.6.17 - 38M.  Такой pack-файл придётся получить при
   выполнении git-fetch -k ... tag bare/v2.6.18-linked (этот тег указывает
   на коммит с деревом v2.6.18^{tree}, для которого в качестве
   единственного родительского коммита записан bare/v2.6.17^{commit}).
   При отсутствии связей между коммитами не удаётся получить даже такой
   результат.

 - Размер pack-файла bare/v2.6.18-linked, который сформирован с ключом
   --thin в предположении о наличии у клиента bare/v2.6.17 - 5,3M.  Такой
   pack передаётся при выполнении git-fetch ... tag bare/v2.6.18-linked
   без опции -k.  Вот так должен работать нормальный fetch с
   использованием родных протоколов git.

Учитывая то, что на основе release-*-bare нельзя продолжать нормальную
разработку (разве что чуть подпатчить spec - патчи для остальных
компонентов уже не будут накладываться на исходный вариант из-за изменения
путей), такой вариант даёт довольно мало преимуществ.  Кроме того, имея
подобный коммит, никак не связанный с остальной историей, невозможно
получить изменения исходников относительно оригинальной версии (разве что
в дерево для этого коммита будут помещаться оригинальные исходники и
автоматически сформированные патчи).

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

Re: [devel] gear -- создание тарбола из другого branch

[Alex V. Myltsev]

On Tue, 26 Sep 2006 15:49:04 +0400
Sergey Vlasov wrote:

> branch1 - это имя, которое gear-release в момент запуска преобразует в
> sha1?  В таком случае, даже если .gear-tags лежит в репозитории, это
> само по себе ничего не значит, так как неизвестно, на что указывала
> ссылка с указанным именем в момент запуска gear-release,
> следовательно, действия мантейнера невозможно повторить
> ...  Разве что модифицировать .gear-tags в этом дереве, добавив туда
> реально использованные sha1 пришитых бранчей.
Ну ситуация же не становится лучше, если sha1 хранить в .gear-tags или
ещё где-то. Всё равно непонятно, откуда эти sha1 появились. Я предлагаю
хранить sha1 прямо в деревьях, родными механизмами git.

> > * Создаёт новый коммит1, который ссылается на новосозданное дерево,
> > а родителем числит прошлый release commit. Создаёт новый коммит2,
> >   который ссылается на новосозданное дерево, но не имеет родителей.
> Откуда берётся прошлый release commit?
Хм. Они вроде все лежат в refs/releases/?

> У коммит1, если уж делать его в таком виде, нужно вторым родителем
> ставить текущий коммит
Нет, родителем у него должен быть только прошлый release commit. Тогда
дифф между релизами будет настоящим диффом, со всеми исходниками.
А вот информацию о всех сшитых вместе коммитах надо где-то хранить в
релизе, это правда. Иначе нельзя будет проверить наследственность.

> > если .gear-tags непуст, то gear не найдёт в нём path* и отвалится.
> >   Это напоминание сборщику, что HEAD требует применения
> > gear-release.
> Это неудобно - как минимум, нужен wrapper, позволяющий вызвать gear
> одной командой (либо поддержка в самом gear).
Поддержка в самом gear должна отсутствовать по определению. Из этого
commit-ish не собирается однозначно пакет; значит, gear на него
применять нельзя.
Wrapper можно сделать, но он, разумеется, не будет обеспечивать
воспроизводимости.
 
> это должен быть не gear-release, а что-то другое.
ОК.

> при отсутствии связей между коммитами все объекты всегда передаются
> полностью
Беда. Я надеялся, что если дерево уже есть, то его заново не передают.
Тогда, конечно, bare отпадает.

> Кроме того, имея подобный коммит, никак не связанный с остальной
> историей, невозможно получить изменения исходников относительно
> оригинальной версии
Ну, это и сейчас, с историей, непонятно как делать. Где она,
оригинальная версия?

-- 
Best regards,
Alex V. Myltsev.

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Tue, Sep 26, 2006 at 05:01:36PM +0400, Alex V. Myltsev wrote:
> On Tue, 26 Sep 2006 15:49:04 +0400
> Sergey Vlasov wrote:
> 
> > branch1 - это имя, которое gear-release в момент запуска преобразует в
> > sha1?  В таком случае, даже если .gear-tags лежит в репозитории, это
> > само по себе ничего не значит, так как неизвестно, на что указывала
> > ссылка с указанным именем в момент запуска gear-release,
> > следовательно, действия мантейнера невозможно повторить
> > ...  Разве что модифицировать .gear-tags в этом дереве, добавив туда
> > реально использованные sha1 пришитых бранчей.
> Ну ситуация же не становится лучше, если sha1 хранить в .gear-tags или
> ещё где-то. Всё равно непонятно, откуда эти sha1 появились.

Если в .gear-tags хранится sha1 коммита, у этого коммита есть какая-то
история.  Понятно, что можно закоммитить неизвестно откуда взятые файлы с
бесполезным сообщением и заведомо ложной информацией об авторе, но эту
проблему вряд ли можно решить техническими средствами.

Если имеется только sha1 от дерева, действительно непонятно, откуда оно
появилось.

> Я предлагаю хранить sha1 прямо в деревьях, родными механизмами git.

sha1 каких объектов - tree или commit?  Для нормальной работы нужен
commit; искать commit по tree никуда не годится.

> > > * Создаёт новый коммит1, который ссылается на новосозданное дерево,
> > > а родителем числит прошлый release commit. Создаёт новый коммит2,
> > >   который ссылается на новосозданное дерево, но не имеет родителей.
> > Откуда берётся прошлый release commit?
> Хм. Они вроде все лежат в refs/releases/?

И какой из них последний?

> > У коммит1, если уж делать его в таком виде, нужно вторым родителем
> > ставить текущий коммит
> Нет, родителем у него должен быть только прошлый release commit.

Так делать нельзя.  Тот коммит, который идёт на сборку, должен иметь
ссылки на полную историю пакета, и этой истории должно быть достаточно для
нормального продолжения работы над пакетом (возможно, совершенно другим
мантейнером).  Если release commit будет содержать только склеенное дерево
исходников без явных ссылок на те коммиты, из которых это дерево было
собрано, продолжить работу на базе этого коммита будет проблематично (при
отсутствии явных ссылок рабочий коммит, из которого делался релиз, не
попадёт в кэширующий репозиторий Сизифа, а останется только в персональном
репозитории мантейнера, и вполне может оттуда пропасть).

> Тогда дифф между релизами будет настоящим диффом, со всеми исходниками.

git-diff release^1 release выдаст этот дифф независимо от того, есть у
коммита ещё родители или нет.  Вот в gitk, если явно не запросить,
получится diff --cc.

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

Проверять наследственность для сшитых коммитов, вероятно, как раз не
нужно, поскольку мантейнер вполне может в очередном релизе что-то
выбросить, и не стоит заставлять его в таком случае делать fake merge.
Вполне достаточно, чтобы release commit происходил от аналогичного коммита
предыдущего релиза.

Хотя при такой схеме, которая описана здесь, получается, что надо
проверять наследственность не только для release commit, но и для рабочего
коммита, из которого делается релиз (иначе можно не глядя пришить к
предыдущему релизу что попало).

> > > если .gear-tags непуст, то gear не найдёт в нём path* и отвалится.
> > >   Это напоминание сборщику, что HEAD требует применения
> > > gear-release.
> > Это неудобно - как минимум, нужен wrapper, позволяющий вызвать gear
> > одной командой (либо поддержка в самом gear).
> Поддержка в самом gear должна отсутствовать по определению. Из этого
> commit-ish не собирается однозначно пакет; значит, gear на него
> применять нельзя.

Либо нужно использовать схему, при которой пакет собирается однозначно.

> Wrapper можно сделать, но он, разумеется, не будет обеспечивать
> воспроизводимости.
>  
> > это должен быть не gear-release, а что-то другое.
> ОК.

Как минимум, подписывать каждую тестовую сборку - это перебор.

> > при отсутствии связей между коммитами все объекты всегда передаются
> > полностью
> Беда. Я надеялся, что если дерево уже есть, то его заново не передают.
> Тогда, конечно, bare отпадает.

Протокол git определяет только общие коммиты, получение списка нужных
tree/blob происходит уже на более поздней стадии, до которой при
отсутствии общих коммитов нужная информация уже не доходит.

> > Кроме того, имея подобный коммит, никак не связанный с остальной
> > историей, невозможно получить изменения исходников относительно
> > оригинальной версии
> Ну, это и сейчас, с историей, непонятно как делать. Где она,
> оригинальная версия?

При наличии истории есть хотя бы какая-то возможность что-то найти.  При
отсутствии нормальных связей до истории можно просто не добраться.

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

Re: [devel] gear -- создание тарбола из другого branch

[Alexey I. Froloff]

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

* Sergey Vlasov <vsu@> [060926 18:39]:
> При наличии истории есть хотя бы какая-то возможность что-то найти.  При
> отсутствии нормальных связей до истории можно просто не добраться.
Честно говоря я немного запутался.  Можно ещё раз озвучить, какие
проблемы призвано решить и как облегчит всем жизнь внедрение
.gear-tags?  Я помню только "иметь возможность генерить тарболлы
из разных бранчей", и наверно "генерить diff между произвольными
бранчами".

-- 
Regards,
Sir Raorn.

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

Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov]

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

On Tue, Sep 26, 2006 at 06:52:20PM +0400, Alexey I. Froloff wrote:
> Честно говоря я немного запутался.  Можно ещё раз озвучить, какие
> проблемы призвано решить и как облегчит всем жизнь внедрение
> .gear-tags?  Я помню только "иметь возможность генерить тарболлы
> из разных бранчей", и наверно "генерить diff между произвольными
> бранчами".

Других применений пока никто не предлагал.

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

On Sat, Sep 23, 2006 at 06:07:47PM +0400, Dmitry V. Levin wrote:

>> Только вот есть ли гарантия, что объект на который ссылаемся не будет по
>> какой-либо причине в будушем удален?
DVL> К сожалению, гарантии нет, что сводит всю идею на нет.

А если создавать ссылку на такой объект? Можно ли заблокировать смену или
удаление этой ссылки впоследствии при git push со стороны сервера?

>> То бишь в tar будет и spec с .gear-rules, так?
>> Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.
DVL> Некрасиво?  Почему?  Кто на этот tar будет смотреть?

Скажем я вообще извращаюсь. Собираю из группы пакетов единый seirospbx,
который в том числе выкладываю как тарболл (который используется за
пределами ALT). Но это уже, видимо, мои личные трудности. Тарболл для
выкладывания реальный все равно делается в spec'файле, и удалить два файла
перед генерированием тарболла можно.

Вот проблема со слиянием репозиториев меня куда больше волнует, я вообще
не знаю как ее решить.

> >>> Поэтому раскладывать мне приходится ручками.
> DVL>> Можно скрипт написать.
>> Я не представляю себе как это сделать.
>> Вот git-svn скачивает 3 репозитория. Их надо раскладывать по разным
>> каталогам. В них есть одинаковые имена (configure, например|. Я и ручками
>> после git pull из них трех не разберусь, как это сделать скриптом?
DVL> Да, с подкаталогами было бы удобнее.

Дело не в "удобнее", сейчас я вообще не могу нормально собирать этот пакет
:(

Решение можно найти (хоть с теми же sha1-name в .gear-rules), или мне
забить и тарболы генерировать своими скриптами и тупо класть их потом
распакованые в git? Только история из subversion будет полностью утеряна.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН УИСТЛЕРА
 Никогда не знают, кто прав, но всегда известно, кто в ответе.

Re: [devel] gear -- создание тарбола из другого branch

[Alexey Tourbin]

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

On Fri, Sep 22, 2006 at 02:44:27PM +0400, Денис Смирнов wrote:
> On Fri, Sep 22, 2006 at 09:57:17AM +0400, Алексей Турбин wrote:
> 
> >> Можно ли с помощью gear создавать тарболл по тэгу, например, а не из
> >> каталога? Это позволило бы избавиться от каши, когда приходится в одном
> >> пакете использовать несколько svn-репозиториев.
> AT> Что ты хочешь сделать?
> 
> Паковать asterisk.
> В svn он лежит прямо в корне. Соответственно в ветке master я вынужден
> делать на все файлы git mv. При каждом очередном переименовании или
> добавлении новых файлов я имею геморрой.

В корне это где?  Не понял зачем делать git mv.

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

>> Паковать asterisk.
>> В svn он лежит прямо в корне. Соответственно в ветке master я вынужден
>> делать на все файлы git mv. При каждом очередном переименовании или
>> добавлении новых файлов я имею геморрой.
AT> В корне это где?  Не понял зачем делать git mv.

В http://svn.digium.com/svn/asterisk/trunk/ я вижу сразу же содержимое
пакета. Если я это импортирую в git, то у .gear-rules остается указывать
разве что на текущий каталог, а не на подкаталог.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Сделает кто-нибудь нормальный патч или нет?
		-- ldv in #7399

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

Re: [devel] gear -- создание тарбола из другого branch

[Alexey Tourbin]

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

On Tue, Oct 03, 2006 at 11:54:22AM +0400, Денис Смирнов wrote:
> >> Паковать asterisk.
> >> В svn он лежит прямо в корне. Соответственно в ветке master я вынужден
> >> делать на все файлы git mv. При каждом очередном переименовании или
> >> добавлении новых файлов я имею геморрой.
> AT> В корне это где?  Не понял зачем делать git mv.
> 
> В http://svn.digium.com/svn/asterisk/trunk/ я вижу сразу же содержимое
> пакета. Если я это импортирую в git, то у .gear-rules остается указывать
> разве что на текущий каталог, а не на подкаталог.

Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с исходниками
работаешь, тогда отдельный подкаталог не нужен.

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

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

On Tue, Oct 03, 2006 at 12:05:49PM +0400, Алексей Турбин wrote:
>> В http://svn.digium.com/svn/asterisk/trunk/ я вижу сразу же содержимое
>> пакета. Если я это импортирую в git, то у .gear-rules остается указывать
>> разве что на текущий каталог, а не на подкаталог.
AT> Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с исходниками
AT> работаешь, тогда отдельный подкаталог не нужен.

Как я уже говорил -- астериск активно использует svn:external, на который
git-svn плюет с высокого дерева. Так что размещать по каталогам мне все
равно приходится.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Все программы содержат ошибки, просто о некоторых мы не догадываемся.

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

Re: [devel] gear -- создание тарбола из другого branch

[Pavlov Konstantin]

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

On Tuesday 03 October 2006 15:19, Денис Смирнов wrote:
> On Tue, Oct 03, 2006 at 12:05:49PM +0400, Алексей Турбин wrote:
> >> В http://svn.digium.com/svn/asterisk/trunk/ я вижу сразу же содержимое
> >> пакета. Если я это импортирую в git, то у .gear-rules остается указывать
> >> разве что на текущий каталог, а не на подкаталог.
>
> AT> Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с исходниками
> AT> работаешь, тогда отдельный подкаталог не нужен.
>
> Как я уже говорил -- астериск активно использует svn:external, на который
> git-svn плюет с высокого дерева. Так что размещать по каталогам мне все
> равно приходится.

Я для этого использую GIT_SVN_NO_LIB=1 git-svn --no-ignore-externals fetch с 
патчиком для git-svn:

diff --git a/git-svn.perl b/git-svn.perl
index 0290850..2f5cf90 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1246,6 +1246,7 @@ sub assert_svn_wc_clean {
        }
        my @status = grep(!/^Performing status on external/,(`svn status`));
        @status = grep(!/^\s*$/,@status);
+       @status = grep(!/^X/,@status) if $_no_ignore_ext;
        if (scalar @status) {
                print STDERR "Tree ($SVN_WC) is not clean:\n";
                print STDERR $_ foreach @status;
-- 
1.4.2.1.ga8608c

-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

On Tue, Oct 03, 2006 at 03:25:26PM +0400, Pavlov Konstantin wrote:

>> Как я уже говорил -- астериск активно использует svn:external, на который
>> git-svn плюет с высокого дерева. Так что размещать по каталогам мне все
>> равно приходится.
PK> Я для этого использую GIT_SVN_NO_LIB=1 git-svn --no-ignore-externals fetch с 
PK> патчиком для git-svn:

Может этот патчик тогда интегрировать?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
VMWare нынче не модно. Модно qemu.
		-- mithraen in devel@

Re: [devel] gear -- создание тарбола из другого branch

[Pavlov Konstantin]

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

On Tuesday 03 October 2006 18:36, Денис Смирнов wrote:
> On Tue, Oct 03, 2006 at 03:25:26PM +0400, Pavlov Konstantin wrote:
> >> Как я уже говорил -- астериск активно использует svn:external, на
> >> который git-svn плюет с высокого дерева. Так что размещать по каталогам
> >> мне все равно приходится.
>
> PK> Я для этого использую GIT_SVN_NO_LIB=1 git-svn --no-ignore-externals
> fetch с PK> патчиком для git-svn:
>
> Может этот патчик тогда интегрировать?

vsu@ его отсылал вапстрим, судьба этого патча мне далее неизвестна...

-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

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

Re: [devel] gear -- создание тарбола из другого branch

[Dmitry V. Levin]

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

On Tue, Oct 03, 2006 at 06:46:28PM +0400, Pavlov Konstantin wrote:
> On Tuesday 03 October 2006 18:36, Денис Смирнов wrote:
> > On Tue, Oct 03, 2006 at 03:25:26PM +0400, Pavlov Konstantin wrote:
> > >> Как я уже говорил -- астериск активно использует svn:external, на
> > >> который git-svn плюет с высокого дерева. Так что размещать по каталогам
> > >> мне все равно приходится.
> >
> > PK> Я для этого использую GIT_SVN_NO_LIB=1 git-svn --no-ignore-externals
> > fetch с PK> патчиком для git-svn:
> >
> > Может этот патчик тогда интегрировать?
> 
> vsu@ его отсылал вапстрим, судьба этого патча мне далее неизвестна...

Есть в git'овом master, 191414c025c3f0032d9b4843d629e4877126a748.


-- 
ldv

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

Re: [devel] gear -- создание тарбола из другого branch

[Денис Смирнов]

On Wed, Oct 04, 2006 at 02:25:39AM +0400, Dmitry V. Levin wrote:

>> vsu@ его отсылал вапстрим, судьба этого патча мне далее неизвестна...
DVL> Есть в git'овом master, 191414c025c3f0032d9b4843d629e4877126a748.

У нас может с ним собрать?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Надо же, выглядит вполне работоспособно.
		-- ldv in #9426