[devel] Бранч для svn-репозитария в git

[Eugene Prokopiev]

31.08.08, Alexey I. Froloff<raorn на altlinux.ru> написал(а):
> * Eugene Prokopiev <enp@> [080831 18:29]:
>
> > достаточно просто перейти на сборку из svn + иметь возможность
>  > собирать нескольким майнтейнерам
>
> Тогда так:
>
>  $ ssh -n git.alt git-clone git.alt:/archive/p/package-name.git
>  $ git clone git.alt:packages/package-name.git
>  $ git branch -d srpms
>  $ git push origin :srpms

Удалить бранч srpms в локальном репозитарии и в своем на git.alt?

Так его нет:

$ git-branch -a
* master
  origin/HEAD
  origin/master
  origin/srpms

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

>  $ git pull . tags/ВЕРСИЯ_ПАКЕТА
...
>  Далее в .gear/rules будет примерно так:
>
>  tar: remotes/tags/@version@:.
>  diff: remotes/tags/@version@:. .
...
>  $ git pull . tags/НОВАЯ_ВЕРСИЯ или trunk или branches/БРАНЧ

Зачем делать pull в текущий бранч (предполагается, что спек там же?),
если tar нам сделают из ремотного бранча по тегу, а не из каталога в
текущем бранче?

И в чем принципиальная разница с моим рецептом? У меня тоже tar
делался из ремотного бранча, но после push на git.alt и clone оттуда
этот ремотный бранч уже не был виден - т.о. разработчик, сделавший
clone, не мог просто сделать git-svn fetch для обновления апстримных
исходников, а должен был сделать перед тем git-svn init. В вашем
случае это тоже так?

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

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