| 

.NET C# Java Javascript Exception

1
Hallo Community,

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.
15.09.2009
LastFreeNickname 316 1 7
6 Antworten
3
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.

Hier die entsprechenden Befehle:

cd projekt/trunk
$ svn update
At Revision 2203

$ svn merge -r 2045:HEAD http://svn.domain.de/repos/projekt/branches/my-projekt-branch
U file1.c
U fileXYZ.h
U Makefile

$ svn status
M file1.c
M fieleXYZ.h
M Makefile

$ svn commit

Tadaaaa! Wir haben fertig.

Grüßle
15.09.2009
Scout 1,4k 2 8
Jahaha! Denn nur ein Merge ist auch ein Merge. :)
Bombe 16.09.2009
2
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.
15.09.2009
jdehaan 434 2 7
0
Ich kann dir für zukünftige arbeiten das Subversive Plugin für Eclipse empfehlen. Ich hatte mit Subclipse auch sehr viele Probleme.
15.09.2009
kernkraft 144 2
0
(Huch, falsches Eingabefenster.)
15.09.2009
Bombe 219 1 4
Bombe 219 1 4
0
>> Eintrag in Frage verschoben.
16.09.2009
LastFreeNickname 316 1 7
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.
Scout 16.09.2009
-1
Hmm wenn alle Stricke reißen bleibt halt nur noch folgender Weg:


    1. Checkout vom Trunk in Verzeichnis coTrunk
    2. Checkout vom Branch in Verzeichnis coBranch
    3. .svn Verzeichnisse vom coBranch entfernen
    4. coBranch über coTrunk kopieren
    5. Commit coTrunk (macht effektiv Merge)


Wenn natürlich sehr große Änderungen gemacht wurden, dann traut SVN sich das Merge nicht automatisch, wirft ein Konflikt und verlangt Usereingriff!

Grüßle
15.09.2009
Scout 1,4k 2 8
Scout 1,4k 2 8
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 15.09.2009
@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.
Scout 15.09.2009
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?
Bombe 15.09.2009
@Bombe: cp kann kein merge, aber "svn commit" ;-)
Scout 15.09.2009
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.
Scout 15.09.2009
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?
Bombe 15.09.2009
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.
Scout 15.09.2009
ups meinete im vorhergehenden Kommentar natürlich "svn commit" und nicht "svn merge" :(
Scout 15.09.2009
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…
Bombe 15.09.2009
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.

LastFreeNickname 15.09.2009
@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 15.09.2009
EDIT: Hab beim Überschreiben sowohl alle Verzeichnisse *außer .svn*, als auch nur den src-Ordner ausprobiert, das Ergebnis ist das gleiche.
LastFreeNickname 15.09.2009
@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 15.09.2009
@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 15.09.2009
@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 15.09.2009
@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. ;)
Scout 15.09.2009
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.
Bombe 16.09.2009
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.
Scout 16.09.2009

Stelle deine Eclipse-Frage jetzt!