Обсуждение:Git-svn

Честно говоря, в лоб это не работает, нужна творческая переработка. Опишу на своём примере. Был репозиторий pymol вполне обычным: в бранче upstream исходники апстрима, в бранче master - всё остальное. При помощи git-svn решил сделать более правильно (т.е. чтобы не заморачиваться каждый раз вытягиванием нового снапшота, укладыванием его в бранч upstream и т.д.):

git checkout upstream
rm pymol -fR
git svn init -s https://pymol.svn.sourceforge.net/svnroot/pymol
git svn fetch

Без второй строки (удаление старых исходников) операция fetch вываливается из-за конфликтов. Перенос исходников из подкаталога pymol в корень бранча делать не стал, ибо смысла не увидел, git-svn сам именно в этот подкаталог исходники и положил.

git checkout master

А вот это не сработало: git pull . tags/ВЕРСИЯ_ПАКЕТА

потому что в .git/config указано:

[svn-remote "svn"]
  url = https://pymol.svn.sourceforge.net/svnroot/pymol
  fetch = trunk:refs/remotes/trunk
  branches = branches/*:refs/remotes/*
  tags = tags/*:refs/remotes/tags/*

Вместо этого я сделал:

git pull . refs/remotes/trunk

Для ВЕРСИЯ_ПАКЕТА, соответственно, будет

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

для того, чтобы получить исходники наиболее свежие. В .gear/rules прописал:

tar.bz2: refs/remotes/trunk:@name@

После этого сборка в gear прошла успешно.

viy@: это плохо. тем что человек не может повторить сборку
например вчера сборка проходила успешно, а сегодня в транк закоммитили
1.1 alpha, которая в упор не собирается. а в спеке обман -- написано 1.0.
Нужно либо явно задавать тэг (refs/remotes/tags/ВЕРСИЯ_ПАКЕТА),
либо делать сборку из git (убрать refs/remotes/trunk:)

Либо просто создавать в другом бранче (или в самом master) новый тэг и от него уже плясать.

Возникли трудности с заливкой локального репозитория на git.alt. Стандартная часть прошла без вопросов:

git push --all git.alt:packages/pymol.git -f
git push --tags git.alt:packages/pymol.git -f

Опция -f понадобилась из-за тех же конфликтов, о которых выше. Дальше пробовал (как описано здесь) поместить в refs/svn, ибо мне такой вариант показался более подходящим по смыслу:

git push origin refs/remotes/trunk:refs/svn/trunk
git push origin 'refs/remotes/tags/*:refs/svn/tags/*'
git push origin 'refs/remotes/branches/*:refs/svn/branches/*'

Этот вариант тоже нерабочий, поэтому сделал, как сказано там же, но чуть выше:

git push origin refs/remotes/trunk:refs/remotes/trunk
git push origin 'refs/remotes/tags/*:refs/remotes/tags/*'
git push origin 'refs/remotes/branches/*:refs/remotes/branches/*'

Но осталось одно очень досадное недоразумение: вся история из svn попала в shortlog бранча master, вытеснив далеко вниз то, что желательно как раз на виду оставить. Пока не выяснил, поможет ли проблеме выполнение команды git checkout master не в тот момент, где я делал, а уже после git pull . refs/remotes/trunk (там ещё после checkout придётся сделать gear-merge, видимо).

UPD: да, так и есть: после git svn fetch делаем (в бранче upstream)

git-pull . refs/remotes/ЧТО_ТАМ_У_НАС

а потом уже

git tag -s -m "комментарий" ИМЯ_ТЭГА
git checkout master
gear-merge -r .gear/merge
gear-update-tag -a

Соответственно, в .gear/rules:

tar.bz2: @version@:@name@

real 05:04, 23 марта 2009 (UTC)

Свежий пример: попробовал ради эксперимента использовать git-svn для вытягивания mplayer:

git svn init -s svn://svn.mplayerhq.hu/mplayer/trunk
git svn fetch

Первая команда добавила в .git/config:

[svn-remote "svn"]
  url = svn://svn.mplayerhq.hu/mplayer
  fetch = trunk/trunk:refs/remotes/trunk
  branches = trunk/branches/*:refs/remotes/*
  tags = trunk/tags/*:refs/remotes/tags/*

Но вторая команда ничего из svn не вытягивает, и даже не ругается.

:real 09:07, 1 апреля 2009 (UTC)