Google Code Subversion 저장소를 GitHub에 포크 및 동기화

Google Code Subversion 저장소를 GitHub에 포크 및 동기화

---

GitHub 리포지토리에 대한 쓰기 액세스 권한이없는 Google Code Subversion 리포지토리와 포크 및 동기화를 유지하려면 어떻게해야합니까?

Git 리포지토리에서 자체 기능을 개발하고 싶지만 Google Code Subversion 리포지토리와 동기화하고 싶습니다. Google 코드 프로젝트 측에서 수정 사항을 가져옵니다.

git-svn에 대해 알고 있으며 내가 완전히 제어 할 수있는 Subversion 저장소로 업스트림 및 다운 스트림하기 전에 사용했습니다. 그러나 Google Code Subversion 저장소와 동기화하는 방법을 모르겠습니다.

---

git-svn의 원격 브랜치는 일반 Git 원격과 거의 같습니다. 따라서 로컬 리포지토리에서 git-svn 복제본을 만들고 변경 사항을 GitHub에 푸시 할 수 있습니다. Git은 상관하지 않습니다. git-svn 클론을 생성하고 똑같은 변경 사항을 GitHub에 푸시하면 비공식 Google 코드 저장소 미러가 생깁니다. 나머지는 바닐라 힘입니다.

git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com: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로 푸시 됩니다. 그리고 첫 번째 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 코드 분기보다 몇 가지 커밋이 있습니다. 맞습니까? 그렇다면 Google 코드에서 새로운 것을 통합하고 싶을 때 어떤 일이 발생합니까? git svn rebase먼저 실행 하고 이것을 얻으십시오 :

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

If you git push master out, you can imagine the [remotes/origin/master] being at the same point as master. But your feature branch doesn't have the changes. Your choices now are to merge master into features, or rebase features. A merge would look like this

git checkout features
git merge master 

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

Then you push features out to GitHub. I've left off the remotes for master to save space, they'd be at the same point as [master].

The rebase approach is slightly more evil - you'd have to push with --force as your push would not be a fast-forward merge (you'd pull the features branch from under someone who had cloned it). It's not really considered OK to do this, but nobody can stop you if you are determined. It does make some things easier too, such as when patches get accepted upstream in slightly reworked form. It'd save having to mess about with conflicts, you can just rebase --skip the upstreamed patches. Anyway, a rebase would be like this:

git rebase master features

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

And then you would have to git push --force that. You can see why you need to force it, the history has a big old schism from the [remotes/origin/features] to the new current post-rebase [features].

This all works, but it is a lot of effort. If you are going to be a regular contributor, the best bet would be to work like this for a while, send some patches upstream and see if you can get commit access to Subversion. Failing that, perhaps don't push your changes out to GitHub. Keep them local and try and get them accepted upstream anyway.

---

svn2github service

The website http://svn2github.com/ provides a service to fork any publicly-accessible SVN repository onto Github (at https://github.com/svn2github/projectname). I tried it; upon pressing "Make a mirror" it apparently did nothing for a few seconds and displayed the message "error", but it actually worked. The new repository was in fact created, containing the code from the SVN repo.

You would then fork the repository it creates, and work on your own fork. You would then submit your changes to the upstream project using their bugtracker.

Looking at existing repositories under the service's Github user (e.g. "svn2github pushed to master at svn2github/haxe 5 hours ago"), it does seem to regularly pull in changes from the SVN repository. There's no information on who runs the service on the website, so I wouldn't bet on it continuing to run indefinitely, but it works for now (and if it ever goes down, you can still manually update your fork).

Launchpad

If you're not set on using Git and Github, another alternative is to use Launchpad.net. Launchpad can automatically import SVN (also CVS) repositories into a personal bzr branch. To do this, create a Launchpad project, then go to the new import page, select Subversion and enter the URL (e.g. http://projectname.googlecode.com/svn/trunk/). Depending on the project size, the initial import can take up to a few hours. Subsequent imports will run periodically.

For more documentation, see VCS Imports on Launchpad Help.

---

A walk-through for synchronizing from Google Code to GitHub is available at fnokd.com. The author uses an always-on remote server and a cron job to automate the synchronization and keeps the SVN trunk in a GitHub branch called "vendor".

---

GitHub now supports directly importing subversion projects (see http://help.github.com/import-from-subversion/). Just create a new repo and then click "Import from Subversion" at the "Next Steps" screen. It doesn't support further syncing, though :/.

---

Hmm.. In my company I was doing nearly the same. Just having both .svn and .git repo in the same directory (you checkout svn repo and create git repo in this working copy).

Then using svn up and git push did the thing. Of course if you diverge a lot you'll have to merge things by hand.

---

I’m not quite sure what it is that you want but, of course can you pull from a subversion repository and push to a Git repository from the same working copy. And you can also git svn dcommit back to the subversion repository. You can’t make the GitHub repository sync against the subversion repository, though. Also, when you have commits in your working copy that are not yet in the subversion repository you will need to rebase them if the subversion repository was updated, forcing you to git push --force the “new” commits to GitHub.

---

I found these instructions on Yu-Jie Lin's blog:

First clone the Subversion repository and push to the Git:

git svn clone https://foo.googlecode.com/svn/ git-foo 
cd git-foo
git remote add git-foo git@github.com:username/foo.git 
git push git-foo master

After committing in the Subversion repository, run

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

참고URL : https://stackoverflow.com/questions/796991/fork-and-synchronize-google-code-subversion-repository-into-github