SVN-Repository mit mehreren aktiven Zweigen in GIT konvertieren

Question

Ich versuche mein SVN-Repository in ein GIT-Repository zu konvertieren. Das Problem dabei ist, dass im SVN mehrere aktive Zweige für verschiedene Softwareversionen parallel verwaltet werden. sieht also die SVN-Setup somthing wie folgt aus:

SVN ROOT 
|- trunk 
|- branches 
| |- v1 
| |- v2 
| |- v3 
|- tags 
| |- v1 
| | |- 0 
| | |- 1 
| |- v2 
... 

Jetzt möchte ich für jeden der Zweige der der SVN ein Git-Repository mit einem Zweig erstellen. Das Erstellen des Repositorys und das Portieren der Tags ist überhaupt kein Problem. Ich bin ein

git svn init -s --tags=tags/v1 --tags=tags/v2 <REPO_URL> 
# modified .git/config to use tags/v1/* for the tags of the different versions 
git svn fetch 

tun und danach bekomme ich die Zweige wie gewünscht, und ich bin in der Lage, die verschiedenen Software-Versionen zu überprüfen, indem Sie

git checkout -b v1 origin/v1 

Das Problem ist, dass die SVN-Repository ist sehr alt und die verschiedenen Zweige verzweigen alle von der Stamm. Aber meine Entwicklung erfordert, dass ich einen Fehler in v1 beheben, merge es zu v2 als auch und dcommit alles zurück zu SVN.

Also meine Frage ist, was ist der beste Weg, um sauber (mergable/rebaseable) GIT-Zweige zu bekommen? Und wie soll der Workflow damit sein? Soll ich einen neuen Zweig für jede Version in GIT hinzufügen, sagen wir mal svn_v1, die v1 in diese rebase und dann dcommit von dort? Oder was ist der beste Weg, um das Commit zurück zu SVN zu bekommen?

EDIT:

Ich habe bereits versucht, die verschiedenen Zweige nach der Zusammenführung stromaufwärts nach rebase (zB umbasiert v2 auf v1 und trunk auf v2), aber dies verkorkste meine histroy und bei dem Versuch zu dcmit wollte es alle Commits, die ich oben auf der aktuellen Geschichte rebased Commit haben. Dies würde die SVN Geschichte chaotisch machen, da diese Commits bereits im Repo sind.

EDIT2:

Um das Problem deutlich zu machen. Imageine die folgende Geschichte:

 D--E--F v1 K--L--M v2 
    /  /
A--B--C--G--H--I--J--N trunk 
^
    | 
    introduced a bug 

Wie begehen B einen Fehler eingeführt, Alle Branchen v1, v2 und trunk betroffen sind. Die Richtlinie meiner Firma ist jetzt (in SVN), dieses Problem in der am wenigsten betroffenen Zweigstelle zu beheben (v1 in diesem Fall) und dann den Commit über die Zweige bis zu trunk zusammenzuführen. Wie sieht der Workflow in GIT so aus, dass in SVN das Commit in v1 als in v2 zusammengeführt markiert wird?

Answer 1

Ok, ich habe es endlich geschafft, dieses Problem selbst zu lösen. Ich habe das in zwei Schritten gelöst: Zuerst, da unsere Code-Basen für v1 und v2 gut sind (Aufbauen und Arbeiten, beide mit den bekannten Fehlern behoben), habe ich eine Zusammenführung des v1 Zweiges in die v2 aufgenommen Verzweigung und v2 in trunk in svn. Jetzt bin ich in der Lage, die Zweige in git zusammenzuführen. Dann habe ich diese Passage in der git-svn Dokumentation gefunden:

Config-Schlüssel: Svn.pushmergeinfo

Diese Option bewirkt, dass git-svn versucht, die svn: mergeinfo-Eigenschaft im SVN-Repository nach Möglichkeit automatisch zu füllen. Momentan kann dies nur durchgeführt werden, wenn Nicht-Fast-Forward-Merges durchgeführt werden, bei denen alle Eltern außer dem ersten bereits in SVN gedrängt wurden.

Also habe ich diesen Config-Wert

aktiviert

git config svn.pushmergeinfo true 

und jetzt, wenn ein neuer Fehler gefunden wird, ich bin es in der niedrigsten Version Befestigung, die diesen Fehler hat, dcommit es svn, und anschließend unter Verwendung der Option --no-ff in die nächste Version zusammenführen. Wenn ich jetzt dcommit von dort, werden die Mergerinfos in svn aktualisiert und alles ist in Ordnung.

Answer 2

Klingt, als ob Sie Ihre Bugfix in v1 tun und dann in v2 vor dem Commit beide Kirschen picken. Dies ist weder eine Zusammenführungsoperation noch eine Umsetzungsoperation unter git. Es wäre, wenn Sie die Änderung in v1 tun würden, dann fusionieren Sie das in master, dann merge-oder-rebase das in v2.

Ich gebe zu, ich bin nicht sicher, wo das Problem ist, nach Ihrer Beschreibung, obwohl. Es klingt eher nach einem Workflow-Problem als nach einem git-svn-Problem für mich? Wenn deine Svn-Zweige gut sind (d. H. Keine totale Unordnung), dann sollte git init sie so übertragen haben, dass du wie gewohnt mit ihnen arbeiten kannst. Wenn sie auf der SVN-Seite bereits stark degradiert sind, dann kann sie dieses Durcheinander wirklich nicht "reparieren".

BEARBEITEN: Um auf Ihre zweite Bearbeitung zu reagieren: Was Sie beschreiben (Verteilung eines Hotfixes/Patches über alle Zweige) wird in git "cherry-picking" genannt, nicht verschmelzen. git muss (und muss nicht) nachverfolgen, ob Sie etwas ausgewählt haben oder nicht; du machst es einfach und bist damit fertig. Sie möchten auf keinen Fall Zusammenführungen oder Rücklagen in Ihrem Szenario vornehmen.

So, hier ist was Sie tun können:

1. Ihre Situation

    D--E--F v1 K--L--M v2 
       /  /
   A--B--C--G--H--I--J--N trunk 
   ^
       | 
       introduced a bug 
   

2. Ihr Bug Fix und alles daran setzen, v1, wenn das Ihre Politik ist.

   git checkout v1 
   # fix bug 
   git add ; git commit 
   # note the commit hash you just created, let's call it a1b2c3d4 
   

3. zu den anderen Zweigen

   git checkout v2 
   git cherry-pick a1b2c3d4 
   
   git checkout trunk 
   git cherry-pick a1b2c3d4 
   

4. Neue Situation

    D--E--F--a1b2c3d4 v1 K--L--M--abcde123 v2 
       /     /
   A--B--C--G--H-------------I--J--N--bca123123 trunk 
   ^
       | 
       introduced a bug 
   

Das ist es verteilen. git cherry-pick nimmt automatisch den Diff/Patch für diesen einzelnen Commit, wendet ihn auf Ihren aktuellen HEAD an und erstellt einen neuen Commit. Es gibt (von Entwurf) nichts "backstage", es ist ein ziemlich einfaches Verfahren. Es kann wie üblich zu Konflikten kommen, die Sie möglicherweise manuell beheben müssen, aber git wird Ihnen sagen, was Sie mehr oder weniger klar machen müssen.

Wenn Sie Ihre reguläre Arbeit später fortsetzen und diese Zweige zusammenführen/rebasen, muss git nicht über das Rosinenpicken wissen. Das Zeug ist in Ihren Dateien, es wird sehen (oder nicht sehen) die textlichen Unterschiede, und mit ein bisschen Glück wird alles gut.