Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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.
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 ....
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.
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...
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.
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 ....
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).
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.
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.
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.
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).
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?
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.
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.
