[devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

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

Нечто подобное уже описывалось здесь:

http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream

Но в процессе выполнения у меня возникло множество вопросов, поэтому я
попытался описать примерно то же самое, но более доступно для таких, как
я сам ;) Отправляю пока сюда, а не в вики, потому что надеюсь на
конструктивную критику: очень интересно, что я сделал неправильно и не
оптимально. Также прошу дополнить пример соответствующими примерами для
работы с svn и cvs (у меня в качестве upstream scm рассматривается
только git, о своих проблемах с svn я писал несколько выше)

Спасибо всем, кто мне помогал: Алексею Авдееву, Владимиру Камарзину, 
Сергею Власову и многим другим ...

------------------------------------------------------------------------

<< Сопровождение пакета в git.alt и взаимодействие с upstream scm на
примере dbmail >>

Мне удобнее всего вести разработку в 2-х бранчах:

1) dbmail_2_2 - импортируется из upstream scm, причем только тот бранч,
который соответствует версии нашего пакета
2) srpms - все, что необходимо для сборки пакета

В самом начале необходимо создать каталог dbmail, в котором будет
вестись разработка, и инициализировать репозитарий c помощью
git-init-db, перейдя в этот каталог. Это необходимо сделать каждому
разработчику, принимающему участие в разработке пакета.

Затем необходимо импортировать содержимое последнего пакета (можно не
только последнего) в в бранч srpms репозитария с помощью gear-srpmimport
--import-only, перейти в бранч rpms с помощью git-checkout и удалить
распакованные исходники (git-rm -r -f dbmail), т.к. мы будем 
генерировать тарболл с исходниками из бранча upstream scm. Эта операция 
выполняется один раз одним разработчиком.

Остальные операции будут выполняться разработчиками регулярно по мере
необходмости:

1) Импорт из upstream scm и сборка пакета:

    * для git:  git-fetch [url] [remote tag]:[local tag] - в нашем
случае команда будет выглядеть так:

git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2

    * для svn: ?
    * для cvs: ?

После импорта необходимо перейти в новый бранч (git-checkout dbmail_2_2) 
найти таг, на основе которого будет генерироваться тарболл, или создать 
его с помощью git-tag, указав идентификатор коммита или имя бранча - в 
этом случае будет взят последний на момент создания тага коммит в 
бранче. Дерево git удобнее всего изучать с помощью gitk --all, список 
тагов - с помощью git-show-ref. В нашем случае команда создания тага 
будет выглядеть так:

git-tag -a -m 'new dbmail 2.2.4 09.04.2007 21:40' 
dbmail/2.2.4.200704092140 a42aa96f31a555c2b20d600cdd6e961c0d9cfb67

Соданный таким образом новый или уже существующий коммит необходимо 
подшить к бранчу srpms (предварительно перейдя в него - git-checkout 
srpms), чтобы он был доступен при генерации тарболла:

git-merge -s ours 'Using upstream branch' HEAD dbmail/2.2.4.200704092140

Затем необходимо обновить .gear-tags с помощью gear-update-tag -a

Идентификатор тага необходимо указать в файле .gear-rules, заменив
строку, начинающуюся с tar.[gz|bz2] на:

tar.[gz|bz2]: [tag]:. name=[tarball]

В нашем случае запись будет основана на текущей дате/времени импорта из
upstream scm и будет выглядеть так:

tar.gz: dbmail/2.2.4.200704090940:. name=dbmail-2.2.4.git200704090940

После этих подготовительных операций необходимо описать в спеке, что же
мы сделали (как минимум увеличить номер версии и добавить запись в
%changelog), и попытаться собрать src.rpm с помощью:

gear --commit --rpmbuild -- rpm -bs --nodeps --sign

и

gear --commit --hasher -- hsh ~/hasher/

Если все прошло удачно, можно закоммитить изменения:

gear-commit -a

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

2) Выгрузка изменений в локальном репозитарии на git.alt:

Для выгрузки необходимо создать файл .git/remotes/origin с таким содержимым:

URL: git.alt:packages/dbmail.git
Push: refs/heads/*:refs/heads/*
Push: refs/tags/*:refs/tags/*

Выгружать можно командой git-push

3) Загрузка изменений из git.alt в локальный репозитарий:

Необходимо повторить следующее для каждого используемого бранча:

git-fetch [url] [remote branch]:[local branch]

В нашем случае:

git-fetch git.alt:packages/dbmail dbmail_2_2:dbmail_2_2
git-fetch git.alt:packages/dbmail srpms:srpms

Бранч dbmail_2_2 можно загружать и из
http://nfg3.nfgs.net/git/dbmail.git, но это будет медленнее. В тех
случаях, когда необходимо обновить dbmail из upstream scm, особого
выбора нет ;)

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

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey Tourbin]

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

On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
> http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
> http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream

В общем, я бы не стал делать, как там написано.  По-моему, Вам и другим
maintainer'ам будет проще всего работать с таким git репозитарием, в
котором содержимое рабочего бранча (master) максимально приближено к
результату rpm -bp.  Тогда можно сразу править что нужно и посто
коммитить.  Это не исключает .gear-tags.

Могу подробнее объяснть, как я бы сделал, если не понятно.

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Dmitry V. Levin]

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

On Mon, Apr 09, 2007 at 11:52:27PM +0400, Alexey Tourbin wrote:
> On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
> > http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
> > http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
> 
> В общем, я бы не стал делать, как там написано.

Ты имеешь в виду первый рецепт (когда есть upstream scm) или второй рецепт
(когда есть только upstream tarball)?

> Могу подробнее объяснть, как я бы сделал, если не понятно.

Пока не понятно. ;)


-- 
ldv

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey Tourbin]

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

On Tue, Apr 10, 2007 at 12:01:51AM +0400, Dmitry V. Levin wrote:
> On Mon, Apr 09, 2007 at 11:52:27PM +0400, Alexey Tourbin wrote:
> > On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
> > > http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
> > > http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
> > 
> > В общем, я бы не стал делать, как там написано.
> 
> Ты имеешь в виду первый рецепт (когда есть upstream scm) или второй рецепт
> (когда есть только upstream tarball)?

У мутта 1.5 вроде тоже есть git.

В случае с тарболлами иногда удобнее деражть содержимое тарболла в
подкаталоге, а патчи держать отдельно; а иногда удобнее прикладывать
патчи к тарболлу, тогда подкаталог не нужен (а spec положить прямо в
каталог, это не криминально).

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

Я например не знаю, как мне сейчас с netpbm в этом отношении быть.
Всё время откладываю его в долгий ящик. :(

> > Могу подробнее объяснть, как я бы сделал, если не понятно.
> Пока не понятно. ;)

Допустим что есть апстримный project.git, в котором есть таги 1.1, 1.2,
1.3 и основной бранч master, который содержит эти таги.  (На самом деле не
важно, git это или git-svnimport или git-cvsimport.)

Допустим, что у нас есть project-1.1.src.rpm и project-1.2.src.rpm.
Мы хотим импортировать эти src.rpm'ы и собрать новый релиз 1.3 (или
прямо origin).

Я бы имортировал вот как.  Сначала клонируем апстрим, имеем бранч
origin.

Преподолжим, что в src.rpm'ах есть всего один "большой" тарболл с
подкаталогом, а других тарболлов нет (но, возможно есть патчи).
Тогда можно применить модифицированный gear-srpmimport, который
не создает подкаталога, чтобы избежать перемещения файлов.

Импортируем src.rpm'ы, привязывая их к апстримным тагам.

$ git-checkout -b srpms 1.1
$ gear-srpmimport project-1.1.src.rpm
$ git-branch foo 1.2
$ git-pull --no-commit -s ours . foo && git-branch -D foo
$ gear-srpmimport project-1.2.src.rpm

Здесь происходит merge апстримного тага 1.2 и нашей предыдущей сборки
1.1-alt1.  С первого раза этот трюк, наверное, сложно понять.  К
сожалению, я не знаю, как это можно предельно понятно объяснить.

Теперь мы стоим на бранче srpms, и на него показывает таг 1.2-alt1.
Перименовываем бранч srpms в бранч master и продолжаем с ним работать
как с основным бранчем для подготовки пакетов.

$ git-branch -D master
$ git-checkout -b master srpms
$ git-branch -D srpms

Нужно проверить, что git-diff 1.2..1.2-alt1 показывает только *.spec и
.gear-rules (кроме, быть может, $Id$ и прочей мишуры).

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

Если приложили патчи, желательно добавить %release в название тарболла и
в .gear-rules.  Также желательно разжать тарболл, чтобы был просто *.tar.

Дальше делаем
$ git-pull . origin

Наша сборка переместилась на origin.  Теперь можно сделать

$ gear --rpm -- rpm -bc

Если всё работает, то остается исправить version и release в спеке на
1.3-alt1 (или 1.4-alt0.1) и сделать gear-commit -a.

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

[devel] Subversion tags (was: Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm)

[Grigory Batalov]

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

On Mon, 9 Apr 2007 23:19:17 +0400, Alexey Tourbin wrote:

> >     * для git:  git-fetch [url] [remote tag]:[local tag] - в нашем
> > случае команда будет выглядеть так:
> > 
> > git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2
> > 
> >     * для svn: ?
> 
> git-svnimport или git-svn

  А как поступать с тегами Subversion типа $Date$ ?
  При импортировании в git они так и остаются нераскрытыми, тогда как
  в распространяемых тарболах обычно преобразуются к

  $Date: 2006-10-31 20:28:54 +0000 (Tue, 31 Oct 2006) $

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

-- 
 Grigory Batalov,
 ALT Linux Team

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

Re: [devel] Subversion tags (was: Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm)

[Alexey Tourbin]

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

On Tue, Apr 10, 2007 at 03:33:38AM +0400, Grigory Batalov wrote:
> On Mon, 9 Apr 2007 23:19:17 +0400, Alexey Tourbin wrote:
> 
> > >     * для git:  git-fetch [url] [remote tag]:[local tag] - в нашем
> > > случае команда будет выглядеть так:
> > > 
> > > git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2
> > > 
> > >     * для svn: ?
> > 
> > git-svnimport или git-svn
> 
>   А как поступать с тегами Subversion типа $Date$ ?
>   При импортировании в git они так и остаются нераскрытыми, тогда как
>   в распространяемых тарболах обычно преобразуются к
> 
>   $Date: 2006-10-31 20:28:54 +0000 (Tue, 31 Oct 2006) $
> 
>   и т.п. Можно было бы не обращать на них внимания, но иногда программы
>   формируют свою версию при выводе на экран именно из таких тегов.

Лучше чтобы оставались не раскрытыми.  Это только в очень редких случаях
нужно, чтобы они раскрывались, например, если в manaul page это
используется как дата и т.п.  Иначе будут засоряться изменения, будут
проблему с мержами...

У git-cvsimport есть опция -k.

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Понял я действительно мало, но по мотивам обсуждения родились такие 
выводы: действительно, проще вести сборку пакета в одном бранче. Т.е. 
процедура такова:

1) Импортируем последний src.rpm (смысл импорта нескольких от меня, 
честно говоря, ускользает: я вряд ли чего полезного почерпну из старых 
спеков)

2) Каталог с исходниками очищаем и делаем в него git-pull из требуемого 
апстримного бранча (или git-svnimport/git-cvsimport) - мне все-таки 
удобнее держать исходники отдельно. Когда основным поддерживаемым 
апстримным бранчем станет другой, удаляем все из каталога и делаем в 
него git-pull из этого нового бранча.

3) В .gear-rules соответвенно указываем существующий или созданный нами 
таг, ссылающийся на какой-либо коммит апстрима - танцы с merge, 
получается, не нужны

4) Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
собираю апстримные исходники и тестирую разультат где-то отдельно 
(иногда в системе, в которой не жалко сделать make install ;) ), 
изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
способ с отдельным бранчем под каждый патч?

Вроде это должно работать. Какие имеются противопоказания?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070410 00:38]:
> У мутта 1.5 вроде тоже есть git.
Он там такой, что лучше бы его не было вообще...  Но вот Brendan
Cully девелопает всё в mercurial, туда я ещё не добрался.

> В случае с тарболлами иногда удобнее деражть содержимое тарболла в
> подкаталоге, а патчи держать отдельно; а иногда удобнее прикладывать
> патчи к тарболлу, тогда подкаталог не нужен (а spec положить прямо в
> каталог, это не криминально).
Мне почему-то удобнее держать сорцы в подкаталоге, ради этого всё
и затевалось.  Проблема в том, что в diff: попадают спек и
.gear-*, "как-то неаккуратненько".

P.S. А master действительно соответствует rpm -bp, только в
описании процесса я остановился на импорте.

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

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

>>    * для svn: ?
> 
> 
> git-svnimport или git-svn

Единственное, что у меня заработало:

git-init-db
git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve
git-svn-fetch

Но таким образом я получил весь репозитарий полностью, а мне достаточно 
бранча libsieve_2_2_branch - 
http://libsieve.svn.sourceforge.net/viewvc/libsieve/branches/libsieve_2_2_branch/

Как вытащить только его? Другой вопрос: ладно, я вытащил все, как теперь 
получить исходники, соответствующие этому бранчу? Я вижу:

Т.е. нет и намека на бранч libsieve_2_2_branch :(

Как пользоваться git-svnimport я вообще не понял. Может кто-нибудь 
показать, с какими параметрами его вызвать, чтобы получить результат, 
хотя бы аналогичный git-svn?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

> Я вижу:

$ git-branch
* master

$ git-show-ref
8e3b606462bf08c90af899346835400af7161ab4 refs/heads/master
8e3b606462bf08c90af899346835400af7161ab4 refs/remotes/git-svn

> Т.е. нет и намека на бранч libsieve_2_2_branch :(

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Vladimir V. Kamarzin]

>>>>> On 10 Apr 2007 at 12:44 "EP" == Eugene Prokopiev writes:

 EP> Как пользоваться git-svnimport я вообще не понял. Может кто-нибудь 
 EP> показать, с какими параметрами его вызвать, чтобы получить результат, 
 EP> хотя бы аналогичный git-svn?

Я предпочитаю пока что использовать именно git-svnimport, потому как он
создаёт структуру в git, аналогичную svn. Т.е. бранчи, имеющиеся в svn,
появляются и в git, таги тоже.

На примере lighttpd:

vvk@vvk ~/devel/lighttpd % git branch
  lighttpd-1.3.x
  lighttpd-1.4.11-ssl-fixes
  lighttpd-1.4.x
  lighttpd-merge-1.4.x
* master
  trunk
vvk@vvk ~/devel/lighttpd %
vvk@vvk ~/devel/lighttpd % git-svnimport -v -o trunk svn://svn.lighttpd.net/lighttpd/

Последняя команда применяется периодически для импорта.

-- 
vvk

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Vladimir V. Kamarzin пишет:
>>>>>>On 10 Apr 2007 at 12:44 "EP" == Eugene Prokopiev writes:
> 
> 
>  EP> Как пользоваться git-svnimport я вообще не понял. Может кто-нибудь 
>  EP> показать, с какими параметрами его вызвать, чтобы получить результат, 
>  EP> хотя бы аналогичный git-svn?
> 
> Я предпочитаю пока что использовать именно git-svnimport, потому как он
> создаёт структуру в git, аналогичную svn. Т.е. бранчи, имеющиеся в svn,
> появляются и в git, таги тоже.
> 
> На примере lighttpd:
> 
> vvk@vvk ~/devel/lighttpd % git branch
>   lighttpd-1.3.x
>   lighttpd-1.4.11-ssl-fixes
>   lighttpd-1.4.x
>   lighttpd-merge-1.4.x
> * master
>   trunk
> vvk@vvk ~/devel/lighttpd %
> vvk@vvk ~/devel/lighttpd % git-svnimport -v -o trunk svn://svn.lighttpd.net/lighttpd/
> 
> Последняя команда применяется периодически для импорта.
> 

$ git-init-db
Initialized empty Git repository in .git/

$ git-svnimport -v -o trunk 
https://libsieve.svn.sourceforge.net/svnroot/libsieve
Branch 'trunk' does not exist.
Either use the correct '-o branch' option,
or import to a new repository.

$ gear-srpmimport --branch=master ~/libsieve-2.2.4-alt1.src.rpm
...
$ git-svnimport -v -o master 
https://libsieve.svn.sourceforge.net/svnroot/libsieve
'/home/john/git/libsieve/.git/svn2git' does not exist.
You need that file for incremental imports.

Покажите .git/svn2git ;)

А один бранч вытащить в принципе нельзя?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

> 2) Каталог с исходниками очищаем и делаем в него git-pull из требуемого 
> апстримного бранча (или git-svnimport/git-cvsimport) - мне все-таки 
> удобнее держать исходники отдельно. Когда основным поддерживаемым 
> апстримным бранчем станет другой, удаляем все из каталога и делаем в 
> него git-pull из этого нового бранча.

гладко было на бумаге ...

$ git-init-db
$ gear-srpmimport --branch=master ~/RPM/SRPMS/dbmail-2.2.4-alt1.src.rpm
$ cd dbmail/
$ rm -rf *
$ git-pull http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:
got 149777bf14442d761d3f0a5c443d1b5c27016305
  100% (533/533) done
Auto-merged dbmail.conf
CONFLICT (add/add): Merge conflict in dbmail.conf
Automatic merge failed; fix conflicts and then commit the result.

У меня есть свой dbmail.conf, который идет в пакет, а есть такой же файл 
в исходниках, который я не опакечиваю - собственно, это только одна из 
причин держать исходники апстрима в отдельном каталоге.

Интересно, что git-pull выгрузил все, что ему полагается не в текущий 
каталог, а в каталог, в котором есть .git, т.е. уровнем выше.

До того я использовал git-rm -r -f dbmail/* вместо cd dbmail/; rm -rf *, 
однако попутно был удален сам каталог dbmail. Я создал его заново, но 
как добавить с помощью git-add, не понял: git-add утверждает, что он 
умеет добавлять только файлы и симлинки. Вызов git-pull после cd в этот 
каталог приводит к результатам, показанным выше.

Т.е. или все в одном бранче и в одном каталоге, или в разных бранчах 
(+небходимость merge)?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Vladimir V. Kamarzin]

>>>>> On 10 Apr 2007 at 13:10 "EP" == Eugene Prokopiev writes:

 EP> $ git-init-db
 EP> Initialized empty Git repository in .git/

Это не нужно

 EP> $ git-svnimport -v -o trunk 
 EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve
 EP> Branch 'trunk' does not exist.
 EP> Either use the correct '-o branch' option,
 EP> or import to a new repository.

 А уж если сделали git init, то бранч для импорта тоже нужно сделать.

 EP> Покажите .git/svn2git ;)

Нету такого ;)

 EP> А один бранч вытащить в принципе нельзя?

Поробуйте так:

git init
git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch
git-svn fetch

-- 
vvk

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Vladimir V. Kamarzin пишет:
>>>>>>On 10 Apr 2007 at 13:10 "EP" == Eugene Prokopiev writes:
> 
> 
>  EP> $ git-init-db
>  EP> Initialized empty Git repository in .git/
> 
> Это не нужно
> 
>  EP> $ git-svnimport -v -o trunk 
>  EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve
>  EP> Branch 'trunk' does not exist.
>  EP> Either use the correct '-o branch' option,
>  EP> or import to a new repository.
> 
>  А уж если сделали git init, то бранч для импорта тоже нужно сделать.
> 
>  EP> Покажите .git/svn2git ;)
> 
> Нету такого ;)
> 
>  EP> А один бранч вытащить в принципе нельзя?
> 
> Поробуйте так:
> 
> git init
> git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch
> git-svn fetch

Спасибо. Похоже, что это как раз то, что нужно.

Тут случай как раз удачный: исходники уже вынесены в отдельный каталог. 
В менее удачных случаях 
(http://svn.ic-s.nl/websvn/listing.php?repname=DBMail&path=%2Fbranches%2Fdbmail_2_2_branch%2F&rev=0&sc=0) 
можно извлекать исходники в отдельный каталог?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey Tourbin]

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

On Tue, Apr 10, 2007 at 10:44:19AM +0400, Eugene Prokopiev wrote:
> >>    * для svn: ?
> > 
> > 
> > git-svnimport или git-svn
> 
> Единственное, что у меня заработало:
> 
> git-init-db
> git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve
> git-svn-fetch
> 
> Но таким образом я получил весь репозитарий полностью, а мне достаточно 
> бранча libsieve_2_2_branch - 
> http://libsieve.svn.sourceforge.net/viewvc/libsieve/branches/libsieve_2_2_branch/

Лучше вытаскивать полностью.  Он же типа умеет делать мерж, когда одна
один svn'овский бранчи вливается в другой.  Или типа не умеет.  Не знаю. :)

> Как вытащить только его? Другой вопрос: ладно, я вытащил все, как теперь 
> получить исходники, соответствующие этому бранчу? Я вижу:
> 
> Т.е. нет и намека на бранч libsieve_2_2_branch :(

git-branch -r

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Alexey Tourbin пишет:
> On Tue, Apr 10, 2007 at 10:44:19AM +0400, Eugene Prokopiev wrote:
> 
>>>>   * для svn: ?
>>>
>>>
>>>git-svnimport или git-svn
>>
>>Единственное, что у меня заработало:
>>
>>git-init-db
>>git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve
>>git-svn-fetch
>>
>>Но таким образом я получил весь репозитарий полностью, а мне достаточно 
>>бранча libsieve_2_2_branch - 
>>http://libsieve.svn.sourceforge.net/viewvc/libsieve/branches/libsieve_2_2_branch/
> 
> 
> Лучше вытаскивать полностью.  Он же типа умеет делать мерж, когда одна
> один svn'овский бранчи вливается в другой.  Или типа не умеет.  Не знаю. :)

а зачем мне вытаскивать лишнее?

бранчи ведь независимы, и если в апстриме что-то с чем-то смержат, 
нужный мне бранч не сломается ;)

>>Как вытащить только его? Другой вопрос: ладно, я вытащил все, как теперь 
>>получить исходники, соответствующие этому бранчу? Я вижу:
>>
>>Т.е. нет и намека на бранч libsieve_2_2_branch :(
> 
> 
> git-branch -r

попробую

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey Tourbin]

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

On Tue, Apr 10, 2007 at 01:35:41PM +0400, Eugene Prokopiev wrote:
> > Лучше вытаскивать полностью.  Он же типа умеет делать мерж, когда одна
> > один svn'овский бранчи вливается в другой.  Или типа не умеет.  Не знаю. :)
> 
> а зачем мне вытаскивать лишнее?
> 
> бранчи ведь независимы, и если в апстриме что-то с чем-то смержат, 
> нужный мне бранч не сломается ;)

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

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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Alexey Tourbin пишет:
> On Tue, Apr 10, 2007 at 01:35:41PM +0400, Eugene Prokopiev wrote:
> 
>>>Лучше вытаскивать полностью.  Он же типа умеет делать мерж, когда одна
>>>один svn'овский бранчи вливается в другой.  Или типа не умеет.  Не знаю. :)
>>
>>а зачем мне вытаскивать лишнее?
>>
>>бранчи ведь независимы, и если в апстриме что-то с чем-то смержат, 
>>нужный мне бранч не сломается ;)
> 
> 
> Вы хотите не мало.  Если что-то с чем-то смержили, то git-svn
> предполагает, что нужный коммит или релиз уже есть.  В общем,
> говорю же, не уверен, как это там всё на самом деле работает...

хм... а есть тут такие, которые уверены?

другой вопрос: а если я вытягиваю требуемый мне бранч из git с помощью, 
например, git-pull, все сказанное остается в силе, т.е. может и сломаться?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

> git-branch -r

$ git-branch -r
   git-svn

libsieve_2_2_branch нет :(

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Aleksey Avdeev]

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

Alexey Tourbin пишет:
> On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
>> http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
>> http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
> 
> В общем, я бы не стал делать, как там написано.  По-моему, Вам и другим
> maintainer'ам будет проще всего работать с таким git репозитарием, в
> котором содержимое рабочего бранча (master) максимально приближено к
> результату rpm -bp.  Тогда можно сразу править что нужно и посто
> коммитить.  Это не исключает .gear-tags.

  -1

  Мне удобнее держать полученное из старонних источников отдельно, с
мимниумом изменений: продукты полученные от поставщика могут требовать
предварительной обработки (мытья, например) и до её проведения --
незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
-- смешаю как сочту нужным ;-)).

-- 

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



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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Aleksey Avdeev пишет:
> Alexey Tourbin пишет:
> 
>>On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
>>
>>>http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
>>>http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
>>
>>В общем, я бы не стал делать, как там написано.  По-моему, Вам и другим
>>maintainer'ам будет проще всего работать с таким git репозитарием, в
>>котором содержимое рабочего бранча (master) максимально приближено к
>>результату rpm -bp.  Тогда можно сразу править что нужно и посто
>>коммитить.  Это не исключает .gear-tags.
> 
> 
>   -1
> 
>   Мне удобнее держать полученное из старонних источников отдельно, с
> мимниумом изменений: продукты полученные от поставщика могут требовать
> предварительной обработки (мытья, например) и до её проведения --
> незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
> -- смешаю как сочту нужным ;-)).

Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
требуют регулярного слияния, если же просто вынести исходники апстрима в 
отдельный каталог, то получим и разделение (пока для меня в принципе 
достаточное), и уменьшение количества операций.

Вот правда вынести исходники апстрима в отдельный каталогу меня не 
выходит :(

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Aleksey Avdeev пишет:
>> Alexey Tourbin пишет:
>>
>>> On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
>>>
>>>> http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
>>>> http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
>>> В общем, я бы не стал делать, как там написано.  По-моему, Вам и другим
>>> maintainer'ам будет проще всего работать с таким git репозитарием, в
>>> котором содержимое рабочего бранча (master) максимально приближено к
>>> результату rpm -bp.  Тогда можно сразу править что нужно и посто
>>> коммитить.  Это не исключает .gear-tags.
>>
>>   -1
>>
>>   Мне удобнее держать полученное из старонних источников отдельно, с
>> мимниумом изменений: продукты полученные от поставщика могут требовать
>> предварительной обработки (мытья, например) и до её проведения --
>> незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>> -- смешаю как сочту нужным ;-)).
> 
> Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
> требуют регулярного слияния, если же просто вынести исходники апстрима в 
> отдельный каталог, то получим и разделение (пока для меня в принципе 
> достаточное), и уменьшение количества операций.

  Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
сложнее...

> 
> Вот правда вынести исходники апстрима в отдельный каталогу меня не 
> выходит :(

  Я незнаю приемлимово, без большого дифа, решения. (Понятно, что в
данном случаи, этот большой diff несоздаёт кучи новых объектов
хранения... Но что-то меня сдесь настораживает.)

-- 

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



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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

>>>  Мне удобнее держать полученное из старонних источников отдельно, с
>>>мимниумом изменений: продукты полученные от поставщика могут требовать
>>>предварительной обработки (мытья, например) и до её проведения --
>>>незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>>>-- смешаю как сочту нужным ;-)).
>>
>>Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
>>требуют регулярного слияния, если же просто вынести исходники апстрима в 
>>отдельный каталог, то получим и разделение (пока для меня в принципе 
>>достаточное), и уменьшение количества операций.
> 
> 
>   Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
> сложнее...

Кажется, выше я писал, каким образом я выцепляю изменения:

> Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
> раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
> собираю апстримные исходники и тестирую разультат где-то отдельно 
> (иногда в системе, в которой не жалко сделать make install  ;)  ), 
> изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
> gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
> способ с отдельным бранчем под каждый патч?

Если вы делаете иначе, пожалуйста, расскажите как (по возможности 
подробно, с командами). Особенно интересуют преимущества по сравнению с 
приведенным выше способом.

>>Вот правда вынести исходники апстрима в отдельный каталогу меня не 
>>выходит :(
> 
> 
>   Я незнаю приемлимово, без большого дифа, решения. (Понятно, что в
> данном случаи, этот большой diff несоздаёт кучи новых объектов
> хранения... Но что-то меня сдесь настораживает.)

Что-то я потерял нить ... О каком дифе идет речь и как это связано с 
хранением исходников в отдельном каталоге вместо отдельного бранча?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Vladimir V. Kamarzin пишет:
>>>>>>On 10 Apr 2007 at 13:10 "EP" == Eugene Prokopiev writes:
> 
> 
>  EP> $ git-init-db
>  EP> Initialized empty Git repository in .git/
> 
> Это не нужно
> 
>  EP> $ git-svnimport -v -o trunk 
>  EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve
>  EP> Branch 'trunk' does not exist.
>  EP> Either use the correct '-o branch' option,
>  EP> or import to a new repository.
> 
>  А уж если сделали git init, то бранч для импорта тоже нужно сделать.
> 
>  EP> Покажите .git/svn2git ;)
> 
> Нету такого ;)
> 
>  EP> А один бранч вытащить в принципе нельзя?
> 
> Поробуйте так:
> 
> git init
> git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch
> git-svn fetch

Таким образом я вытяну svn-бранч libsieve_2_2_branch в текущий локальный 
бранч. Можно ли указать, в какой бранч вытягивать? Если указать -b 
libsieve_2_2, svn-бранч libsieve_2_2_branch все равно вытягивается в 
текущий локальный бранч со следующими словами:

fatal: ambiguous argument 'libsieve_2_2': unknown revision or path not 
in the working tree.

Очевидное решение - создать локальный бранч libsieve_2_2:

$ git-branch libsieve_2_2
fatal: Not a valid branch point: 'master'.

Бранча master у меня действительно нет (и он мне не нужен), есть только 
бранч srpms, созданный gear-srpmsimport. Как быть?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>>>  Мне удобнее держать полученное из старонних источников отдельно, с
>>>> мимниумом изменений: продукты полученные от поставщика могут требовать
>>>> предварительной обработки (мытья, например) и до её проведения --
>>>> незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>>>> -- смешаю как сочту нужным ;-)).
>>> Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
>>> требуют регулярного слияния, если же просто вынести исходники апстрима в 
>>> отдельный каталог, то получим и разделение (пока для меня в принципе 
>>> достаточное), и уменьшение количества операций.
>>
>>   Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
>> сложнее...
> 
> Кажется, выше я писал, каким образом я выцепляю изменения:
> 
>> Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
>> раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
>> собираю апстримные исходники и тестирую разультат где-то отдельно 
>> (иногда в системе, в которой не жалко сделать make install  ;)  ), 
>> изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
>> gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
>> способ с отдельным бранчем под каждый патч?
> 
> Если вы делаете иначе, пожалуйста, расскажите как (по возможности 
> подробно, с командами). Особенно интересуют преимущества по сравнению с 
> приведенным выше способом.

  Патчи, к которым я приложил руку после перехода на git, в виде файлов
я не храню (только унаследываемые). Для из поучения -- использую diff
между тегами, благо gear это позволяет. (Пока непозволял -- использовал
самописанный велосипед для автоматизированного создания патчей на базе
заданных коммитов.)

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

> 
>>> Вот правда вынести исходники апстрима в отдельный каталогу меня не 
>>> выходит :(
>>
>>   Я незнаю приемлимово, без большого дифа, решения. (Понятно, что в
>> данном случаи, этот большой diff несоздаёт кучи новых объектов
>> хранения... Но что-то меня сдесь настораживает.)
> 
> Что-то я потерял нить ... О каком дифе идет речь и как это связано с 
> хранением исходников в отдельном каталоге вместо отдельного бранча?

  О diff между соседними коммитами, при перемеи сорцов в другой каталог.

-- 

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



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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Aleksey Avdeev пишет:
> Eugene Prokopiev пишет:
> 
>>>>> Мне удобнее держать полученное из старонних источников отдельно, с
>>>>>мимниумом изменений: продукты полученные от поставщика могут требовать
>>>>>предварительной обработки (мытья, например) и до её проведения --
>>>>>незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>>>>>-- смешаю как сочту нужным ;-)).
>>>>
>>>>Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
>>>>требуют регулярного слияния, если же просто вынести исходники апстрима в 
>>>>отдельный каталог, то получим и разделение (пока для меня в принципе 
>>>>достаточное), и уменьшение количества операций.
>>>
>>>  Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
>>>сложнее...
>>
>>Кажется, выше я писал, каким образом я выцепляю изменения:
>>
>>
>>>Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
>>>раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
>>>собираю апстримные исходники и тестирую разультат где-то отдельно 
>>>(иногда в системе, в которой не жалко сделать make install  ;)  ), 
>>>изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
>>>gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
>>>способ с отдельным бранчем под каждый патч?
>>
>>Если вы делаете иначе, пожалуйста, расскажите как (по возможности 
>>подробно, с командами). Особенно интересуют преимущества по сравнению с 
>>приведенным выше способом.
> 
> 
>   Патчи, к которым я приложил руку после перехода на git, в виде файлов
> я не храню (только унаследываемые). Для из поучения -- использую diff
> между тегами, благо gear это позволяет. (Пока непозволял -- использовал
> самописанный велосипед для автоматизированного создания патчей на базе
> заданных коммитов.)
> 
>   Поскольку, для работы с данной схемой всё равно нужны фиктивные мержи
> и gear-upate-tag, у меня нет усложнения техпроцесса при хранении
> исходников в отдельном банче. Это, в свою очередь, позволяет
> небеспокоется о имени каталога, куда апстрим пакует исходники (если они
> распространяются в тарбл, то версия часто присутствует в имени
> каталога): достаточно соглашения, что всё находящееся в корне бранча с
> сорцами -- сорцы, полученные из внешнего источника (возможно --
> правленные, но в данном контексте это не важно).

Под каждый свой патч вы выделяете отдельный бранч? Из сказанного вами 
вроде этого не следует, хотя я с трудом представляю себе обратное. Можно 
все-таки пример?

Вот допустим, мне нужно изменить что либо в Makefile.in, я создаю бранч 
(git-branch dbmail_2_2_makefile_patch dbmail_2_2), что я получаю? Копию 
предыдущего без тагов? А идентификаторы коммитов будут такие же?

Теперь мне нужно сделать таг, слить его с бранчем srpms, чтобы сделать 
положить в пакет исходники нового бранча, исправить .gear-rules и 
собрать пакет.

Потом установить его в hasher, чтобы в рабочей системе не устраивать 
свинство с *-devel и промежуточными результатами сборки - опа, а какие 
тогда преимущества этого подхода, если все сводится к старому способу с 
.orig?

Значит собирать надо в бранче (ладно, иногда на свинство можно 
согласиться ;) ), хорошо, собираю, какой командой теперь разницу 
выгрузить в файл, перейдя в бранч srpms?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Aleksey Avdeev пишет:
>> Eugene Prokopiev пишет:
>>
>>>>>> Мне удобнее держать полученное из старонних источников отдельно, с
>>>>>> мимниумом изменений: продукты полученные от поставщика могут требовать
>>>>>> предварительной обработки (мытья, например) и до её проведения --
>>>>>> незачем их мешать их с остальными инградиентами (на своей кухне я хозяин
>>>>>> -- смешаю как сочту нужным ;-)).
>>>>> Это верно, однако разделение можно понимать по разному ;) Разные бранчи 
>>>>> требуют регулярного слияния, если же просто вынести исходники апстрима в 
>>>>> отдельный каталог, то получим и разделение (пока для меня в принципе 
>>>>> достаточное), и уменьшение количества операций.
>>>>  Деление -- получаем. Но выцепить изменения сделанные в исходниках уже
>>>> сложнее...
>>> Кажется, выше я писал, каким образом я выцепляю изменения:
>>>
>>>
>>>> Патчи, если таковые имеются, можно держать в отдельных файлах, как и 
>>>> раньше. Если эти патчи мои, то делаю я их старым проверенным способом: 
>>>> собираю апстримные исходники и тестирую разультат где-то отдельно 
>>>> (иногда в системе, в которой не жалко сделать make install  ;)  ), 
>>>> изменяемые файлы перед изменением обзываю .orig, после изменений делаю 
>>>> gendiff. Даст ли мне ощутимые преимущества какой-нибудь более правильный 
>>>> способ с отдельным бранчем под каждый патч?
>>> Если вы делаете иначе, пожалуйста, расскажите как (по возможности 
>>> подробно, с командами). Особенно интересуют преимущества по сравнению с 
>>> приведенным выше способом.
>>
>>   Патчи, к которым я приложил руку после перехода на git, в виде файлов
>> я не храню (только унаследываемые). Для из поучения -- использую diff
>> между тегами, благо gear это позволяет. (Пока непозволял -- использовал
>> самописанный велосипед для автоматизированного создания патчей на базе
>> заданных коммитов.)
>>
>>   Поскольку, для работы с данной схемой всё равно нужны фиктивные мержи
>> и gear-upate-tag, у меня нет усложнения техпроцесса при хранении
>> исходников в отдельном банче. Это, в свою очередь, позволяет
>> небеспокоется о имени каталога, куда апстрим пакует исходники (если они
>> распространяются в тарбл, то версия часто присутствует в имени
>> каталога): достаточно соглашения, что всё находящееся в корне бранча с
>> сорцами -- сорцы, полученные из внешнего источника (возможно --
>> правленные, но в данном контексте это не важно).
> 
> Под каждый свой патч вы выделяете отдельный бранч? Из сказанного вами 
> вроде этого не следует, хотя я с трудом представляю себе обратное. Можно 
> все-таки пример?

  Да, под каждый патч -- отдельный бранч. Иногда -- несколько патчей в
одном бранче (это предусматривет ветвление в будующием).

  Пример --
<http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=summary>.
(Внимание: репозитарий поряко 100 Мб.)

> 
> Вот допустим, мне нужно изменить что либо в Makefile.in, я создаю бранч 
> (git-branch dbmail_2_2_makefile_patch dbmail_2_2), что я получаю? Копию 
> предыдущего без тагов? А идентификаторы коммитов будут такие же?

  В момент созия бранча -- теже. Потом -- теже + новые.

> 
> Теперь мне нужно сделать таг, слить его с бранчем srpms, чтобы сделать 
> положить в пакет исходники нового бранча, исправить .gear-rules и 
> собрать пакет.

  С помощью gear. Можно это делать сразу в hashr (см. ниже).

> 
> Потом установить его в hasher, чтобы в рабочей системе не устраивать 
> свинство с *-devel и промежуточными результатами сборки - опа, а какие 
> тогда преимущества этого подхода, если все сводится к старому способу с 
> .orig?

  С борку в hasher выполняю спомощью gear:

$ gear --hasher -- hsh ...

  В сложных случаях, когда нужен "сырой" и/или промежуточные результаты
сборки .src.rpm, действую через:

$ gear --rpmbuild -- rpmbuild --nodeps -b*

> 
> Значит собирать надо в бранче (ладно, иногда на свинство можно 
> согласиться ;) ), хорошо, собираю, какой командой теперь разницу 
> выгрузить в файл, перейдя в бранч srpms?

  git-diff, если правельно понял вопрос.

-- 

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



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

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Eugene Prokopiev пишет:
> Vladimir V. Kamarzin пишет:
> 
>>>>>>>On 10 Apr 2007 at 13:10 "EP" == Eugene Prokopiev writes:
>>
>>
>> EP> $ git-init-db
>> EP> Initialized empty Git repository in .git/
>>
>>Это не нужно
>>
>> EP> $ git-svnimport -v -o trunk 
>> EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve
>> EP> Branch 'trunk' does not exist.
>> EP> Either use the correct '-o branch' option,
>> EP> or import to a new repository.
>>
>> А уж если сделали git init, то бранч для импорта тоже нужно сделать.
>>
>> EP> Покажите .git/svn2git ;)
>>
>>Нету такого ;)
>>
>> EP> А один бранч вытащить в принципе нельзя?
>>
>>Поробуйте так:
>>
>>git init
>>git-svn init https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch
>>git-svn fetch
> 
> 
> Таким образом я вытяну svn-бранч libsieve_2_2_branch в текущий локальный 
> бранч. Можно ли указать, в какой бранч вытягивать? Если указать -b 
> libsieve_2_2, svn-бранч libsieve_2_2_branch все равно вытягивается в 
> текущий локальный бранч со следующими словами:
> 
> fatal: ambiguous argument 'libsieve_2_2': unknown revision or path not 
> in the working tree.
> 
> Очевидное решение - создать локальный бранч libsieve_2_2:
> 
> $ git-branch libsieve_2_2
> fatal: Not a valid branch point: 'master'.
> 
> Бранча master у меня действительно нет (и он мне не нужен), есть только 
> бранч srpms, созданный gear-srpmsimport. Как быть?

Сделал так:

$ git-branch
   srpms

$ git-svn init 
https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch

$ git-svn fetch
Fetching git-svn
         A       libsieve2/www/example.php
...
         M       libsieve2/Makefile
r110 = 15ef41ffd4d2e52cee5ae30dba1de1ee47b16c84
$ git-branch
* master
   srpms

$ git-checkout srpms
Switched to branch "srpms"

$ ls
libsieve  libsieve.spec

$ git-checkout master
Switched to branch "master"

$ ls
libsieve2

И что все это означает?

Еще интереснее:

$ git-checkout master
Switched to branch "master"

$ head -n 1 libsieve2/NEWS
libSieve 2.2.5

$ git-checkout srpms
Switched to branch "srpms"

$ head -n 1 libsieve/NEWS
libSieve 2.2.4

Т.е. вроде в бранч master попало то, что надо, а что тогда попало в 
бранч srpms?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Vladimir V. Kamarzin]

>>>>> On 11 Apr 2007 at 16:59 "EP" == Eugene Prokopiev writes:

 EP> Сделал так:

 EP> $ git-branch
 EP>    srpms

 EP> $ git-svn init 
 EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch

 EP> $ git-svn fetch
 EP> Fetching git-svn
 EP>          A       libsieve2/www/example.php
 EP> ...
 EP>          M       libsieve2/Makefile
 EP> r110 = 15ef41ffd4d2e52cee5ae30dba1de1ee47b16c84
 EP> $ git-branch
 EP> * master
 EP>    srpms

 EP> $ git-checkout srpms
 EP> Switched to branch "srpms"

 EP> $ ls
 EP> libsieve  libsieve.spec

 EP> $ git-checkout master
 EP> Switched to branch "master"

 EP> $ ls
 EP> libsieve2

 EP> И что все это означает?

Не понял вопроса.

 EP> Еще интереснее:

 EP> $ git-checkout master
 EP> Switched to branch "master"

 EP> $ head -n 1 libsieve2/NEWS
 EP> libSieve 2.2.5

 EP> $ git-checkout srpms
 EP> Switched to branch "srpms"

 EP> $ head -n 1 libsieve/NEWS
 EP> libSieve 2.2.4

 EP> Т.е. вроде в бранч master попало то, что надо, а что тогда попало в 
 EP> бранч srpms?

Ничего не попало. Вы же не делали ни merge ни pull :)

-- 
vvk

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

Vladimir V. Kamarzin пишет:
>>>>>>On 11 Apr 2007 at 16:59 "EP" == Eugene Prokopiev writes:
> 
> 
>  EP> Сделал так:
> 
>  EP> $ git-branch
>  EP>    srpms
> 
>  EP> $ git-svn init 
>  EP> https://libsieve.svn.sourceforge.net/svnroot/libsieve/branches/libsieve_2_2_branch
> 
>  EP> $ git-svn fetch
>  EP> Fetching git-svn
>  EP>          A       libsieve2/www/example.php
>  EP> ...
>  EP>          M       libsieve2/Makefile
>  EP> r110 = 15ef41ffd4d2e52cee5ae30dba1de1ee47b16c84
>  EP> $ git-branch
>  EP> * master
>  EP>    srpms
> 
>  EP> $ git-checkout srpms
>  EP> Switched to branch "srpms"
> 
>  EP> $ ls
>  EP> libsieve  libsieve.spec
> 
>  EP> $ git-checkout master
>  EP> Switched to branch "master"
> 
>  EP> $ ls
>  EP> libsieve2
> 
>  EP> И что все это означает?
> 
> Не понял вопроса.
> 
>  EP> Еще интереснее:
> 
>  EP> $ git-checkout master
>  EP> Switched to branch "master"
> 
>  EP> $ head -n 1 libsieve2/NEWS
>  EP> libSieve 2.2.5
> 
>  EP> $ git-checkout srpms
>  EP> Switched to branch "srpms"
> 
>  EP> $ head -n 1 libsieve/NEWS
>  EP> libSieve 2.2.4
> 
>  EP> Т.е. вроде в бранч master попало то, что надо, а что тогда попало в 
>  EP> бранч srpms?
> 
> Ничего не попало. Вы же не делали ни merge ни pull :)

Зато я делал fetch :)

Проблема вот в чем: до fetch у меня был только один бранч - srpms. После 
fetch появился новый бранч master (это нормально), в нем появились новые 
файлы, соответствующие последнему тарболлу апстрима (это тоже хорошо), а 
в бранче srpms тоже появились файлы, предположительно соответствующие 
предыдущему тарболлу апстрима (и вот это мне уже непонятно). Такие 
выводы сделаны на основании записей в libsieve2/NEWS в бранче master и 
libsieve/NEWS в бранче srpms. Почему это произошло?

-- 
С уважением, Прокопьев Евгений

Re: [devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Eugene Prokopiev]

похоже, я сделал git-rm в бранче srpms, а потом переключился (меня 
переключили ;) ) в бранч master, не сделав commit в бранче srpms

-- 
С уважением, Прокопьев Евгений