Jak mogę rozwidlić i zachować synchronizację z repozytorium Google Code Subversion, do którego nie mam uprawnień do zapisu, w repozytorium GitHub?

Chcę mieć możliwość tworzenia własnych funkcji w moim repozytorium Git, ale chcę również synchronizować się z repozytorium Google Code Subversion. Aby pobrać poprawki po stronie projektu Google Code.

Wiem o git-svn i używałem go wcześniej do przesyłania i odbierania danych do repozytorium Subversion, nad którym miałem pełną kontrolę. Ale nie wiem, jak zachować synchronizację z repozytorium Google Code Subversion.

Zdalna gałąź z git-svn jest prawie taka sama jak zwykły pilot Git. Więc w swoim lokalnym repozytorium możesz mieć swój klon git-svn i wypychać zmiany do GitHub. Gita to nie obchodzi. Jeśli utworzysz swój klon git-svn i wyślesz dokładnie te same zmiany do GitHub, będziesz mieć nieoficjalną kopię lustrzaną repozytorium Google Code. Reszta to waniliowy Git.

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

Teraz, gdy już to masz, od czasu do czasu będziesz musiał zsynchronizować repozytorium Subversion z Git. Będzie wyglądać mniej więcej tak:

git svn rebase
git push

W gitk czy czymkolwiek, wyglądałoby to mniej więcej tak:

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

A kiedy biegniesz git svn rebase, miałbyś to:

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

Więc teraz uruchomienie git pushspowoduje wypchnięcie tych zatwierdzeń do GitHub, gałęzi [remotes / origin / master] tam. Wrócisz do scenariusza z pierwszego diagramu graficznego ASCII.

Problem w tym, jak wprowadzasz zmiany w miksie? Chodzi o to, że nigdy nie angażujesz się w tej samej gałęzi, w której korzystasz z git-svn-rebase-ing i git-pushing. Potrzebujesz osobnej gałęzi do wprowadzania zmian. W przeciwnym razie skończyłbyś na ponownym bazowaniu swoich zmian na tych z Subversion, co mogłoby zdenerwować każdego, kto sklonuje twoje repozytorium Git. Chodź za mną? OK, więc tworzysz gałąź, nazwijmy to „funkcjami”. Dokonujesz zatwierdzenia i wypychasz go do GitHub do gałęzi Features. Twój gitk wyglądałby mniej więcej tak:

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

Tutaj masz gałąź funkcji kilka zatwierdzeń przed gałęzią Google Code, prawda? Więc co się dzieje, gdy chcesz włączyć nowe elementy z Google Code? Biegniesz git svn rebasepierwszy i dostaniesz to:

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

Jeśli git pushopanujesz, możesz sobie wyobrazić, że [piloty / źródło / mistrz] znajduje się w tym samym punkcie co mistrz. Ale twoja gałąź funkcji nie ma zmian. Masz teraz do wyboru scalanie elementów głównych z funkcjami lub przebudowywanie funkcji. Scalanie wyglądałoby tak

git checkout features
git merge master 

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

Następnie wysyłasz funkcje do GitHub. Zostawiłem piloty dla mastera, aby zaoszczędzić miejsce, byłyby w tym samym punkcie co [master] .

Podejście rebase jest nieco bardziej złe - musiałbyś naciskać z --force, ponieważ twoje pchnięcie nie byłoby szybkim łączeniem do przodu (wyciągnąłbyś gałąź funkcji spod kogoś, kto ją sklonował). Robienie tego nie jest uważane za w porządku, ale nikt nie może cię powstrzymać, jeśli jesteś zdeterminowany. Ułatwia to również pewne rzeczy, na przykład gdy łatki są akceptowane przez nadawcę w nieco zmienionej formie. Oszczędziłoby to kłopotów z konfliktami, możesz po prostu zmienić bazę - pomiń zainstalowane poprawki. W każdym razie rebase wyglądałby tak:

git rebase master features

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

A potem musiałbyś to zrobić git push --force. Możesz zobaczyć, dlaczego musisz to wymusić, historia ma wielką starą schizmę od [pilotów / pochodzenie / cechy] do nowej, obecnej po rebase [cechy] .

To wszystko działa, ale wymaga dużo wysiłku. Jeśli masz zamiar być stałym współpracownikiem, najlepiej byłoby popracować w ten sposób przez jakiś czas, wysłać kilka poprawek do systemu i sprawdzić, czy możesz uzyskać dostęp do Subversion. W przeciwnym razie być może nie wypychaj zmian do GitHub. Trzymaj je lokalnie i mimo wszystko spróbuj uzyskać ich akceptację w górę rzeki.

Usługa svn2github

Witryna http://svn2github.com/ zapewnia usługę rozwidlenia dowolnego publicznie dostępnego repozytorium SVN na Github (pod adresem https://github.com/svn2github/projectname ). Próbowałem tego; po naciśnięciu „Utwórz kopię lustrzaną” najwyraźniej nic nie robił przez kilka sekund i wyświetlał komunikat „błąd”, ale faktycznie zadziałał. W rzeczywistości zostało utworzone nowe repozytorium zawierające kod z repozytorium SVN.

Następnie możesz rozwidlić repozytorium, które tworzy, i pracować na swoim własnym forku. Następnie przesłałbyś swoje zmiany do zewnętrznego projektu używając ich bugtrackera.

Patrząc na istniejące repozytoria użytkownika usługi Github (np. „Svn2github przeniesiono do mastera na svn2github / haxe 5 godzin temu”), wydaje się, że regularnie pobiera zmiany z repozytorium SVN. Nie ma informacji o tym, kto prowadzi usługę na stronie, więc nie postawiłbym na to, że będzie działać w nieskończoność, ale na razie działa (i jeśli kiedykolwiek się zepsuje, nadal możesz ręcznie zaktualizować widelec).

Wyrzutnia

Jeśli nie chcesz korzystać z Git i Github, inną alternatywą jest użycie Launchpad.net. Launchpad może automatycznie importować repozytoria SVN (także CVS) do osobistego oddziału bzr. Aby to zrobić, utwórz projekt Launchpad, a następnie przejdź do nowej strony importu , wybierz Subversion i wprowadź adres URL (np http://projectname.googlecode.com/svn/trunk/.). W zależności od rozmiaru projektu, początkowy import może zająć do kilku godzin. Kolejne importy będą odbywały się okresowo.

Aby uzyskać więcej dokumentacji, zobacz Importy VCS w pomocy Launchpad .

Przewodnik dotyczący synchronizacji z Google Code do GitHub jest dostępny pod adresem fnokd.com . Autor używa zawsze włączonego zdalnego serwera i zadania cron w celu zautomatyzowania synchronizacji i utrzymuje łącze trunkingowe SVN w gałęzi GitHub o nazwie „sprzedawca”.

GitHub obsługuje teraz bezpośrednie importowanie projektów subversion (patrz http://help.github.com/import-from-subversion/ ). Po prostu utwórz nowe repozytorium, a następnie kliknij „Importuj z Subversion” na ekranie „Następne kroki”. Nie obsługuje jednak dalszej synchronizacji: /.

Hmm ... W moim towarzystwie robiłem prawie to samo. Wystarczy mieć repozytorium .svn i .git w tym samym katalogu (wyewidencjonowujesz repozytorium svn i tworzysz repozytorium git w tej kopii roboczej).

Następnie użycie svn up i git push załatwiło sprawę. Oczywiście, jeśli bardzo się rozejdziesz, będziesz musiał łączyć różne rzeczy ręcznie.

Nie jestem do końca pewien, czego chcesz, ale oczywiście możesz pobrać z repozytorium subversion i wypchnąć do repozytorium Git z tej samej kopii roboczej. Możesz także git svn dcommitwrócić do repozytorium subversion. Nie możesz jednak zsynchronizować repozytorium GitHub z repozytorium subversion. Ponadto, jeśli w kopii roboczej masz zmiany, których jeszcze nie ma w repozytorium subversion, będziesz musiał je ponownie bazować, jeśli repozytorium subversion zostało zaktualizowane, zmuszając cię do git push --force„nowych” zatwierdzeń do GitHub.

Znalazłem te instrukcje na blogu Yu-Jie Lin :

Najpierw sklonuj repozytorium Subversion i wypchnij do Gita:

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

Po zatwierdzeniu w repozytorium Subversion uruchom

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