[devel] как избавиться от git-mv?

[devel] как избавиться от git-mv?

[Ildar Mulyukov]

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

On 03.10.2006 14:05:49, Alexey Tourbin wrote:
> 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
>> остается  указывать  разве что на текущий каталог, а не на
>> подкаталог.
> 
> Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с
> исходниками  работаешь, тогда отдельный подкаталог не нужен.

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

Задача: имеется пакет, имеющий свой апстрим (а то и несколько).  
Соответственно для жизненного цикла пакета необходима синхронизация с  
апстримом и свои, Альтовские файлы (spec, патчи, другие файлы).  
Тонкость заключается в желании стягивать (pull) апстрим не в том виде  
"как там им захотелось", а, положим, в отдельную папку. (В случае с  
несколькими апстримами это становится необходимо).

В худшем случае решение задачи (теоретически) представляется возможным  
небольшим подхакиванием используемых средств (git-pull и git-svn).

Хочется узнать реальное положение дел. И вообще - возможно ли решить ли  
данную задачу как-нибудь?

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] как избавиться от git-mv?

[Alexey Tourbin]

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

On Tue, Oct 31, 2006 at 05:35:29PM +0600, Ildar Mulyukov wrote:
> Re: [devel] gear -- создание тарбола из другого branch
> 
> On 03.10.2006 14:05:49, Alexey Tourbin wrote:
> > 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
> >> остается  указывать  разве что на текущий каталог, а не на
> >> подкаталог.
> > 
> > Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с
> > исходниками  работаешь, тогда отдельный подкаталог не нужен.
> 
> Для меня вопрос так и остался открытым.
> Если позволят уважаемые господа, я попробую сформулировать.
> 
> Задача: имеется пакет, имеющий свой апстрим (а то и несколько).  
> Соответственно для жизненного цикла пакета необходима синхронизация с  
> апстримом и свои, Альтовские файлы (spec, патчи, другие файлы).  
> Тонкость заключается в желании стягивать (pull) апстрим не в том виде  
> "как там им захотелось", а, положим, в отдельную папку. (В случае с  
> несколькими апстримами это становится необходимо).
> 
> В худшем случае решение задачи (теоретически) представляется возможным  
> небольшим подхакиванием используемых средств (git-pull и git-svn).
> 
> Хочется узнать реальное положение дел. И вообще - возможно ли решить ли  
> данную задачу как-нибудь?

Не надо класть в отдельную папку.

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

Re: [devel] как избавиться от git-mv?

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

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

On Tue, Oct 31, 2006 at 03:17:37PM +0300, Алексей Турбин wrote:

>> Хочется узнать реальное положение дел. И вообще - возможно ли решить ли  
>> данную задачу как-нибудь?
AT> Не надо класть в отдельную папку.

Иногда _надо_. А иногда пакет собирается из нескольких апстримов.

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

http://freesource.info
----------------------------------------------------------------------------
> Мы вообще все время чего-то ждем. К чему бы это :) ?
К дезорганизации.
		-- mike in devel-kernel@

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

Re: [devel] как избавиться от git-mv?

[Ildar Mulyukov]

On 31.10.2006 18:17:37, Alexey Tourbin wrote:
> > Для меня вопрос так и остался открытым.
> > Если позволят уважаемые господа, я попробую сформулировать.
> >
>>  Задача: имеется пакет, имеющий свой апстрим (а то и несколько).   
>> Соответственно для жизненного цикла пакета необходима синхронизация   
>> с  апстримом и свои, Альтовские файлы (spec, патчи, другие файлы).   
>> Тонкость заключается в желании стягивать (pull) апстрим не в том   
>> виде  "как там им захотелось", а, положим, в отдельную папку. (В  
>> случае с   несколькими апстримами это становится необходимо).
> >
>>  В худшем случае решение задачи (теоретически) представляется   
>> возможным  небольшим подхакиванием используемых средств (git-pull и  
>> git-svn).
> >
>>  Хочется узнать реальное положение дел. И вообще - возможно ли   
>> решить  ли  данную задачу как-нибудь?
> 
> Не надо класть в отдельную папку.
Ну что ж, коротко и ясно. Осталось только добавить:
КРРУУГОМ! РАЗОЙТИСЬ! ;)

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

Спасибо за ответ(ы). Ильдар.
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] как избавиться от git-mv?

[Ildar Mulyukov]

On 31.10.2006 17:35:29, Ildar Mulyukov wrote:
> Re: [devel] gear -- создание тарбола из другого branch
> 
> On 03.10.2006 14:05:49, Alexey Tourbin wrote:
> > 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  
>>> остается  указывать  разве что на текущий каталог, а не на  
>>> подкаталог.
> >
>> Ну и хорошо!  Если ты патчи не отдельно хранишь, а сразу с  
>> исходниками  работаешь, тогда отдельный подкаталог не нужен.
> 
> Для меня вопрос так и остался открытым.
> Если позволят уважаемые господа, я попробую сформулировать.
> 
> Задача: имеется пакет, имеющий свой апстрим (а то и несколько).  
> Соответственно для жизненного цикла пакета необходима синхронизация с  
> апстримом и свои, Альтовские файлы (spec, патчи, другие файлы).  
> Тонкость заключается в желании стягивать (pull) апстрим не в том виде  
> "как там им захотелось", а, положим, в отдельную папку. (В случае с  
> несколькими апстримами это становится необходимо).
> 
> В худшем случае решение задачи (теоретически) представляется  
> возможным небольшим подхакиванием используемых средств (git-pull и  
> git-svn).
> 
> Хочется узнать реальное положение дел. И вообще - возможно ли решить  
> ли данную задачу как-нибудь?

	Уважаемые коллеги,
Вернусь к строму-старому вопросу, хочу уточнить: правильно ли моё  
предположение, что:

Наилучшим вариантом представляется хранение дерева исходников в git,  
исходя из того, как в апстриме? То есть, если в апстриме в репозитарии  
файлы лежат прямо в корне, то так и поступать, положив спек и гир-рулез  
туда же (вперемешку), а если файлы лежат в отдельной подпапке типа  
./%name , то так и хранить?

Извините, если не совсем понятно, но сейчас я не могу сообразить, как  
это объяснить лучше :(

Спасибо за внимание. С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] как избавиться от git-mv?

[Damir Shayhutdinov]

>         Уважаемые коллеги,
> Вернусь к строму-старому вопросу, хочу уточнить: правильно ли моё
> предположение, что:
>
> Наилучшим вариантом представляется хранение дерева исходников в git,
> исходя из того, как в апстриме? То есть, если в апстриме в репозитарии
> файлы лежат прямо в корне, то так и поступать, положив спек и гир-рулез
> туда же (вперемешку),
ИМХО лучше котлеты отдельно, а мухи отдельно. То есть репозитарий
апстрима в отдельной ветке (upstream), .gear-rules и спек - в ветке
master. А мержить upstream можно в мастер со стратегией -s ours,
оставляя в master только спек и .gear-rules.

В .gear-rules писать что-то типа

tar.bz2: upstream-tip:.

> а если файлы лежат в отдельной подпапке типа
> ./%name , то так и хранить?
Да, так можно и в master мержить без -s ours.

Re: [devel] как избавиться от git-mv?

[Ildar Mulyukov]

On 22.10.2007 23:03:59, Damir Shayhutdinov wrote:
> >         Уважаемые коллеги,
>> Вернусь к строму-старому вопросу, хочу уточнить: правильно ли моё  
>> предположение, что:
>> 
>> Наилучшим вариантом представляется хранение дерева исходников в git,  
>> исходя из того, как в апстриме? То есть, если в апстриме в  
>> репозитарии файлы лежат прямо в корне, то так и поступать, положив  
>> спек и гир-рулез туда же (вперемешку),
> ИМХО лучше котлеты отдельно, а мухи отдельно. То есть репозитарий  
> апстрима в отдельной ветке (upstream), .gear-rules и спек - в ветке  
> master.

Да, всё в разных ветках, я это подразумевал.

> А мержить upstream можно в мастер со стратегией -s ours, оставляя в  
> master только спек и .gear-rules.

ours - это чтобы спек и рулез не трогались, так?

> В .gear-rules писать что-то типа
> tar.bz2: upstream-tip:.

ммм.

> > а если файлы лежат в отдельной подпапке типа
> > ./%name , то так и хранить?
> Да, так можно и в master мержить без -s ours.

Вопрос ставился немного иначе:
поскольку в репо надо держать:
1. рулес и спек
2. апстримную ветку
3. патченную ветку, которая будет собираться ,
то из чего следует исходить для того, чтобы разложить исходники в репо ?

В корне должны лежать .git, .gear-rules, спек и ... тут как минимум 2  
варианта:
1. папка с исходниками
2. сами исходники без отдельной папки.

Чем определяется?
Моё предположение - тем, как разложено в апстриме.
Обоснование: чтобы не делать git-mv при каждом мердже. (что также  
отрицательно скажется на истории)

Правильно?

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] как избавиться от git-mv?

[Ildar Mulyukov]

On 24.10.2007 12:39:30, Ildar Mulyukov wrote:
> В корне должны лежать .git, .gear-rules, спек и ... тут как минимум 2  
> варианта:
> 1. папка с исходниками
> 2. сами исходники без отдельной папки.

И, наконец, самый главный вопрос:
Возможно ли настроить git-svn класть исходники в папку? То есть  
хочется, чтобы импорт из svn-upstream давал примерно такой результат:
$ ls -la
drwxr-xr-x  5 ildar ildar 4096 Окт 24 12:32 .
drwxr-xr-x 29 ildar ildar 4096 Окт 24 12:32 ..
drwxr-xr-x 10 ildar ildar 4096 Окт 24 12:32 balsa
-rw-r--r--  1 ildar ildar 6153 Окт 24 12:32 balsa.spec
-rw-r--r--  1 ildar ildar   86 Окт 24 12:32 .gear-rules
drwxr-xr-x  8 ildar ildar 4096 Окт 24 12:32 .git

в man git-svn написано что-то неудобовразумительное, поэтому решил  
спросить здесь.

Спасибо. С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] как избавиться от git-mv?

[Damir Shayhutdinov]

> >> Наилучшим вариантом представляется хранение дерева исходников в git,
> >> исходя из того, как в апстриме? То есть, если в апстриме в
> >> репозитарии файлы лежат прямо в корне, то так и поступать, положив
> >> спек и гир-рулез туда же (вперемешку),
> > ИМХО лучше котлеты отдельно, а мухи отдельно. То есть репозитарий
> > апстрима в отдельной ветке (upstream), .gear-rules и спек - в ветке
> > master.
>
> Да, всё в разных ветках, я это подразумевал.
А почему тогда возник вопрос про "перемешку"?

> > А мержить upstream можно в мастер со стратегией -s ours, оставляя в
> > master только спек и .gear-rules.
>
> ours - это чтобы спек и рулез не трогались, так?
Нет, это чтобы файлы из upstream не попали в master. Чтобы в master
было только два файла и директория .gear-tags.

> Вопрос ставился немного иначе:
> поскольку в репо надо держать:
> 1. рулес и спек
> 2. апстримную ветку
> 3. патченную ветку, которая будет собираться ,
> то из чего следует исходить для того, чтобы разложить исходники в репо ?
Я не совсем понимаю ваш стиль использования gear.

Мой стиль основывается на том, что в результирующем .src.rpm
сохраняется "замещающая первозданность(ванильность)". То есть можно
заменить тарбол из сгенерированного .src.rpm на тарбол из апстрима и
при этом ничего не изменится.

Чтобы поддерживать такой стиль, я создаю тарбол из апстримной ветки, а
патченную ветку (ветки) кладу в пакет в виде диффа между апстримом и
патченной веткой. (директива diff: в .gear-rules). Если патченных
веток несколько, то и патчей получается несколько. В первую патченную
ветку мержатся изменения апстрима. Во вторую ветку мержится первая
ветка с уже слитыми изменениями апстрима и патчем первой ветки. В
третью ветку - мержится вторая. И т.д.

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

Мержить при этом последнюю ветку в master с -s ours или без - не принципиально.

> В корне должны лежать .git, .gear-rules, спек и ... тут как минимум 2
> варианта:
> 1. папка с исходниками
> 2. сами исходники без отдельной папки.
Третий вариант - исходники в других ветках.

> Чем определяется?
Вкусом.

> Моё предположение - тем, как разложено в апстриме.
В случае когда исходники в отдельной ветке - это не принципиально.

> Обоснование: чтобы не делать git-mv при каждом мердже. (что также
> отрицательно скажется на истории)
А зачем вы делаете git-mv?

> Правильно?
Ну может и правильно, для вашей схемы.

Re: [devel] как избавиться от git-mv?

[Damir Shayhutdinov]

> И, наконец, самый главный вопрос:
> Возможно ли настроить git-svn класть исходники в папку?
Я раньше тоже думал над этим вопросом. Даже специальный скрипт
написал, который импортит KoLmafia из апстримного svn в папку. Но
потом понял, что чуть-чуть изменив процесс сборки .src.rpm, можно
обойтись без отдельных папок. Конкретно KoLmafia мне переделывать уже
не хочется, а вот в новых моих пакетах я так делаю.

Посмотрите на http://git.altlinux.org/people/damir/packages/?p=liblazy.git;a=summary

Там правда апстрим git-овый, но это сути не меняет.
.gear-rules там состоит из одной строчки - вот такой:

tar.bz2: @name@-@version@:.

@name@ и @version@ берутся из спека. @name@ - это liblazy. а @version@ - это 0.1

На ветке upstream присутствует тег liblazy-0.1. Поэтому апстримный
тарбол будет браться из этого тега.

При переезде на новую версию надо будет всего лишь:

1. Поставить нужный тег на апстримной ветке (например liblazy-0.2).
2. Смержить этот тег в master с -s ours
3. Заменить в спеке версию с 0.1 на 0.2.
4. Выполнить gear-update-tag -ac
5. Дописать changelog
6. Собрать.

.gear-rules в этом случае дергать не надо.

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

[devel] логика "менеджмента" gear+git.alt

[Ildar Mulyukov]

	Уважаемый Дамир!
спасибо, что уделили мне столько времени!

За последний месяц я посвятил значительное количество времени, чтобы  
перейти на gear+git.alt. Я прочёл всё, что нашёл на тему  
git+gear+git.alt . Однако не наткнулся на то, какая логика  
"менеджмента" всего этого хозяйства (никто не поделился?) или, по  
крайней мере, не смог собрать из кусочков целостной картины. Ваше  
письмо очень ценно именно поэтому. Ещё раз огромное спасибо. Буду  
разбираться.

Одно пожелание: Я сейчас буду лезть в Вашу папку git/people. Не  
присоветуете мне небольшой образцово-показательный репо?

On 24.10.2007 13:11:29, Damir Shayhutdinov wrote:
> Я не совсем понимаю ваш стиль использования gear.
вся прелесть в том, что пока никакого _моего_ стиля нет. Буду учиться у  
старших товарищей.

>>>> Наилучшим вариантом представляется хранение дерева исходников в  
>>>> git, исходя из того, как в апстриме? То есть, если в апстриме в  
>>>> репозитарии файлы лежат прямо в корне, то так и поступать, положив  
>>>> спек и гир-рулез туда же (вперемешку),
>>> ИМХО лучше котлеты отдельно, а мухи отдельно. То есть репозитарий  
>>> апстрима в отдельной ветке (upstream), .gear-rules и спек - в ветке  
>>> master.
>> Да, всё в разных ветках, я это подразумевал.
> А почему тогда возник вопрос про "перемешку"?
Потому что я в этой кухне ещё ничего не понимаю.

> > > А мержить upstream можно в мастер со стратегией -s ours, оставляя  
> в
> > > master только спек и .gear-rules.
> > ours - это чтобы спек и рулез не трогались, так?
> Нет, это чтобы файлы из upstream не попали в master. Чтобы в master
> было только два файла и директория .gear-tags.
тут понятно.

> > Вопрос ставился немного иначе:
> > поскольку в репо надо держать:
> > 1. рулес и спек
> > 2. апстримную ветку
> > 3. патченную ветку, которая будет собираться ,
> > то из чего следует исходить для того, чтобы разложить исходники в  
> репо ?
> Я не совсем понимаю ваш стиль использования gear.
> Мой стиль основывается на том, что в результирующем .src.rpm  
> сохраняется "замещающая первозданность(ванильность)". То есть можно  
> заменить тарбол из сгенерированного .src.rpm на тарбол из апстрима и  
> при этом ничего не изменится.
Мне нравится.

Один вопрос: Если в истории есть и тарболы, и SVN, как быть с  
исчезающими и появляющимися Makefile.in/configure ?
> Чтобы поддерживать такой стиль, я создаю тарбол из апстримной ветки, а
> патченную ветку (ветки) кладу в пакет в виде диффа между апстримом и
> патченной веткой. (директива diff: в .gear-rules). Если патченных
> веток несколько, то и патчей получается несколько. В первую патченную
> ветку мержатся изменения апстрима. Во вторую ветку мержится первая
> ветка с уже слитыми изменениями апстрима и патчем первой ветки. В
> третью ветку - мержится вторая. И т.д.
> 
> В результате первый патч получается как дифф между первой веткой и
> апстримом. Второй патч - как дифф между второй веткой и первой веткой.
> Третий - дифф между третьей и второй и т.д. Накладываются патчи в том
> же порядке. При этом патчи даже могут пересекаться, это никак не
> сказывается на работе.
> 
> Мержить при этом последнюю ветку в master с -s ours или без - не  
> принципиально.
кажется улавливаю. Буду пробовать руками.

> > В корне должны лежать .git, .gear-rules, спек и ... тут как минимум  
> 2
> > варианта:
> > 1. папка с исходниками
> > 2. сами исходники без отдельной папки.
> Третий вариант - исходники в других ветках.
> 
> > Чем определяется?
> Вкусом.
> 
> > Моё предположение - тем, как разложено в апстриме.
> В случае когда исходники в отдельной ветке - это не принципиально.
> 
> > Обоснование: чтобы не делать git-mv при каждом мердже. (что также
> > отрицательно скажется на истории)
> А зачем вы делаете git-mv?
думаю, проживу без него :-)

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

Спасибо! С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] логика "менеджмента" gear+git.alt

[Damir Shayhutdinov]

>         Уважаемый Дамир!
> спасибо, что уделили мне столько времени!
:) На здоровье!

> За последний месяц я посвятил значительное количество времени, чтобы
> перейти на gear+git.alt. Я прочёл всё, что нашёл на тему
> git+gear+git.alt . Однако не наткнулся на то, какая логика
> "менеджмента" всего этого хозяйства (никто не поделился?) или, по
> крайней мере, не смог собрать из кусочков целостной картины. Ваше
> письмо очень ценно именно поэтому. Ещё раз огромное спасибо. Буду
> разбираться.
На самом деле, мантейнеры, использующие git.alt, на мой взгляд еще
только подходят к выработке этой самой целостной картины. Меня git.alt
привлекает не столько удобством, сколько широчайшим простором для
экспериментов, обсуждений, исследований. В git.alt пока еще не
оформились тренды, не определились гуру, не выработана "единая линия
партии". :)

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


> Одно пожелание: Я сейчас буду лезть в Вашу папку git/people. Не
> присоветуете мне небольшой образцово-показательный репо?
Хмм.. Ну даже не знаю что именно посоветовать. У меня там полный
зоопарк из различных схем. По дате создания репозиториев можно даже
определить "гитологические эры" - например эра gear-srpmimport, потом
эра самописных скриптов конвертации из апстримного SCM, потом вот
новая схема.

Даже внутри одного репозитория может наблюдаться смена этих эпох. :)

Хотя вот по отдельным вопросам могу посоветовать следующее:

liblazy.git - это пример использования апстримного SCM (git), когда
апстрим импортируется в отдельную ветку (upstream) без директории
верхнего уровня, в ветке master кладется spec, .gear-rules и
.gear-tags. Это свеженький пакет, я его еще не залил в Сизиф, пока
испытываю на своей машине.

KoLmafia.git - классический пример эпохи самописных скриптов. Я
написал специальный скрипт - замену git-svn, который бы складывал
импортированные исходники в директорию верхнего уровня. На этом
репозитории можно увидеть схему "много веток-патчей", и как я с ними
управляюсь. Совсем недавно например я решал проблему с конфликтом,
возникшем между апстримной веткой и патчем-веткой от raorn@. Также в
этом репозитории можно увидеть пример совместной работы мантейнеров
(для этого надо бы еще посмотреть
git.alt:/people/raorn/packages/KoLmafia.git

firebird.git - смешанная схема. В ветку upstream я кладу распакованные
тарболы, каждый помечая своим тегом. От этой ветки я отпочковал ветку
alt/system-libicu, в которой запатчил firebird на сборку с системной
libicu. И .gear-rules в master это отражает. Но этот пакет еще не
доделан.

Ну остальные я пока не рекомендую смотреть - они в основном сделаны по
минимальной схеме  а-ля git-srpmimport.

> > Я не совсем понимаю ваш стиль использования gear.
> > Мой стиль основывается на том, что в результирующем .src.rpm
> > сохраняется "замещающая первозданность(ванильность)". То есть можно
> > заменить тарбол из сгенерированного .src.rpm на тарбол из апстрима и
> > при этом ничего не изменится.
> Мне нравится.
>
> Один вопрос: Если в истории есть и тарболы, и SVN, как быть с
> исчезающими и появляющимися Makefile.in/configure ?
Просто. В спеке перед %configure ставить autoreconf -fisv
Если этих файлов не было (в случае импорта из апстрима), то они будут
созданы. Если же они были - то они будут выкинуты, и вместо них будут
созданы новые.

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

Re: [devel] логика "менеджмента" gear+git.alt

[Damir Shayhutdinov]

> За последний месяц я посвятил значительное количество времени, чтобы
> перейти на gear+git.alt. Я прочёл всё, что нашёл на тему
> git+gear+git.alt .
В догонку (возможно, окажется полезным для понимания git)

http://los-t.livejournal.com/tag/git+guts

Я еще потихоньку дописываю, как время появляется, а пока можно хоть
начало почитать.

[devel] [wiki] Re: логика "менеджмента" gear+git.alt

[Michael Shigorin]

On Wed, Oct 24, 2007 at 01:38:12PM +0600, Ildar Mulyukov wrote:
> спасибо, что уделили мне столько времени!

Дык а почему я фиксировать должен? ;-)

Можете взяться причесать и разбить эту страничку, если хотите.

> За последний месяц я посвятил значительное количество времени,
> чтобы  перейти на gear+git.alt. Я прочёл всё, что нашёл на тему  
> git+gear+git.alt . Однако не наткнулся на то, какая логика  
> "менеджмента" всего этого хозяйства (никто не поделился?) или, по  
> крайней мере, не смог собрать из кусочков целостной картины. Ваше  
> письмо очень ценно именно поэтому. Ещё раз огромное спасибо. Буду  
> разбираться.

http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/git?v=11ip

(по ходу -- если кто ловил сейчас там 500 при редактировании, уже
отловлено и исправлено; мож mithraen@ прокомментирует изящные СХИ)

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

Re: [devel] [wiki] Re: логика "менеджмента" gear+git.alt

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

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

On Thu, Nov 01, 2007 at 09:46:36PM +0200, Michael Shigorin wrote:

MS> (по ходу -- если кто ловил сейчас там 500 при редактировании, уже
MS> отловлено и исправлено; мож mithraen@ прокомментирует изящные СХИ)

Вообще это неприятная security-проблема nginx.

У нас из-за паранои nginx пускается от _nginx:_nginx, и его спул виден
только группе _nginx (на часть каталогов права root:_nginx).

Соответственно проблема, если нужно иметь файлы которые доступны только
для группы apache (к примеру нужна статика, которая меняется PHP-скриптами
под safe_mode, но при этом раздавать эту статику должен nginx).

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

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН МЭРИАННА
 Находишь всегда то, что не искал.

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