ich habe ein Eclipse Projekt unter Subversion/Subclipse, das in Trunk und Branch parallel weiterentwickelt wurde. Nun möchte ich klassisch den Branch-Code in den Trunk überführen.
Mein Problem: Die Merge-Funktion von Subclipse funktoniert nicht, weil unser SVN noch auch Version 1.4 läuft und ein Upgrade momentan nicht möglich ist. Auch Merge mit TortoiseSVN schlug fehl, da eine Arbeitkopie nicht als solche angesehen wird - die Fehlermeldung kann ich bei Interesse gerne posten. Eclipse => Compare To => Branch liefert nur Diffs gegen leere Dateien.
Meine Frage: Was sind eure Erfahrungen beim Reintegrieren? Kennt ihr sonstige Tools oder Eclipse-Plugins, die mir helfen könnten?
Die Änderungen in Trunk und Branch sind leider zu umfangreich, als dass ein manuelles Zusammenführen sinnvoll wäre.
Schöne Grüße und Danke, LastFreeNickname
---------------------------------------------------------------- Erstmal vielen Dank für eure vielen Antworten und die Diskussion! :-)
Im Endeffekt hab ich es leider so gemacht, dass ich - wie von Scout vorgeschlagen - das SVN umgangen bin und die Datei umkopiert habe. *schäm Nicht schön, aber das war die einzige Möglichkeit, die mir aufgrund technischer Einschränkungen blieb.
Als Zusammenfassung: 1. Checkout des Trunks nach coTrunk 2. Checkout des Branches nach coBranch 3. Händisches Kopieren aller Sourcen von coBranch nach coTrunk. Dabei ist zu beachten, keine .svn Infos (auch in den Unterverzeichnissen!!) mitzukopieren. 4. Commit von coTrunk in den Trunk. Änderungen werden nun gemerget.
Ok, da mir das jetzt oben zu blöd wurde hab ich nochmal kurz nachgelesen und herausgefunden, dass es auch mit dem MERGE Befehl gehen müßte. Hier kurze Erklärung: Nehmen wir an ein Zweig wurde getrennt und in beiden Zweigen (Stamm und privater Zweig) wurde weitergearbeitet. Den privaten Zweig möchte man nun nach Funktionsprüfung usw. wieder zurück in den Stamm überführen, so dass alle davon provitieren. Der Befehl "svn merge" vergleicht bekanntlich zwei Bäume um die Unterschiede auf die Arbeitskopie anzuwenden. Um also die Änderungen zu empfangen brauchen wir eine Arbeitskope des Stammes (TRUNK). Doch welche beiden Bäume sollen verglichen werden? Auf den ersten Blick offensichtlich den neuesten Stammbaum mit dem neuesten Zweigbaum! Doch das ist falsch. Da "svn merge" wie "svn diff" arbeitet, wird bei einem Vergleich nicht nur lediglich die Menge der Änderungen beschrieben, die im privaten Zweig vorgenommen wurden. Es wird außerdem auch Änderungen im Stammbaum angezeigt, die im privaten Zweig nie vorgenommen wurden! Um nur die Änderungen im privaten Zweig auszudrücken, muß man den Anfangszustand des privaten Zweigs mit dessen Endzustand vergleichen. Mit "svn log --stop-on-copy http://.../branch" kann man herausfinden in welcher Revision der Zweig erstellt wurde (zum Bsp. Rev. 2045). Der Endzustand ist die HEAD Revision. Das bedeutet, dass die Revision 2045 mit der Head Revision vergleicht werden muß und alle Änderungen auf die Arbeitskopie des Stammes angewendet werden müssen.
Vielleicht hilft es ein sauberes Checkout zu machen und mit dem gleichen client den Merge durchzuführen. Mit dem 1.4er und 1.5er Server hatten wir auch einige Probleme in zusammenhang mit TortoiseSVN (Achtung beim Einchecken des merge Ergebnis, überprüfen auf doppelte merges...). Ich vermute dass die Client Versionen vom Eclipse Plugin & TortoiseSVN zu unterschiedlich sind.
Zur Info: Seit wir auf 1.6er serverseitig sind haben wird nahezu keine Probleme mehr in diese Richtung, die repos sind viel kleiner und das Merge Tracking ist ziemlich gut.
Die bessere Lösung ist allerdings,das geb ich zu, das mit Merge zu machen. Woran hat es denn da gescheitert? Die Befehle hatte ich dir doch oben rausgesucht.
Brr, das ist kein Merge, sondern ein „wir schmeißen einfach eine Version weg“, was bei paralleler Entwicklung (siehe Frage) eine verdammt dumme Idee ist.
@Bombe: Genau das ist es eben nicht, weil SVN erkennt, dass es ein Merge machen muß anstatt ein Commit. Sonst könnten ja nie mehrere Entwickler an einem Projekt gleichzeitig arbeiten.
Du kopierst ein Verzeichnis über ein anderes. Wo findet denn da bitte ein Merge statt? Kann cp mittlerweile mergen? Ist mir was entgangen? Kann cp vielleicht auch den Welthunger besiegen?
Die Dateien werden dann so behandelt, als wenn du sehr lange dran Änderungen vorgenommen hast. (Da ist absolut kein Unterschied!) und ob ich nun händig drin rumschreibe oder drüber kopiere ist svn völlig egal.
Du änderst also in coTrunk beliebige Dateien, schmeißt Metainformationen aus coBranch weg, und svn commit kann daraus immer noch einen Merge generieren? Verstehe ich das richtig?
Richtig! "svn merge" versucht dann aus deinen geänderten Daten und der eingecheckten Version eine komplette neue Version zu machen - verbindet also beide Versionen miteinander. Sollte SVN dies zu kompliziert sein (weil zu gravierende Unterschiede) dann wird wird ein Konflikt ausgelöst. Diesen muß man zwar händig dann lösen, aber ist verständlich. Kleinere Änderungen werden jedoch vom SVN automatisch zusammen gebracht.
Wenn du jegliche Metainformationen von coBranch verwirfst, woher weiß svn commit, dass es einen Merge machen soll? Und wieso ist es ein Merge, wenn du eine Version (nämlich coTrunk) gnadenlos überschreibst? Ich fürchte, dir sind da einige Begrifflichkeiten nicht ganz klar…
Zumindest theoretisch kann ich den Ansatz von Scout verstehen. Eine Lösung, die die gesamte SVN-Logik umgeht, aber immerhin.
Habs praktisch ausprobiert, mit dem Ergebnis, dass unter Eclipse die Versionsinfo der Dateien interessanterweise mitkopiert wurde und es deshalb "Future Versions" gibt, die nicht in den Trunk commited werden können.
Hab beim Überschreiben sowohl alle Verzeichnisse, als auch nur den src-Ordner ausprobiert, das Ergebnis ist das gleiche.
@Bombe: Ich arbeite jeden Tag beruflich mit svn und ich weiß wie es programmiert ist und wie es funktioniert. Die Metainformationen geben ja lediglich an, woher svn die Dateien ausgecheckt hat. Da wir die Daten aber ehh nicht in den Branch Zweig wieder einchecken wollen, brauchen wir diese auch nicht. Einzig und allein die Metainfos von coTrunk brauchen wir zum Commit von coTrunk, coBranch bleibt völlig unangetastet im SVN. Es werden lediglich die Daten-Dateien überschrieben - so als ob die Daten von Hand geändert wurden.
@Scout, genau. Was dir dabei völlig verloren geht, ist die Information, dass dieser Commit ein Merge ist. Außerdem verlierst du sämtliche Änderungen, die in coTrunk, aber nicht in coBranch, gemacht wurden (außer in in coTrunk neu angelegten Dateien), und ich wiederhol’s nochmal: Das ist bei paralleler Entwicklung in coTrunk und coBranch einfach völlig daneben.
@Bombe: Es ist richtig, dass man die Information verleirt, dass das Commit ein Merge ist. Aber man verliert nicht alle Änderungen aus coTrunk. Dieses hat man ja ausgecheckt und mit coBranch überschrieben und mit dem Commit (eigentlich Merge) dann zusammengeführt.
@Scout, also, wird coTrunk jetzt überschrieben, oder irgendwie doch nicht? Du ergibst immer weniger Sinn. Wenn ich eine Datei überschreibe (von coBranch nach coTrunk KOPIERE), ist das, was vorher drin war, WEG. Da wird exakt NICHTS gemerget. Ich verstehe nicht, was es da nicht zu verstehen gibt. Ein anschließendes „svn commit“ macht aus einem KOPIEREN noch lange kein MERGEN.
@Bombe: Das behauptet ja auch keiner, dass aus dem Kopieren ein Mergen wird, es erspart nur Tipparbeit! Ob ich nun händisch in coTrunk die Daten ändere oder die Daten von coBranch rüberkopiere macht keinen Unterschied. Es geht nur darum, dass die Metadaten von coTrunk zum checkin genutzt werden können, mit dem geänderten Source-Code aus coBranch. Jetzt ein Commit von coTrunk bewirkt, dass die Daten mit dem Datenbestand im SVN GEMERGET werden, denn die Daten im SVN sind ja bisher unverändert. Hoffe das war jetzt verständlich. ;)
Also ist „Datei auschecken, ändern, einchecken“ jetzt auf einmal auch ein Merge? Das würde einiges erklären; in dem Falle wäre meine Definition von „Merge“ wohl falsch.
Nicht in jedem Fall! Nur wenn du auscheckst, deine Dateien änderst, in der zwischenzeit sich der Stammbaum geändert hat und du deine Arbeitskopie wieder einchecken willst... in diesem Fall wirst du sehen, dass Commit ein Merge macht ;) ...zumindest schreibt svn da bei mir hin ...file xyz merged.
