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

Материал из ALT Linux Wiki
(Изложение сути проблемы)
 
(Непонятно, как настраивать git-svn при проблемах)
 
(не показаны 3 промежуточные версии этого же участника)
Строка 10: Строка 10:
  git checkout master
  git checkout master


А вот это не сработало: git pull . tags/ВЕРСИЯ_ПАКЕТА, вместо этого я сделал:
А вот это не сработало: 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/trunk
Для ВЕРСИЯ_ПАКЕТА, соответственно, будет
git pull . refs/remotes/tags/ВЕРСИЯ_ПАКЕТА


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


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


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


Но осталось одно очень досадное недоразумение: вся история из svn попала в shortlog бранча master, вытеснив далеко вниз то, что желательно как раз на виду оставить. Пока не выяснил, поможет ли проблеме выполнение команды git checkout master не в тот момент, где я делал, а уже после git pull . refs/remotes/trunk (там ещё после checkout придётся сделать gear-merge, видимо).
Но осталось одно очень досадное недоразумение: вся история из 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|real]] 05:04, 23 марта 2009 (UTC)
:[[Участник:Real|real]] 05:04, 23 марта 2009 (UTC)
[http://lists.altlinux.org/pipermail/sisyphus/2009-March/338203.html Свежий пример]: попробовал ради эксперимента использовать 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|real]] 09:07, 1 апреля 2009 (UTC)

Текущая версия от 12:07, 1 апреля 2009

Честно говоря, в лоб это не работает, нужна творческая переработка. Опишу на своём примере. Был репозиторий 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)