[devel] git: бранчи/дистрибутивы/обновления

[devel] git: бранчи/дистрибутивы/обновления

[Artem Zolochevskiy]

Господа,

Кто что посоветует по организации git/gear репозитория в свете поддержания 
различных версий пакета, находящегося в Sisyphus/Desktоp/Server/Junior ?

Постарался уложить в голову взаимодействие
git/gear/выпуски_дистрибутивов/и_обновлений

Как вернее всё это увязать?
Где/что можно делать лучше, правильнее эффективнее?

На вот этом совсем простом примере:

+---
Готовим пакет для Сизифа
+---

$ mkdir example
$ cd example
$ git init

$ cat > text.txt <<EOF
Этот текст описывает что-то

Пошло описание чего-то.
Ещё одна строка описания
Для этого надо нажать красную кнопку.
EOF
$ git add text.txt
$ git commit -m "initial revision"

$ cat > example.spec <<EOF
Name: example
Version: 0.1
Release: alt1
%changelog
* date name <mail> 0.1-alt1
- initial build for Sisyphus
EOF
$ git add example.spec
$ git commit -m "spec added"

$ echo "tar: ." > .gear-rules
$ git add .gear-rules
$ git commit -m ".gear-rules added"
$ git-tag 0.1-alt1

ну и gear > example-0.1-alt1.src.rpm > Sisyphus
Далее пакет уходит в том виде что есть в дистрибутив скажем Desktop.

+---
Новая версия для Сизифа
+---
Для Сизифа же выпускаются новые версии example

$ echo "ещё какая-то информация" >> text.txt
$ git add text.txt
$ git commit -m "more info in text.txt"
$ vi example.spec
	(меняем версию/changelog)
	$ cat example.spec
	Name: example
	Version: 0.2
	Release: alt1
	%changelog
	* new-date name <mail> 0.2-alt1
	- initial build for Sisyphus
	
	* date name <mail> 0.1-alt1
	- initial build for Sisyphus
$ git add example.spec
$ git commit -m "spec modified for 0.2-alt1"
$ git-tag 0.2-alt1

gear > example-0.2-alt1.src.rpm > Sisyphus
(в Desktop по-прежнему example-0.1-alt1.src.rpm)

+---
Обновление или бэкпорт для Desktop
+---

Теперь обнаруживается баг репорт
(опечаткa :-) в пакете, попавшем в Desktop)
надо бы её поправить.
т.е по идее надо бы изготовить пакет для Desktop
(видимо в соответсвии с policy относительно версий)

??? Вот тут как поступить ??? ТАК???

== 1. сделать изменение в текщей версии и отправить в обновления Desktop
т.е. получается версия examples-0.1-alt1 обновится до
examples-0.3-alt1, cодержащий помимо фикса
ещё и дополнительную фичу в виде строчки "ещё какая-то информация"
Это вообще допустимо?

$ vi test.txt
	s/Ещё одна строка описания/Ещё одна строка описания./
$ git add test.txt
$ git commit -m " misiing '.' fixes bug#XXX"
$ vi example.spec
	(меняем версию/changelog)
	$ cat example.spec
	Name: example
	Version: 0.3
	Release: alt1
	%changelog
	* new-new-date name <mail> 0.3-alt1
	- fixed bug#XXX
	
	* new-date name <mail> 0.2-alt1
	- initial build for Sisyphus
	
	* date name <mail> 0.1-alt1
	- initial build for Sisyphus
$ git add example.spec
$ git commit -m "spec modified for 0.3-alt1"
$ git-tag 0.3-alt1

gear > example-0.3-alt1.src.rpm > Sisyphus
gear > example-0.3-alt1.src.rpm > куда? чтоб он попал в обновления.

== 2. А если сторочка "ещё какая-то информация" для Desktop никак не 
применима,
то, видимо, надо отдельный бранч заводить? как-то так:
$ git checkout -b desktop 0.1-alt1
$ vi test.txt
	s/Ещё одна строка описания/Ещё одна строка описания./
$ git add test.txt
$ git commit -m "added point. fixes bug#XXX"
$ vi example.spec
	(меняем версию/changelog)
	$ cat example.spec
	Name: example
	Version: 0.1
	Release: alt1.M40.1
	%changelog
	* new-date name <mail> 0.1-alt1.M40.1
	- fixed bug#XXX

	* date name <mail> 0.1-alt1
	- initial build for Sisyphus
$ git commit -m "spec modified for 0.1-alt1.M40.1"
$ git-tag 0.1-alt1.M40.1

gear > example-0.3-alt1.src.rpm > куда? чтоб он попал в обновления.

т.е. получается некое копирования branch-ами структуры нашего ftp

Теперь хорошо бы, наверное, эту забытую "." и в текущую версию внести
Видимо, это можно cделать:

$ git checkout master
a) просто вручную cделать commit
б) merge? скорее даже git merge -s ours desktop ?
c) или обойтись git-cherry-pick на коммит с фиксом точки?
  если, он был сделан в desktop отдельным коммитом.

Или вообще всё не так. И выше, надо эту "." исправить в master,
а уж затем
$ git checkout -b desktop 0.1-alt1
$ git merge master

Тут, кажется, мне просто не хватает практики/понимания merge-вания и 
branch-евания

Ну суть вопроса, надеюсь, ясна.
Кто-что посоветует по организации git/gear репозитория в свете поддержания 
различных версий пакета,
находящегося в Sisyphus/Desktоp/Server/Junior ?


PS
Слава героям, дочитавшим этот пост до конца :-)

--
Артём Золочевский

Re: [devel] git: бранчи/дистрибутивы/обновления

[Damir Shayhutdinov]

> == 2. А если сторочка "ещё какая-то информация" для Desktop никак не
> применима,
> то, видимо, надо отдельный бранч заводить? как-то так:
> $ git checkout -b desktop 0.1-alt1
> $ vi test.txt
>         s/Ещё одна строка описания/Ещё одна строка описания./
> $ git add test.txt
> $ git commit -m "added point. fixes bug#XXX"
> $ vi example.spec
>         (меняем версию/changelog)
>         $ cat example.spec
>         Name: example
>         Version: 0.1
>         Release: alt1.M40.1
>         %changelog
>         * new-date name <mail> 0.1-alt1.M40.1
>         - fixed bug#XXX
>
>         * date name <mail> 0.1-alt1
>         - initial build for Sisyphus
> $ git commit -m "spec modified for 0.1-alt1.M40.1"
> $ git-tag 0.1-alt1.M40.1
>
> gear > example-0.3-alt1.src.rpm > куда? чтоб он попал в обновления.
>
> т.е. получается некое копирования branch-ами структуры нашего ftp
>
> Теперь хорошо бы, наверное, эту забытую "." и в текущую версию внести
> Видимо, это можно cделать:
>
> $ git checkout master
> a) просто вручную cделать commit
> б) merge? скорее даже git merge -s ours desktop ?
> c) или обойтись git-cherry-pick на коммит с фиксом точки?
>   если, он был сделан в desktop отдельным коммитом.
Лучше cherry-pick, раз уж бранчи разошлись. Merge тут ИМХО не нужен.

> Ну суть вопроса, надеюсь, ясна.
> Кто-что посоветует по организации git/gear репозитория в свете поддержания
> различных версий пакета,
> находящегося в Sisyphus/Desktоp/Server/Junior ?

Мне пока видится приемлемой вышеприведенная структура, с бранчем на
каждый поддерживаемый дистрибутив, в котором исправления переносятся
из ветки в ветку через cherry-pick.

Или же можно держать спек и .gear-rules в отдельном бранче, и тогда
можно сократить количество cherry-pick-ов за счет merge. Но это будет
посложнее и понимать, и поддерживать.

Re: [devel] git: бранчи/дистрибутивы/обновления

[Artem Zolochevskiy]

В сообщении от Sunday 22 July 2007 11:03:24 Damir Shayhutdinov написал(а):

> > Ну суть вопроса, надеюсь, ясна.
> > Кто-что посоветует по организации git/gear репозитория в свете
> > поддержания различных версий пакета,
> > находящегося в Sisyphus/Desktоp/Server/Junior ?
>
> Мне пока видится приемлемой вышеприведенная структура, с бранчем на
> каждый поддерживаемый дистрибутив, в котором исправления переносятся
> из ветки в ветку через cherry-pick.
>
> Или же можно держать спек и .gear-rules в отдельном бранче, и тогда
> можно сократить количество cherry-pick-ов за счет merge. Но это будет
> посложнее и понимать, и поддерживать.

ага. я тоже подумал о таком (спек + .gear-rules в отдельном бранче). но потом 
подумал, что создание бранчей cоответсвующих дистрибутивам всё равно скорее 
без перспектив на merge. а посему и выделять src в отдельный бранч от sepc-ов 
ради теоретического merge нецелесообразно. т.е. мне видится схема бранчей 
соответсвующий дистрибутивам + cherry-pick-и между ними.

-- 
Артём Золочевский

Re: [devel] git: бранчи/дистрибутивы/обновления

[Aleksey Avdeev]

Artem Zolochevskiy пишет:
> В сообщении от Sunday 22 July 2007 11:03:24 Damir Shayhutdinov написал(а):
> 
>>> Ну суть вопроса, надеюсь, ясна.
>>> Кто-что посоветует по организации git/gear репозитория в свете
>>> поддержания различных версий пакета,
>>> находящегося в Sisyphus/Desktоp/Server/Junior ?
>> Мне пока видится приемлемой вышеприведенная структура, с бранчем на
>> каждый поддерживаемый дистрибутив, в котором исправления переносятся
>> из ветки в ветку через cherry-pick.
>>
>> Или же можно держать спек и .gear-rules в отдельном бранче, и тогда
>> можно сократить количество cherry-pick-ов за счет merge. Но это будет
>> посложнее и понимать, и поддерживать.
> 
> ага. я тоже подумал о таком (спек + .gear-rules в отдельном бранче). но потом 
> подумал, что создание бранчей cоответсвующих дистрибутивам всё равно скорее 
> без перспектив на merge. а посему и выделять src в отдельный бранч от sepc-ов 
> ради теоретического merge нецелесообразно. т.е. мне видится схема бранчей 
> соответсвующий дистрибутивам + cherry-pick-и между ними.

  Выделять спек в отдельный бранч желательно для упрощения наследования
spec`ов в новых пакетах.

  Например, мне нужно собрать пакет с драйвером для RaLink RT2500
802.11g Cardbus/mini-PCI [Network controller]. Логично не писать spec с
нуля, а взять чтолибо за основу. И если отдельный бранч со спеком
отсутствует -- в качестве предка придётся брать весь репозитарий
пакета-протатипа. А это попахивает оверкиллом, с учётом того, что
исходный код прототипа ненужен... Если спек в отдельном бранче --
наклодные расходы меньше.

-- 

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