Ответ 1

Удаленная ветвь от git -svn в значительной степени похожа на обычный пульт Git. Таким образом, в вашем локальном репозитории вы можете использовать свой git -svn-клон и вносить изменения в GitHub. Git не волнует. Если вы создадите свой git -svn клон и нажмете те же самые изменения в GitHub, у вас будет неофициальное зеркало репозитория Google Code. Остальное - ваниль Git.

git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master

Теперь, когда у вас это есть, иногда вам придется синхронизировать репозиторий Subversion с Git. Это будет выглядеть примерно так:

git svn rebase
git push

В gitk или что-то еще, это выглядит примерно так:

o [master][remotes/trunk][remotes/origin/master]
|
o
|
o

И когда вы запустите git svn rebase, вы получите следующее:

o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o

Итак, теперь работающий git push будет толкать эти коммиты в GitHub, там есть [remotes/origin/master]. И вы вернетесь к сценарию на первой диаграмме ASCII.

Теперь проблема в том, как вы работаете с изменениями в миксе? Идея заключается в том, что вы никогда не привязываетесь к той же ветке, что вы git -svn-rebase-ing и git -pushing. Для ваших изменений требуется отдельная ветка. В противном случае вы в конечном итоге замените свои изменения поверх Subversion, что может расстроить любого, кто клонирует ваш репозиторий Git. Подписывайтесь на меня? Хорошо, так что вы создаете ветку, позвольте называть ее "функциями". И вы делаете фиксацию и выталкиваете ее в GitHub в ветки функций. Ваш gitk будет выглядеть примерно так:

o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o

Здесь у вас есть свои функции, которые разделяют пару моментов перед подразделением Google Code, не так ли? Итак, что происходит, когда вы хотите включить новые вещи из Google Code? Сначала вы запустите git svn rebase и получите следующее:

                           o [features][remotes/origin/features]
[master][remotes/trunk] o  |
                        |  o
                        o /
                        |/
                        o[remotes/origin/master]
                        |
                        o

Если вы git push мастер, вы можете представить, что [remotes/origin/master] находится в той же точке, что и master. Но у вашей ветки функций нет изменений. Теперь ваш выбор состоит в том, чтобы объединить мастер в функции или функции переадресации. Слияние будет выглядеть следующим образом:

git checkout features
git merge master 

            o [features]
           /|
          / o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

Затем вы вытаскиваете функции в GitHub. Я оставил пульт дистанционного управления для мастера, чтобы сэкономить место, они будут в той же точке, что и [мастер].

Подход, основанный на перестановке, немного более злобный - вам придется нажать с помощью --force, поскольку ваш толчок не будет быстрым слиянием (вы вытащите ветвь функций из-под кого-то, кто ее клонировал). На самом деле это не так хорошо, но никто не может остановить вас, если вы решите. Это также делает некоторые вещи более легкими, например, когда патчи принимаются в потоке в слегка переработанной форме. Это избавит вас от необходимости возиться с конфликтами, вы можете просто переустановить -skip восходящие патчи. Во всяком случае, rebase будет выглядеть следующим образом:

git rebase master features

         o [features]
         |
         o
         |  o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

И тогда вам понадобится git push --force. Вы можете понять, зачем вам это нужно, история имеет большой старый раскол из [remotes/origin/features] в новую текущую пост-rebase [features].

Это все работает, но это много усилий. Если вы станете постоянным участником, лучшим вариантом будет некоторое время работать так, чтобы отправить некоторые исправления вверх и посмотреть, можете ли вы получить доступ к транзакции для Subversion. В противном случае, возможно, не подталкивайте свои изменения к GitHub. Держите их локально и старайтесь их принять вверх по течению в любом случае.

Ответ 2

служба svn2github

Веб-сайт http://svn2github.com/ предоставляет услугу для вилки любого общедоступного репозитория SVN на Github (в https://github.com/svn2github/projectname). Я попробовал; после нажатия "Сделать зеркало" он, по-видимому, ничего не сделал в течение нескольких секунд и отобразил сообщение "ошибка", но он действительно сработал. Создан новый репозиторий, содержащий код из репо SVN.

Затем вы откроете репозиторий, который он создает, и поработайте над своей собственной вилкой. Затем вы отправляете свои изменения в восходящий проект, используя свой bugtracker.

Глядя на существующие репозитории под сервисом пользователя Github (например, "svn2github нажата на master svn2github/haxe 5 часов назад" ), он, похоже, регулярно втягивает изменения из репозитория SVN. Там нет информации о том, кто управляет службой на веб-сайте, поэтому я бы не стал делать ставку на то, что она будет работать бесконечно, но теперь она работает (и если она когда-либо снижается, вы все равно можете вручную обновить свою вилку).

Launchpad

Если вы не настроены на использование Git и Github, другой альтернативой является использование Launchpad.net. Launchpad может автоматически импортировать SVN (также CVS) репозитории в личную ветвь bzr. Для этого создайте проект Launchpad, затем перейдите в новую страницу импорта, выберите Subversion и введите URL-адрес (например, http://projectname.googlecode.com/svn/trunk/). В зависимости от размера проекта первоначальный импорт может занять до нескольких часов. Последующий импорт будет выполняться периодически.

Для получения дополнительной документации см. VCS Imports в справке Launchpad.

Ответ 3

Проход для синхронизации от Google Code до GitHub доступен по адресу fnokd.com. Автор использует постоянный удаленный сервер и задание cron для автоматизации синхронизации и поддерживает соединительную линию SVN в ветке GitHub, называемой "поставщиком".

Ответ 4

Теперь GitHub поддерживает прямой импорт проектов подрывной деятельности (см. http://help.github.com/import-from-subversion/). Просто создайте новое репо и нажмите "Импортировать из Subversion" на экране "Следующие шаги". Однако он не поддерживает дополнительную синхронизацию:/.

Ответ 5

Хм.. В моей компании я делал почти то же самое. Просто наличие обоих .svn и .git repo в том же каталоге (вы проверяете svn repo и создаете git repo в этой рабочей копии).

Затем использование svn up и git push сделало это. Конечно, если вы расходитесь много, вам придется объединить вещи вручную.

Ответ 6

Я не совсем уверен, что именно вы хотите, но, конечно, вы можете вытащить из репозитория subversion и нажать на репозиторий Git из той же рабочей копии. И вы также можете git svn dcommit вернуться в репозиторий subversion. Однако вы не можете синхронизировать репозиторий GitHub с репозиторием subversion. Кроме того, когда вы выполняете свою рабочую копию, еще не находящуюся в репозитории subversion, вам нужно будет переустановить их, если репозиторий subversion был обновлен, заставив вас git push --force "новый" совершить GitHub.

Ответ 7

Я нашел эти инструкции на Yu-Jie Lin:

Сначала клонируйте репозиторий Subversion и нажмите на Git:

git svn clone https://foo.googlecode.com/svn/ git-foo 
cd git-foo
git remote add git-foo [email protected]:username/foo.git 
git push git-foo master

После фиксации в репозитории Subversion запустите

cd /path/to/git-foo
git svn fetch 
git svn rebase 
git push git-foo master