Управление проектами - разветвление от SVN main до Git в виде вилки с возможностью перебазирования svn по мере необходимости

Я хочу разделить проект, который в настоящее время управляется через SVN, на Git. Репозиторий SVN - svn.openvpms.org/openvpms. В нем около 8 подпроектов, каждый из которых имеет каталоги trunk / branch / tag. Когда я работаю в своей среде IDE, я фактически проверяю каждую из них через svn отдельно, но в определенной структуре каталогов, например, если так SVN показывает проекты Openvpms

  • svn.openvpms.org
    • openvpms
      • Project 1 (eg openvpms) (this would be the parent project)
        • branch
        • сундук
        • ярлык
      • Project 2 (eg openvpms-archetype) (the parent would depend on this)
        • branch
        • сундук
        • ярлык

когда я проверю их на месте, я проверю ствол, чтобы

  • MainDir
    • Project 1 (project 1 trunk)
      • src
    • Project 2 (project 2 trunk)
      • src

Что я хотел бы сделать, так это разветвить всю настройку на git, используя git-svn, но сохранить ветки и теги из SVn для каждого проекта.

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

Есть ли другой способ клонировать все репозиторий svn в одно репо git и поддерживать ствол / ветку / теги каждого подпроекта?

Я осознаю тот факт, что сейчас существует сайт SE по управлению проектами, но этот вопрос действительно относится к использованию git-svn для клонирования нескольких проектов, каждый из которых имеет структуру тегов / веток / магистрали.

Когда я выдаю

 git svn clone "svn://svn.openvpms.org/openvpms/openvpms" \
 "C:\Users\mydirectory\OPENVPMS-Git LOCAL REPO\openvpms" \
 -T trunk -b branches -t tags

то, что на самом деле происходит сразу, это

Инициализирован пустой репозиторий Git в c:/Users/mydirectory/GIT_LOCAL_REPO/openvpms/.git/
Использование более высокого уровня URL: svn://svn.openvpms.org/openvpms/openvpms => svn://svn.openvpms.org/openvpms

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

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


git project version-control svn smartgit
person Narrim    schedule 08.04.2014    source источник
comment
Хорошо, похоже, что использование git-svn для каждого проекта svn будет работать, создав 8 или около того репозиториев git.   -  person Narrim    schedule 08.04.2014

Ответы (2)


arrow_upward
2
arrow_downward

Вы должны прочитать git- svn Man Page полностью и внимательно

кажется, что git-svn все равно идет обратно к родительскому элементу

Просто откройте для себя и попробуйте --no-minimize-url вариант для git init

Я мог бы создать репозиторий Git для каждого проекта и клонировать каждый, что могло бы быть моим единственным вариантом

кажется Git может отслеживать множество SVN-репозиториев в одном репозитории Git (я не опытный Git-boy, просто попробовал RTFM немного глубоко), но для этого потребуется ручная работа (и, что удивительно, чистый CLI) .

  • В разделе «Конфигурация» справочной страницы git-svn Я видел [svn-remote "project-a"] образец с шаблонами глобусов в определениях веток | тегов (после клонирования первого svn-remote вы можете (?) добавить остальные пульты моей рукой)

  • «Практические советы по использованию Git с большими репозиториями Subversion « в разделе« Получение других веток Subversion »предлагает использовать более одного определения выборки внутри одного svn-remote с разными RELPATH (таким образом, вы можете попробовать получить 1 svn-remote с множеством fetch внутри для trunk / branch / tags реальные SVN-проекты внутри SVN-репо)

person Lazy Badger    schedule 01.07.2014

arrow_upward
0
arrow_downward

Хорошо, я думаю, что наконец-то отсортировал это, в конце концов, дело дошло до использования git svn Сначала я добавил каждый проект svn как удаленный в git, отредактировав файл .git / config. Я дал им разные удаленные имя и псевдонимы.

/...
[svn-remote "parent"]
     url = svn://example.com/rootproject
    fetch = rootproject/trunk:refs/remotes/origin/trunk
    branches = rootproject/branches/*:refs/remotes/origin/*
    tags = rootproject/tags/*:refs/remotes/origin/tags/*
[svn-remote "subproject1"]
    url = svn://localhost/rootproject
    fetch = subproject1/trunk:refs/remotes/subproject1/trunk
    branches = subproject1/branches/*:refs/remotes/subproject1/*
    tags = subproject1/tags/*:refs/remotes/subproject1/tags/*
[svn-remote "subproject2"]
    url = svn://localhost/rootproject
    fetch = subproject2/trunk:refs/remotes/subproject2/trunk
    branches = subproject2/branches/*:refs/remotes/subproject2/*
    tags = subproject2/tags/*:refs/remotes/subproject2/tags/*
[svn-remote "subproject3"]
    url = svn://localhost/openvpms
    fetch = subproject3/trunk:refs/remotes/subproject3/trunk
    branches = subproject3/branches/*:refs/remotes/subproject3/*
    tags = subproject3/tags/*:refs/remotes/subproject3/tags/*
    ..../

так далее

потом я побежал

git svn fetch --all

Это проверило каждый проект в корень репозитория git. Теперь, чтобы реструктурировать, я проверил

git checkout origin/trunk

затем запускался для каждого подпроекта

git merge -s ours --no-commit subproject1/master <2>
git read-tree --prefix=subproject1/ -u subproject1/master <3>
git commit -m "Merge subproject1 as our subdirectory" <4>

Теперь у меня был проект, который выглядел как

ParentProject
|-src
|-parentpom.xml
|-subproject1
|    |-src
|    |-pom.xml
|-subproject2
|    |-src
|    |-pom.xml
|-subproject3
|    |-src
|    |-pom.xml

так далее

Теперь я думаю, что все еще могу бежать

git fetch --all

затем беги

git pull -s subtree subproject1 trunk

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

person Narrim    schedule 19.04.2015