Eclipse SVN-Merge-Tool Eclipse

[tme]

Hallo,

wir haben begonnen, aufgrund unterschiedlicher Datenbankrevisionen und Lösungsvorschlägen in unserem Projekt mit Branches zu arbeiten. Eine tolle Erfindung, auch wenn das Wechseln manchmal ein wenig lange dauert.

Müssen wir einen Branch in den Trunk einfügen, so schlägt die Stunde des "Mergings". Hier haben wir Probleme mit der Bedienung oder dem spezifischen Merge-Tool, welches bei uns in Eclipse drin ist.

Das Tool ist unübersichtlich. Es sieht aus, als würde es nicht Java, sondern einfach Textdateien mergen, es hat also keine Kontextinformationen über die Bedeutung der einzelnen Zeilen, um ggf. bei einfachen Umformatierungen die Gleichheit trotz unterschiedlicher Formatierung festzustellen.

Das Tool scheint nur sehr wenig nach unten und oben zu scannen und erkennt in Dateien, die bis auf einen 20-zeiligen Einschub gleich sind, dies oft nicht. Ab dem Einschub gelten dann die Dateien als unterschiedlich.

Das Tool fügt beim Mergen Zeilen wie

<<<<<<<<<< mine
>>>>>>>>>> Rev136

ein. Diese bleiben anscheinend unter bestimmten Umständen erhalten, wenn man den Merge dann nicht komplettiert, so dass plötzlich Syntaxfehler in den zu mergenden Dateien auftauchen.

Kann jemand ein Tool empfehlen, welches für das Zusammenfügen von SVN-Zweigen gut geeignet ist? Es muß nicht zwangsläufig eine Eclipse-Integration bieten.

Danke.

 

[maki]

SVN kann doch selsbt auch MErgen, zB. von der Komandozeile aus.

Das Tool fügt beim Mergen Zeilen wie

Das ist normal bei Konflikten.

 

[kama]

Hallo,

Eine tolle Erfindung, auch wenn das Wechseln manchmal ein wenig lange dauert.

Wie macht ihr das denn ? per Switch ? Eventuell ist es besser einen Branch auszuchecken und dort die Änderungen / Anpassungen zu machen anstatt zu switchen....je nach größe der Working Copy ....

Hier haben wir Probleme mit der Bedienung oder dem spezifischen Merge-Tool, welches bei uns in Eclipse drin ist.

Welches Plugin nutzt ihr denn ? Subclipse, Subversive ?

Das Tool ist unübersichtlich.

Kann man drüber diskutieren....

Es sieht aus, als würde es nicht Java, sondern einfach Textdateien mergen, es hat also keine Kontextinformationen über die Bedeutung der einzelnen Zeilen, um ggf. bei einfachen Umformatierungen die Gleichheit trotz unterschiedlicher Formatierung festzustellen.

Das ist bei allen Versionskontrollsystemen der fall. Die wissen nichts über den Context...also ob das C, C++, Java, Ruby etc. ist...sondern das Ganze läuft Zeilenorientiert....
Um Probleme mit Formatierungen in den Griff zu bekommen erstellt man bzw. hält sich an Guide Lines...

Das Tool scheint nur sehr wenig nach unten und oben zu scannen und erkennt in Dateien, die bis auf einen 20-zeiligen Einschub gleich sind, dies oft nicht. Ab dem Einschub gelten dann die Dateien als unterschiedlich.

So weit ich weiß sind das 3-Zeilen...context diff eben...

<<<<<<<<<< mine
>>>>>>>>>> Rev136

Das bedeutet es ist ein Konflikt aufgetreten....
Dann gibt es aber auch noch Dateien wie xyz.java.rOldRev, xyz.java.rNewRev und xyz.java.mine...
Dort sind dann die Zustände der Dateien OHNE Bearbeitungen enthalten...bei .mine bedeutet dass die Datei lediglich die Datei wie der Stand vor dem Mergen war...xyz.java.rOldRev ist die Datei auschecken also bevor Du bzw. jemand Änderungen gemacht hat...und xyz.java.rNewRev ist dann die Datei die vom Repository bzw. vom Branch kommt...

Hier ist aber zu klären, ob die Änderungen in der lokalen Arbeitskopie nicht durch händische Änderungen kommen...

Sehr wichtiger Grundsatz wenn man mergen möchte: Eine saubere Arbeitskopie erstellen also OHNE Ausstehende Commits/Änderungen...im Zweifelsfalle einfach einen frischen Checkout machen...

Es gibt noch die Möglichkeit unter Eclipse: Team->Edit Conflict aufzurufen da kann man dann grafisch die Konlikte bearbeiten...

so dass plötzlich Syntaxfehler in den zu mergenden Dateien auftauchen.

Ein merge ist eben ein text-basierter Merge somit kann es immer vorkommen, dass Syntax oder schlimmer semantische Fehler (Funktion/Methode verhält sich anders als vorher)...Dazu sind Unit Tests unabdingbar....

Kann jemand ein Tool empfehlen, welches für das Zusammenfügen von SVN-Zweigen gut geeignet ist? Es muß nicht zwangsläufig eine Eclipse-Integration bieten.

Entweder wie schon vorgeschlagen die Kommandzeile oder TortoiseSVN auf Windows ...anderes Clients gibt es auch noch aber warum nicht in Eclipse ?

MfG
Karl Heinz Marbaise

 

[tme]

Wie macht ihr das denn ? per Switch ? Eventuell ist es besser einen Branch auszuchecken und dort die Änderungen / Anpassungen zu machen anstatt zu switchen....je nach größe der Working Copy ....

Zur Zeit machen wir dies per Switch. Wir können mal den Checkout probieren, danke.

Welches Plugin nutzt ihr denn ? Subclipse, Subversive?

Subversive. Ich weiß, dieses Thema wird fast so religiös diskutiert wie der 1TBS, aber bevor ich wieder wechsle und wieder nicht auf's SVN komme, würd' ich gerne möglichst bei dem Tool bleiben (war beim letzten Wechsel von Subclipse auf Subversive so).

Kann man drüber diskutieren....

Der Mangel an übersichtschaffenden Features wie verschiedene Colorierungen für verschiedene Probleme (Einschübe, Ersetzungen, Veränderungen) oder die Unfähigkeit, Einschübe oder Verschübe von Methoden zu erkennen, empfinde ich auch als objektiv ungünstig. Siehst du das anders?

Das ist bei allen Versionskontrollsystemen der fall. Die wissen nichts über den Context...also ob das C, C++, Java, Ruby etc. ist...sondern das Ganze läuft Zeilenorientiert.... Um Probleme mit Formatierungen in den Griff zu bekommen erstellt man bzw. hält sich an Guide Lines...

Ich glaube, mich zu erinnern, bereits für einige Sprachen von kontextsensitiven Tools für das Zusammenführen von Branches gehört zu haben, aber entweder ist mein Google-Fu zu schwach oder es gibt diese doch nicht.

Leider kann man nicht in jedem Projekt das perfekte Arbeitsumfeld haben, welches mittels Festlegungen solche Problemfelder umschifft. Der Eine sortiert die Member beim Speichern, der Andere läßt Auto-Formatieren, der 3. macht plötzlich 4er-Einrückungen.

So weit ich weiß sind das 3-Zeilen...context diff eben...

Für unsere Belange signifikant zuwenig.

Das bedeutet es ist ein Konflikt aufgetreten....

Grundsätzlich ist's natürlich äußerst ungünstig, wenn diese Annotationen in den Echtquellstand eingeführt werden und dann für Kompilierungsfehler sorgen. Einfach kleine Häufchen da lassen ist einfach unschön.

... anderes Clients gibt es auch noch aber warum nicht in Eclipse?

Ich habe noch keine von mir als nutzerfreundlich oder intuitiv empfundene SVN-Implementation für Eclipse gesehen. Ich habe das Gefühl, Hersteller von externen SVN-Tools kümmern sich besser um die Merge- und Browse-Fähigkeiten ihrer Software. Vielleicht läßt sich mit Eclipse-Entwicklungswerkzeugen schwieriger Geld verdienen, was weiß ich.

Danke für die weiteren Informationen.

 

[kama]

Hallo,

Zur Zeit machen wir dies per Switch. Wir können mal den Checkout probieren, danke.

Nutzt Ihr JavaHL Bindung oder Native Java ? Eventuell ist es auch schneller den Switch per command line zu machen...und dann in Eclipse ein Refersh....

Subversive. Ich weiß, dieses Thema wird fast so religiös diskutiert wie der 1TBS, aber bevor ich wieder wechsle und wieder nicht auf's SVN komme, würd' ich gerne möglichst bei dem Tool bleiben (war beim letzten Wechsel von Subclipse auf Subversive so).

Ich wollte nur wissen welches Ihr nutzt....Subclipse hat den Collabnet Merge Client dabei eventuelle hilft der nochmehr....

Der Mangel an übersichtschaffenden Features wie verschiedene Colorierungen für verschiedene Probleme (Einschübe, Ersetzungen, Veränderungen) oder die Unfähigkeit, Einschübe oder Verschübe von Methoden zu erkennen, empfinde ich auch als objektiv ungünstig. Siehst du das anders?

Wie gesagt das Ganze ist nun mal Zeilenbasiert...da beißt die Maus keinen Faden ab...Richtig gut finde ich das auch noch nicht....

Ich glaube, mich zu erinnern, bereits für einige Sprachen von kontextsensitiven Tools für das Zusammenführen von Branches gehört zu haben, aber entweder ist mein Google-Fu zu schwach oder es gibt diese doch nicht.

Welche ? Ich kenne eine ganze Menge Version Controll Tools aber leider ist mir so etwas noch nicht unter gekommen...(Da war mal was bei ClearCase für XML files...)....

Leider kann man nicht in jedem Projekt das perfekte Arbeitsumfeld haben, welches mittels Festlegungen solche Problemfelder umschifft. Der Eine sortiert die Member beim Speichern, der Andere läßt Auto-Formatieren, der 3. macht plötzlich 4er-Einrückungen.

Dafür gibt es einen CI Server bzw. das Build System dass die Style-Guides prüft und bei Verletzung entsprechende Reports erzeugt.....oder noch Härter beim Einchecken Prüft und bei Verletzung den Commit verbietet...

Grundsätzlich ist's natürlich äußerst ungünstig, wenn diese Annotationen in den Echtquellstand eingeführt werden und dann für Kompilierungsfehler sorgen. Einfach kleine Häufchen da lassen ist einfach unschön.

Tja..das ist wohl ein Problem...wenn sehr häufig solche Fehler auftauchen sollte man eventuelle mal über die Branching Strategie nachdenken...

Ich habe noch keine von mir als nutzerfreundlich oder intuitiv empfundene SVN-Implementation für Eclipse gesehen. Ich habe das Gefühl, Hersteller von externen SVN-Tools kümmern sich besser um die Merge- und Browse-Fähigkeiten ihrer Software. Vielleicht läßt sich mit Eclipse-Entwicklungswerkzeugen schwieriger Geld verdienen, was weiß ich.

Das Problem ist, dass SVN eine Sache ist und die Eclipse Plugins etc. eine andere....

MfG
Karl Heinz Marbaise