Git-svn: различия между версиями

Версия от 09:54, 23 марта 2009

Создаём новый git-репозиторий

Если пакета ещё нет в репозитории, или он попадал в репозиторий только через incoming, и нет смысла сохранять его историю.

Создаём репозиторий:

$ mkdir repo
$ cd repo
$ git init

Инициализируем git-svn:

$ git svn init -s svn://radlinux.org/radlinux/

Втягиваем svn-репозиторий (в remotes/trunk, remotes/tags/* и remotes/branches/*, для нестандартных раскладок репозитория см. git-svn(1)):

$ git svn fetch

Бранч master теперь указывает на trunk. При наличии необходимости переставляем его на какой-то релиз:

$ git reset --hard tags/ВЕРСИЯ

Конвертируем существующий git-репозиторий^[1]

Если пакет уже есть — берём за основу его репозиторий:

$ ssh -n git.alt git-clone git.alt:/archive/p/package-name.git
$ git clone git.alt:packages/package-name.git

Удаляем бранч srpms, он больше не нужен — src.rpm пакеты всасывать больше никто не будет:

$ git branch -d srpms
$ git push origin :srpms

Инициализируем git-svn:

$ git svn init -s svn://radlinux.org/radlinux/

Втягиваем svn-репозиторий (в remotes/trunk, remotes/tags/* и remotes/branches/*, для нестандартных раскладок репозитория см. git-svn(1)):

$ git svn fetch

После импорта из src.rpm исходники находились в поддиректории. Передвигаем их на уровень выше, чтобы расклад совпадал с бранчем, в который импортированы исходники из svn:

$ git mv имякаталога/* .
$ git mv имякаталога/.* . # (if any)
$ git commit -m 'git mv имякаталога/* .'

«Пристёгиваем» нужную версию из svn к истории пакета. Как правило мёрж происходит чисто, но могут быть проблемы, если последний импортированный src.rpm содержит тарболл, не соответствующий чекауту из svn. В принципе можно сделать merge с -s ours, но это скроет возможные ошибки.

$ git pull . tags/ВЕРСИЯ_ПАКЕТА

`.gear/rules`

Содержимое .gear/rules будет примерно таковым:

tar: remotes/tags/@version@:. # тарбол будет генерироваться из upstream-тэга
diff: remotes/tags/@version@:. . # будет создан один patch между master и upstream-тэгом

Накладывание патчей

Прикладываем патчи как обычно: в master, или в разные бранчи — как удобно.

Новые upstream-версии

Вытаскиваем новые изменения из svn-репозитория:

$ git svn fetch

Обновляем master до новой версии:

$ git pull . tags/НОВАЯ_ВЕРСИЯ # или trunk или branches/БРАНЧ

Ссылки

↑ raorn@ об использовании git-svn

[1] raorn@ об использовании git-svn

[1]

@@ Строка 1: / Строка 1: @@
-raorn@ [http://lists.altlinux.org/pipermail/devel/2008-August/159404.html об использовании git-svn]:
+== Создаём новый git-репозиторий ==
+Если пакета ещё нет в репозитории, или он попадал в репозиторий только через incoming, и нет смысла сохранять его историю.
+Создаём репозиторий:
+ $ mkdir repo
+ $ cd repo
+ $ git init
+Инициализируем git-svn:
+ $ git svn init -s svn://radlinux.org/radlinux/
+Втягиваем svn-репозиторий (в <tt>remotes/trunk</tt>, <tt>remotes/tags/*</tt> и <tt>remotes/branches/*</tt>, для нестандартных раскладок репозитория см. <tt>git-svn(1)</tt>):
+ $ git svn fetch
+Бранч master теперь указывает на trunk. При наличии необходимости переставляем его на какой-то релиз:
+ $ git reset --hard tags/ВЕРСИЯ
+== Конвертируем существующий git-репозиторий<ref>raorn@ [http://lists.altlinux.org/pipermail/devel/2008-August/159404.html об использовании git-svn]</ref> ==
+Если пакет уже есть — берём за основу его репозиторий:
   $ ssh -n git.alt git-clone git.alt:/archive/p/package-name.git
   $ git clone git.alt:packages/package-name.git
+Удаляем бранч <tt>srpms</tt>, он больше не нужен — src.rpm пакеты всасывать больше никто не будет:
   $ git branch -d srpms
   $ git push origin :srpms
+Инициализируем git-svn:
   $ git svn init -s svn://radlinux.org/radlinux/
+Втягиваем svn-репозиторий (в <tt>remotes/trunk</tt>, <tt>remotes/tags/*</tt> и <tt>remotes/branches/*</tt>, для нестандартных раскладок репозитория см. <tt>git-svn(1)</tt>):
   $ git svn fetch
+После импорта из src.rpm исходники находились в поддиректории. Передвигаем их на уровень выше, чтобы расклад совпадал с бранчем, в который импортированы исходники из svn:
-Теперь весь репозитарий втянут в remotes/trunk, remotes/tags/* и
-remotes/branches/*, это делает опция -s для svn init.
   $ git mv имякаталога/* .
   $ git mv имякаталога/.* . # (if any)
   $ git commit -m 'git mv имякаталога/* .'
+«Пристёгиваем» нужную версию из svn к истории пакета. Как правило мёрж происходит чисто, но могут быть проблемы, если последний импортированный src.rpm содержит тарболл, не соответствующий чекауту из svn. В принципе можно сделать merge с <tt>-s ours</tt>, но это скроет возможные ошибки.
   $ git pull . tags/ВЕРСИЯ_ПАКЕТА
-Тут мы "пристёгиваем" нужную версию из svn к истории пакета.  Как
+== <tt>.gear/rules</tt> ==
-правило мёрж происходит чисто, но могут быть проблемы если тарбол
-не соответствует чекауту из svn.  -s ours делать не рекомендую,
+Содержимое <tt>.gear/rules</tt> будет примерно таковым:
-лучше таки проконтролировать процесс.
+  tar: remotes/tags/@version@:. # тарбол будет генерироваться из upstream-тэга
+ diff: remotes/tags/@version@:. . # будет создан один patch между master и upstream-тэгом
+== Накладывание патчей ==
-Далее в .gear/rules будет примерно так:
+Прикладываем патчи как обычно: в master, или в разные бранчи — как удобно.
-  tar: remotes/tags/@version@:.
+== Новые upstream-версии ==
-  diff: remotes/tags/@version@:. .
+Вытаскиваем новые изменения из svn-репозитория:
+  $ git svn fetch
+Обновляем master до новой версии:
+  $ git pull . tags/НОВАЯ_ВЕРСИЯ # или trunk или branches/БРАНЧ
-Потом прикладываем все патчи (в master, или в разные бранчи - как
+== Ссылки ==
-удобно) и двигаемся к новому снапшоту:
- $ git pull . tags/НОВАЯ_ВЕРСИЯ или trunk или branches/БРАНЧ
+<references/>
 [[Категория:git]]