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-Repository mit mehreren aktiven Zweigen in GIT konvertieren
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?
Danke für die Rückmeldung. Ja, meine Frage war, den Workflow zu verwenden. Wenn ich die Dokumente für die Rosinenpickerei richtig verstehe, dann wären das zwei unabhängige commits in SVN und verschmelzen die commit auf v1 nicht in v2, oder? Da der SVN wirklich alt ist, denke ich, dass die Zweige bereits durcheinander sind. Frage ist, muss ich das zuerst in SVN lösen, oder kann ich dies direkt in GIT tun? –
Ich würde wahrscheinlich versuchen, es nach der Umwandlung in 'git' zu beheben und würde mich dann nicht damit befassen, es in die' svn'-Welt zurückzuspiegeln. – AnoE
Das wäre mein favorit, aber das Problem ist, dass die gesamte Infrastruktur (Build-System, CI, ect.) Meiner Firma auf SVN basiert, so dass ein SVN-Spiegel erforderlich ist. –