[devel] gear и патчи

[devel] gear и патчи

[Grigory Batalov]

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

Здравствуйте!

Возможно, здесь обсуждалось, а я пропустил:

Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
<название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.

Например:
foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961

Мне кажется, удобнее исправлять исходники непосредственно в git, скажем,
в бранче devel, а не обновлять от версии к версии файлы .patch. Тем более,
что последние обычно называют <package>-<version>-alt-<what>.patch, то есть
эти файлы будут появляться и исчезать при смене <version>.

Можно было бы просто паковать в SRPM модифицированное дерево исходников, но
тогда как указать на конкретное исправление пользователям других
дистрибутивов? Отсылать в наш git?

-- 
 Григорий Баталов

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

Re: [devel] gear и патчи

[Aleksey Avdeev]

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

Grigory Batalov пишет:
> Здравствуйте!
> 
> Возможно, здесь обсуждалось, а я пропустил:
> 
> Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
> коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
> <название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
> 
> Например:
> foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961
2
  Судя по
<http://lists.altlinux.org/pipermail/devel/2006-October/037580.html> --
подобная функциональность ожидается, но пока в официальном gear её нет.

> 
> Мне кажется, удобнее исправлять исходники непосредственно в git, скажем,
> в бранче devel, а не обновлять от версии к версии файлы .patch. Тем более,
> что последние обычно называют <package>-<version>-alt-<what>.patch, то есть
> эти файлы будут появляться и исчезать при смене <version>.

  Для <git.alt:/people/solo/packages/sks.git> применил велосипед, в виде
скрипта git2patch.sh (<git.alt:/people/solo/packages/git2patch.git>,
более детальное описание здесь:
<http://lists.altlinux.org/pipermail/devel/2006-November/038836.html>).

-- 

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



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

Re: [devel] gear и патчи

[Alex V. Myltsev]

On Mon, 27 Nov 2006 15:48:26 +0300
Grigory Batalov wrote:
> Мне кажется, удобнее исправлять исходники непосредственно в git,
> скажем, в бранче devel, а не обновлять от версии к версии
> файлы .patch.
Да. Но опять же получается, что на каждый патч нужно заводить
отдельный бранч, а потом их все мержить (в правильном порядке).

Смотрел ли кто-нибудь на Stacked git [1] и patchy git [2]?
По идее, это как раз инструменты для жонглирования патчами.

[1] http://www.procode.org/stgit/
[2] http://www.spearce.org/category/projects/scm/pg/

-- 
Best regards,
Alex V. Myltsev.

Re: [devel] gear и патчи

[Grigory Batalov]

On Mon, 27 Nov 2006 16:34:44 +0300
Aleksey Avdeev <solo@solin.spb.ru> wrote:

> > Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
> > коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
> > <название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
> > 
> > Например:
> > foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e89612
>   Судя по
> <http://lists.altlinux.org/pipermail/devel/2006-October/037580.html> --
> подобная функциональность ожидается, но пока в официальном gear её нет.
> 
> > 
> > Мне кажется, удобнее исправлять исходники непосредственно в git, скажем,
> > в бранче devel, а не обновлять от версии к версии файлы .patch. Тем более,
> > что последние обычно называют <package>-<version>-alt-<what>.patch, то есть
> > эти файлы будут появляться и исчезать при смене <version>.
> 
>   Для <git.alt:/people/solo/packages/sks.git>

  Нет его там, есть cks.git =)

> применил велосипед, в виде
> скрипта git2patch.sh (<git.alt:/people/solo/packages/git2patch.git>,
> более детальное описание здесь:
> <http://lists.altlinux.org/pipermail/devel/2006-November/038836.html>).

  Спасибо. Я смотрел на cks, но сразу не понял, а про git2patch
  забыл.

-- 
 Григорий Баталов,
 программист
 ЗАО "Ланит-Терком"

Re: [devel] gear и патчи

[Alex V. Myltsev]

On Mon, 27 Nov 2006 15:48:26 +0300
Grigory Batalov wrote:
> Мне кажется, удобнее исправлять исходники непосредственно в git,
> скажем, в бранче devel, а не обновлять от версии к версии
> файлы .patch.
Да. Но опять же получается, что на каждый патч нужно заводить
отдельный бранч, перед сборкой их все мержить (в правильном 
порядке), а при обновлении исходника -- rebase'ить.

Смотрел ли кто-нибудь на Stacked git [1] и patchy git [2]?
По идее, это как раз инструменты для жонглирования патчами.

[1] http://www.procode.org/stgit/
[2] http://www.spearce.org/category/projects/scm/pg/

-- 
Best regards,
Alex V. Myltsev.

Re: [devel] gear и патчи

[Aleksey Avdeev]

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

Grigory Batalov пишет:
> On Mon, 27 Nov 2006 16:34:44 +0300
> Aleksey Avdeev <solo@solin.spb.ru> wrote:
> 
> 
>>>Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
>>>коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
>>><название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
>>>
>>>Например:
>>>foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e89612
>>
>>  Судя по
>><http://lists.altlinux.org/pipermail/devel/2006-October/037580.html> --
>>подобная функциональность ожидается, но пока в официальном gear её нет.
>>
>>
>>>Мне кажется, удобнее исправлять исходники непосредственно в git, скажем,
>>>в бранче devel, а не обновлять от версии к версии файлы .patch. Тем более,
>>>что последние обычно называют <package>-<version>-alt-<what>.patch, то есть
>>>эти файлы будут появляться и исчезать при смене <version>.
>>
>>  Для <git.alt:/people/solo/packages/sks.git>
> 
> 
>   Нет его там, есть cks.git =)

  Так-к... Моя крыша уже едит... :-/

-- 

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


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

Re: [devel] gear и патчи

[Sergey Vlasov]

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

On Mon, Nov 27, 2006 at 03:48:26PM +0300, Grigory Batalov wrote:
> Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
> коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
> <название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
> 
> Например:
> foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961

В последней версии gear это может быть записано в виде:

diff: f9f580742b3b499e4a0fb298511f42f482a14928:. bbab731ee05b4a9211545309d9fdf2954a7e8961:. name=foo-0.1-alt-build.patch

(в name=... можно использовать @name@, @version@, @release@,
@old_dir@, @new_dir@).  Можно также написать diff.gz или diff.bz2.
Ограничение - нельзя указывать совсем произвольные sha1, это должны
быть коммиты, предшествующие (непосредственно или через произвольное
количество промежуточных коммитов) тому коммиту, из которого
собирается пакет.

Чтобы не писать sha1 в .gear-rules, можно использовать вместо них
имена тегов, сохранённых с помощью gear-update-tag.  Хотя этот вариант
применим в основном в случае, когда генерируется один общий патч:

diff: v@version@:. .

(по умолчанию name=@new_dir@-@version@-@release@.patch, при указании
"." вместо @new_dir@ используется @name@).  Ограничения на указание
коммитов через имена тегов те же самые.

> Мне кажется, удобнее исправлять исходники непосредственно в git,
> скажем, в бранче devel, а не обновлять от версии к версии файлы
> .patch.

Тогда возникает вопрос, что делать при обновлении до новой версии.
Естественный для git вариант - объединить изменения с новой версией
через git-pull (т.е., merge), но при этом результат в общем случае уже
не представляется в виде набора патчей - можно сделать только один
общий патч от оригинальной версии к модифицированной.  Чтобы получить
какое-то одно изменение в виде патча к текущей версии, придётся
выполнять, например, git-cherry-pick в отдельной временной ветке
(тащить его в историю пакета при таком способе работы бессмысленно -
оно там уже есть, возможно, с исправлениями, внесёнными в ходе
разрешения конфликтов при merge; единственная причина делать это -
необходимость подготовки патча для передачи, например, в upstream).

Кстати, можно завести не один бранч devel, а несколько, куда разносить
изменения, относящиеся к разным по смыслу исправлениям.

Есть другой вариант - git-rebase при переходе на новую версию из
upstream; в этом случае отдельные патчи сохраняются, но теряется связь
с предыдущей историей пакета, что в новой системе сборки недопустимо.
Правда, можно восстановить эту связь через git-pull -s ours, но при
таком способе история будет засоряться многочисленными копиями одних и
тех же изменений для разных версий пакета (впрочем, в этом случае
старую историю можно будет просто отсечь при просмотре изменений,
поскольку она не будет содержать полезной информации - все изменения
относительно upstream после git-rebase будут воспроизведены в новых
коммитах, либо удалены, если они уже вошли в upstream).

> Тем более, что последние обычно называют
> <package>-<version>-alt-<what>.patch, то есть эти файлы будут
> появляться и исчезать при смене <version>.

Зачастую при смене <version> старые патчи как раз не перегенерируются,
пока окончательно не перестанут прикладываться.  В некоторых случаях
это приводит к трудновыявляемым проблемам, когда патч вроде бы ложится
на новую версию, но какие-то изменения попадают совсем не туда, куда
надо.  Теоретически алгоритм 3-way merge может быть более устойчив к
подобным ошибкам, чем patch, поскольку имеет больше информации
(информация об изменениях не ограничена размером контекста, как в
случае patch).  Хотя при выполнении git-rebase возможность получить
такую проблему сохраняется, поскольку по умолчанию (без опции --merge)
git-rebase сначала пытается приложить изменение как патч, и только в
том случае, если это не удаётся, использует 3-way merge.

> Можно было бы просто паковать в SRPM модифицированное дерево
> исходников, но тогда как указать на конкретное исправление
> пользователям других дистрибутивов? Отсылать в наш git?

Отсылать было бы хорошо в gitweb, но его у нас пока нет.  С другой
стороны, если предполагается упразднение src.rpm, какое-то средство
типа gitweb должно появиться раньше этого.

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

Re: [devel] gear и патчи

[Grigory Batalov]

On Mon, 27 Nov 2006 17:01:26 +0300
"Alex V. Myltsev" <avm@altlinux.org> wrote:

> > Мне кажется, удобнее исправлять исходники непосредственно в git,
> > скажем, в бранче devel, а не обновлять от версии к версии
> > файлы .patch.
> Да. Но опять же получается, что на каждый патч нужно заводить
> отдельный бранч, а потом их все мержить (в правильном порядке).

  Не обязательно, мне это было бы неудобно.

> Смотрел ли кто-нибудь на Stacked git [1] и patchy git [2]?
> По идее, это как раз инструменты для жонглирования патчами.
> 
> [1] http://www.procode.org/stgit/

  По моему, это вполне самостоятельный проект (на Питоне). Для gear
  сгодилось бы решение попроще.
  Оказывается, vsu@ уже кое-что сделал:

http://lists.altlinux.org/pipermail/devel/2006-October/037580.html

> [2] http://www.spearce.org/category/projects/scm/pg/

  Ужасный сайт =). Где там исходники?

-- 
 Григорий Баталов

Re: [devel] gear и патчи

[Aleksey Avdeev]

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

Sergey Vlasov пишет:
> On Mon, Nov 27, 2006 at 03:48:26PM +0300, Grigory Batalov wrote:
> 
>>Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
>>коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
>><название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
>>
>>Например:
>>foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961
> 
> 
> В последней версии gear это может быть записано в виде:

  Имеется в виду, gear-1.1.0?

> 
> diff: f9f580742b3b499e4a0fb298511f42f482a14928:. bbab731ee05b4a9211545309d9fdf2954a7e8961:. name=foo-0.1-alt-build.patch
> 
> (в name=... можно использовать @name@, @version@, @release@,
> @old_dir@, @new_dir@).  Можно также написать diff.gz или diff.bz2.
> Ограничение - нельзя указывать совсем произвольные sha1, это должны
> быть коммиты, предшествующие (непосредственно или через произвольное
> количество промежуточных коммитов) тому коммиту, из которого
> собирается пакет.
> 
...
> 
>>Мне кажется, удобнее исправлять исходники непосредственно в git,
>>скажем, в бранче devel, а не обновлять от версии к версии файлы
>>.patch.
> 
> 
> Тогда возникает вопрос, что делать при обновлении до новой версии.
> Естественный для git вариант - объединить изменения с новой версией
> через git-pull (т.е., merge), но при этом результат в общем случае уже
> не представляется в виде набора патчей - можно сделать только один
> общий патч от оригинальной версии к модифицированной.  Чтобы получить
> какое-то одно изменение в виде патча к текущей версии, придётся
> выполнять, например, git-cherry-pick в отдельной временной ветке
> (тащить его в историю пакета при таком способе работы бессмысленно -
> оно там уже есть, возможно, с исправлениями, внесёнными в ходе
> разрешения конфликтов при merge; единственная причина делать это -
> необходимость подготовки патча для передачи, например, в upstream).
> 
> Кстати, можно завести не один бранч devel, а несколько, куда разносить
> изменения, относящиеся к разным по смыслу исправлениям.

  +1, особенно -- если деление по бранчм осмысленное.

> 
>>Можно было бы просто паковать в SRPM модифицированное дерево
>>исходников, но тогда как указать на конкретное исправление
>>пользователям других дистрибутивов? Отсылать в наш git?
> 
> 
> Отсылать было бы хорошо в gitweb, но его у нас пока нет.  С другой
> стороны, если предполагается упразднение src.rpm, какое-то средство
> типа gitweb должно появиться раньше этого.

  +1

-- 

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


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

Re: [devel] gear и патчи

[Grigory Batalov]

On Mon, 27 Nov 2006 18:15:24 +0300
Aleksey Avdeev <solo@solin.spb.ru> wrote:

> >>Мне кажется, удобнее исправлять исходники непосредственно в git,
> >>скажем, в бранче devel, а не обновлять от версии к версии файлы
> >>.patch.
> > 
> > 
> > Тогда возникает вопрос, что делать при обновлении до новой версии.
> > Естественный для git вариант - объединить изменения с новой версией
> > через git-pull (т.е., merge), но при этом результат в общем случае уже
> > не представляется в виде набора патчей - можно сделать только один
> > общий патч от оригинальной версии к модифицированной.  Чтобы получить
> > какое-то одно изменение в виде патча к текущей версии, придётся
> > выполнять, например, git-cherry-pick в отдельной временной ветке
> > (тащить его в историю пакета при таком способе работы бессмысленно -
> > оно там уже есть, возможно, с исправлениями, внесёнными в ходе
> > разрешения конфликтов при merge; единственная причина делать это -
> > необходимость подготовки патча для передачи, например, в upstream).
> > 
> > Кстати, можно завести не один бранч devel, а несколько, куда разносить
> > изменения, относящиеся к разным по смыслу исправлениям.
> 
>   +1, особенно -- если деление по бранчм осмысленное.

  Теперь я понял, зачем у тебя в cks.git столько бранчей =)

-- 
 Григорий Баталов

Re: [devel] git и патчи

[Alex V. Myltsev]

On Mon, 27 Nov 2006 17:45:40 +0300
Grigory Batalov wrote:
> > [1] http://www.procode.org/stgit/
>   По моему, это вполне самостоятельный проект (на Питоне). Для gear
>   сгодилось бы решение попроще.
gear -- это один из инструментов, который позволяет из репозитария
легко собрать пакет. А уж как я работаю с репозитарием, чем его мержу,
обновляю и выкладываю на git.alt -- к gear никак не относится.

Даже исправлю, пожалуй, subject треда.

>   Оказывается, vsu@ уже кое-что сделал:
> http://lists.altlinux.org/pipermail/devel/2006-October/037580.html
Получается небольшой SCM внутри gear, который зачем-то хранит свою
служебную информацию не в .git, а в файлах репозитория. Это, конечно,
удобнее, чем хранить патчи в файлах, но не намного. Хочется какого-то
решения gitовой проблемы gitовыми средствами.

Я возлагаю ещё некоторые надежды на DarcsGit: может быть, он сумеет
принести в git лёгкость работы с патчами. Но у нас пока darcs без git.

-- 
Best regards,
Alex V. Myltsev.

Re: [devel] gear и патчи

[Aleksey Avdeev]

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

Grigory Batalov пишет:
> On Mon, 27 Nov 2006 18:15:24 +0300
> Aleksey Avdeev <solo@solin.spb.ru> wrote:
> 
> 
>>>>Мне кажется, удобнее исправлять исходники непосредственно в git,
>>>>скажем, в бранче devel, а не обновлять от версии к версии файлы
>>>>.patch.
>>>
>>>
>>>Тогда возникает вопрос, что делать при обновлении до новой версии.
>>>Естественный для git вариант - объединить изменения с новой версией
>>>через git-pull (т.е., merge), но при этом результат в общем случае уже
>>>не представляется в виде набора патчей - можно сделать только один
>>>общий патч от оригинальной версии к модифицированной.  Чтобы получить
>>>какое-то одно изменение в виде патча к текущей версии, придётся
>>>выполнять, например, git-cherry-pick в отдельной временной ветке
>>>(тащить его в историю пакета при таком способе работы бессмысленно -
>>>оно там уже есть, возможно, с исправлениями, внесёнными в ходе
>>>разрешения конфликтов при merge; единственная причина делать это -
>>>необходимость подготовки патча для передачи, например, в upstream).
>>>
>>>Кстати, можно завести не один бранч devel, а несколько, куда разносить
>>>изменения, относящиеся к разным по смыслу исправлениям.
>>
>>  +1, особенно -- если деление по бранчм осмысленное.
> 
> 
>   Теперь я понял, зачем у тебя в cks.git столько бранчей =)


  Там бранчи 3x классов:

1. "Технические" -- относительно независимые части пакета, могущие иметь
_отельную_ от остальных частей историю. Это сам спек, alt`специфичные
конфиги, патчи и пр.... Общие свойство: апстрим ими не занимается
(точнее -- ими могут заниматься несколько независимых апстримов).
Формальный признак: отдельная тег %source*/%patch* в спеке.

2. Бранчи для генерации патчей (на основе тегов).

3. Технологический клей. Это такие вещи как .gear-rules и, в случаи
cks.git, git2patch.sh.

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

-- 

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


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

Re: [devel] git и патчи

[Sergey Vlasov]

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

On Mon, Nov 27, 2006 at 06:55:55PM +0300, Alex V. Myltsev wrote:
> >   Оказывается, vsu@ уже кое-что сделал:
> > http://lists.altlinux.org/pipermail/devel/2006-October/037580.html
> Получается небольшой SCM внутри gear, который зачем-то хранит свою
> служебную информацию не в .git, а в файлах репозитория. Это, конечно,
> удобнее, чем хранить патчи в файлах, но не намного. Хочется какого-то
> решения gitовой проблемы gitовыми средствами.

Это не SCM, а решение другой проблемы - обеспечения идентичности
результатов применения gear к указанному коммиту вне зависимости от
содержимого .git/refs/ в репозитории.  По этой причине нельзя просто
использовать в .gear-rules имена тегов - во время выполнения gear эти
теги вполне могут отсутствовать в .git/refs/tags/, или их имена могут
указывать на совершенно другие объекты.  Если использовать в
.gear-rules только явные sha1, сохранять в .gear-tags/ ничего не
нужно, однако такой способ работы неудобен.

В принципе можно было бы обойтись без сохранения содержимого объектов
tag в файлах, оставив только список ссылок на коммиты (и так было в
первоначальной реализации).  Сейчас единственная польза от этих
объектов в том, что сохраняется некоторая информация об идентичности
использованного коммита тому, который был сделан в upstream (в
частности, тег может содержать подпись GPG).  Результат работы
git-archive при передаче тега совпадает с результатом, получаемым при
передаче коммита (в заголовок пишется sha1 коммита, sha1 тега не
сохраняется).

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

Re: [devel] gear и патчи

[Sergey Vlasov]

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

On Mon, Nov 27, 2006 at 06:15:24PM +0300, Aleksey Avdeev wrote:
> Sergey Vlasov пишет:
> > On Mon, Nov 27, 2006 at 03:48:26PM +0300, Grigory Batalov wrote:
> > 
> >>Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
> >>коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
> >><название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
> >>
> >>Например:
> >>foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961
> > 
> > 
> > В последней версии gear это может быть записано в виде:
> 
>   Имеется в виду, gear-1.1.0?

Да, в этой версии директива diff уже доступна.

> > diff: f9f580742b3b499e4a0fb298511f42f482a14928:. bbab731ee05b4a9211545309d9fdf2954a7e8961:. name=foo-0.1-alt-build.patch

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

Re: [devel] [JT] gear SCM

[Alex V. Myltsev]

On Mon, 27 Nov 2006 19:41:10 +0300
Sergey Vlasov wrote:
> On Mon, Nov 27, 2006 at 06:55:55PM +0300, Alex V. Myltsev wrote:
> > > http://lists.altlinux.org/pipermail/devel/2006-October/037580.html
> > Получается небольшой SCM внутри gear
> Это не SCM, а решение другой проблемы - обеспечения идентичности
> результатов применения gear к указанному коммиту вне зависимости от
> содержимого .git/refs/ в репозитории.
Типичная задача SCM -- по некоторому магическому идентификатору ("тэг",
"SHA1", "revision" etc) однозначно восстановить состояние исходников.

Другой вопрос, что многие SCM решают и другие задачи. Например, git
умеет построчно сравнивать два состояния (git diff), а gear нет
(максимум, что можно получить имеющимися средствами -- дифф,
заменяющий sha1 на sha1 -- not much help); darcs кое-как умеет
объединять две ветки разработки (darcs pull), а gear нет (нет
утилиты gear-merge, которая бы слила две ветки, одновременно
исправляя по необходимости содержимое gear-rules).

Anyway, my point is this: в gear сейчас две части -- 
1) инструмент для сборки пакета из репозитория и
2) наросшая на него SCM.
Эта вторая часть имеет право на существование, но я ещё попробую
поискать ей замену; вполне вероятно, что patch management'ом над GIT
кто-нибудь уже занимался и написал для этого что-нибудь не
ALT-специфичное. Ну если нет, тогда надо gear дописывать, конечно.

-- 
Best regards,
Alex V. Myltsev.

Re: [devel] [JT] gear SCM

[Dmitry V. Levin]

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

On Tue, Nov 28, 2006 at 01:54:56AM +0300, Alex V. Myltsev wrote:
[...]
> Anyway, my point is this: в gear сейчас две части -- 
> 1) инструмент для сборки пакета из репозитория и
> 2) наросшая на него SCM.
> Эта вторая часть имеет право на существование, но я ещё попробую
> поискать ей замену; вполне вероятно, что patch management'ом над GIT
> кто-нибудь уже занимался и написал для этого что-нибудь не
> ALT-специфичное.

Это точно существует, ты же сам приводил пример двух таких "что-нибудь".

> Ну если нет, тогда надо gear дописывать, конечно.

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


-- 
ldv

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