ein Git Geschichte auf einem SVN-Zweig

Question

Die Situation
Verpflanzung habe ich ein Git-Repo und ein SVN Repo, die beide den gleichen Quellcode halten, aber eine unterschiedliche Geschichte begehen. Das Git Repo hat eine Menge kleiner, gut kommentierter Einreichungen ... während das SVN Repo ein paar riesige Commits mit Kommentaren wie "Lots of stuff" hat. Beide Serien von Commits folgen den gleichen Änderungen, die im Code vorgenommen wurden und sind ungefähr gleichwertig.

Das gewünschte Ergebnis
ich mit Git-SVN wechseln möchte ohne die detaillierte Geschichte aus der aktuellen Git-Repo zu verlieren. Dies sollte durch "Pfropfen" der Geschichte von der Git-Repo auf einen SVN-Zweig des Projekts getan werden (von dem Punkt ausgehend, an dem ich anfing, Git zu benutzen).

Warum würden Sie das tun? (Geschichte)
Vor einer Weile begann ich mit Git zu spielen. Ich begann mit der Einrichtung eines Git Repos in einem Projekt, das ich unter SVN-Kontrolle hatte. Mit einer kleinen Konfiguration hatte ich Git und SVN parallel auf dem gleichen Quellcode arbeiten.

Dies war eine großartige Möglichkeit für mich zu lernen und mit Git zu spielen, während immer noch das Sicherheitsnetz von SVN. Es war im Grunde eine Sandbox mit echten Daten. Ich hatte nicht die Zeit wirklich lernen Git aber ich wollte wirklich damit basteln. Das war eigentlich ein ziemlich guter Weg Git für mich zu lernen.

Zuerst, nachdem ich einige Änderungen vorgenommen hatte, würde ich mich zu SVN und dann zu Git bekennen ... dann mit Git spielen, wissend, dass meine Änderungen sicher in SVN waren. Bald beging ich häufiger Git als SVN ... Nun, SVN Commits sind zu einer lästigen Pflicht gefallen, die ich manchmal tun muss.

Wenn die Differenz zwischen git revert und svn revert Lernen war ich SEHR froh, dass ich zum SVN-Repo-Check-in war. Ich hätte fast ein paar Wochen Arbeit verloren, wenn man davon ausging, dass die beiden gleich arbeiteten.

Ich kenne jetzt den Ruhm von Git-SVN und ich benutze es glücklich auf mehreren anderen Projekten. Als ich anfing, wurde mir klar, dass ich mein Git Repo verlieren und ein neues "richtig" mit git-svn init einrichten musste ... aber nachdem ich eine Weile mit Git gespielt habe, bin ich mir sicher, dass es eine Möglichkeit gibt, das zu hacken Gib Geschichte in SVN.

Answer 1

Das könnte schwer zu tun sein, was Sie wollen. Sie können ein Git Repo in svn über etwas wie dieses importieren: http://code.google.com/p/support/wiki/ImportingFromGit, aber ich denke, dass Sie Konflikte haben werden. Sie könnten einfach Ihren SVN Repo von Grund auf neu erstellen, basierend auf Ihrem Git Repo.

Für die Zukunft wäre es wahrscheinlich Git als SVN-Client zu verwenden, nur war es einfacher haben:

git-svn clone path/to/your/svn/repo 
git-commit -a -m 'my small change' 
vi some files to change.txt 
git-commit -a -m 'another small change' 
git-svn dcommit # sends your little changes as individual svn commits 

Answer 2

Ich denke, das in einem von zwei Wegen möglich sein sollte ... ich sie skizzieren würde jetzt und versuche, sie später auszufüllen, wenn ich sie herausfinden kann. Wenn irgendjemand sehen kann, wie man einen Teil herausfasert oder weiß, warum ein Teil nicht funktioniert ... bitte kommentiere!

1 - Anstelle mit git-Svn
(Die folgenden sind Pseudo Befehle, die sie nicht real sind - sie nicht benutzen)

rm .svn 
(configure git-svn '/myproject/branch/git-remerge') 
git svn sync_versions --svn_revision=123 --hash=ad346f221455 
git svn dcommit 

2 - eine separate GIT-SVN Repo als Proxy
(Die folgenden sind Pseudo-Befehle, die sie nicht wirklich sind - SIE sie nicht benutzen)

mkdir ../svn_proxy 
cd ../svn_proxy 
git svn init 
git checkout hash_of_svn_branch_point 
git pull ../messy_repo 

Answer 3

Sie können zur Kasse gehen Tailor. Ich habe es benutzt, um ein Git Repository in ein SVN zu verwandeln, so dass meine Arbeit in unserem Firmensvn Server gehostet werden kann. Es ist ziemlich flexibel, also kann es tun, was Sie wollen.

Answer 4

Es scheint, dass dies NICHT möglich ist. Obwohl es möglich ist, den aktuellen Git Repo mit dem aktuellen Svn Repo verbunden zu haben, scheint es nicht möglich, den Verlauf des Git Repos in den Svn Repo wiederzugeben.

Das Hauptproblem, das ich hatte, war git-svn, um auf ein einzelnes svn commit "zu verriegeln". Die Antwort auf dieses Problem scheint git-svn set-tree zu sein. Dieser Blog-Eintrag war sehr hilfreich:
http://www.reonsoft.com/~john/blog/2008/06/05/git-first-git-svn-later/

Dies ist so weit, wie ich die Geschichte in SVN zu halten bekommen könnte versuchen:

git branch svn-reconsile HASH_OF_SECOND_COMMIT 
git checkout -f svn-reconsile 

git svn init file://path/to/repos/myproject/branches/git-import 
git svn fetch 

git svn set-tree HASH_OF_SECOND_COMMIT 

git rebase git-svn 

git merge master 

git svn dcommit 

Das Problem ist, dass die git svn dcommit nur eine Revision in Svn machen ... nicht für jeden Commit im master Zweig .... dafür ist die Geschichte in Svn gequetscht.

Also die einfachere Lösung ist einfach Start git-svn mit set-tree springen und zufrieden sein, dass die Geschichte ist immer noch in Git, auch wenn es nicht in Svn ist. Dies kann mit dem folgenden erfolgen:

git svn init file://path/to/repos/myproject/branches/git-import 
git svn fetch 

git svn set-tree HASH_OF_MOST_RECENT_COMMIT 

git rebase git-svn 

Wenn jemand eine Idee hat, wie um das Quetschen Problem zu erhalten (I --no-squash versucht haben) bitte Kommentar! In vielen cleveren Kommentaren werde ich nur akzeptieren, dass ich die git-Geschichte und die Pfropfung auf der letzten SVN-Version mit dem zweiten Code-Chunk oben behalten werde. tun so etwas wie die folgenden

Answer 5

Vom git SVN-Repository, das Sie, zu migrieren versuchen:

git remote add old-repo <path-to-old-repo> 
git fetch old-repo 
# to browse and figure out the hashes, if that helps 
gitk --all & 

# for each branch you want to graft 
git rebase --onto <new git svn branch base> <old-repo branch base> <old-repo branch tip> 

# when done 
git remote rm old-repo 

Zu Ihrer Information, sollten Sie auch die gleiche Sache mit git format-patch Lage zu tun, und git am, aber git rebase sollte freundlicher sein.

Answer 6

Ich habe eine Menge Arbeit daran getan, wenn ich mit Git-Geschichten für Memcached von ein paar Dingen zu tun habe. Vieles, woran ich gearbeitet habe, war zu verifizieren, dass jeder für seine Arbeit gutgeschrieben wurde.

baute ich ein tool einen Bericht zu erzeugen, zeigt genau, wo Bäume konvergente unabhängig von Hashes zu begehen, git Geschichten, Autoren, Committer, etc ... Werfen Sie einen Blick auf diese example report, die wir sehen verwendet, wo zwei unabhängige Repositorys die enthält dieselbe Information konvergierte.

Von dort habe ich gerade viele manuelle Veredelung und filter-branch ing nach vielen Google-und Mailing-List-Suchen, um herauszufinden, wer diese Leute, die Änderungen tatsächlich beigetragen haben, waren.