Frage zum Confilctauflösen in SVN (Eclipse Plugin)

[Maik.Neumann]

Juten Tach,

ich hätte da mal eine Frage bzgl. SVN an euch. Ich nutze erst seit kurzem SVN und bin gerade dabei einen Konflikt aufzulösen.

Hier ist der folgende Konflikt:

<<<<<<< .mine

 public void testMethod(int i){
   
      System.out.println("Variable i mit dem Wert " + i + " wird mit der Funktion println ausgegeben!");

 }

=======

 public void testMethod(int i){
   
      System.out.println("Eine andere Art der Datenausgabe");
      System.out.print("Variable i mit dem Wert " + i + " wird mit der Funktion print ausgegeben!");

 }

>>>>>>> .r7

Nun muss ich doch in meiner Eclipse IDE in die Synchronisationssicht wechseln und dort edit Conflicts sagen. Nun sehe ich das obere Ergebnis und weiß nciht genau, was ich damit machen soll (ich weiß nur, dass ich irgendwann marked as merged im Kontextmenü angeben muss). Kann mir da vielleicht jemand weiterhelfen (der obere Bereich müsste ja meine local Änderung sein und die untere die Version, die im Repository steht, in diesem Fall Revision 6, richtig?)

Danke und Gruß
Maik

 

[turtle]

Diese Anzeige soll dir helfen, zu beurteilen, welche Version du denn jetzt als aktuell betrachten möchtest.

Die Zeilen zwischen

<<<<<<< .mine
=======

beschreiben deinen aktuellen Codestand in deinem lokalen Workspace.
Danach zwischen

=======
>>>>>>> .r7

werden die Zeilen aus dem SVN-Respository, hier Revision 7 angezeigt, die zu deinen Zeilen in Konflikt stehen.
In deinem Beispiel siehst du, das jemand eine weitere Zeile eingefügt hatte, die du noch nicht übernommen hast.

System.out.println("Eine andere Art der Datenausgabe");

Also musst du entscheiden, ob die Zeile richtig war. Dann übernimmst du die Zeile bei dir ebenfalls.
Oder du meinst, die Zeile muss weg, also lässt du die Zeile raus. Dabei schmeisst du aber die Änderung, die gemacht wurde, praktisch weg und könntest dir Zorn vom vorherigen Committer einhandeln.

Egal, wie du dich entscheidest, musst du Eclipse sagen, das du den Konflikt behoben hast (mark as merged). Dann sollten auch die Zusatzdateien <Datei>.mine und <Datei>.r7 automatisch entfernt werden.
Danach kannst du problemlos committen.

Solch ein Konflikt kommt übrigens häufiger vor, wenn lange kein Update aus SVN gemacht wurde. Dann steigt natürlich die Chance, das jemand in denselben Dateien, die du bearbeitest hast, ebenfalls Änderungen gemacht hat. Daher mein Rat: Häufig, und UNBEDINGT vor einem Commit, ein Update machen!

 

[Maik.Neumann]

Also musst du entscheiden, ob die Zeile richtig war. Dann übernimmst du die Zeile bei dir ebenfalls.
Oder du meinst, die Zeile muss weg, also lässt du die Zeile raus. Dabei schmeisst du aber die Änderung, die gemacht wurde, praktisch weg und könntest dir Zorn vom vorherigen Committer einhandeln.

Aber wie genau mache ich das denn? Kopiere ich diese eine Codezeile dann oben in meinen Block zwischen <<<<<<< .mine und ======= einfach hinein und belasse zwischen ======= und >>>>>>> .r7 alles so wie es jetzt gerade ist? Und diese Kennzeichnungen wie ======= und >>>>>>> .r7 und <<<<<<< .mine lassen ich ebenfalls komplett stehen und unberührt?

Häufig, und UNBEDINGT vor einem Commit, ein Update machen!

Aber würde ich damit nicht meine lokalen Änderungen (egal wieviel) sofort wieder überschreiben?

 

[turtle]

Aber wie genau mache ich das denn?

Ich benutze immer Team/Synchonize with Repository. Dann kann man sich die anzeigen lassen, welche Dateien im Repo neuer sind als deine workspace-Dateien oder umgekehrt oder welche dateien in Konflikt stehen.

Bei letzterem kannst du dann entscheiden,welche Zeilen du für richtig hältst, indem du darauf klickst, ob du die Repo-version in deiner Workspace-Version aufnehmen möchtest (copy current change from right to left) oder die Workspace-Version bereits richtig ist.

Endresultat muss natürlich kompilierfähiges Java sein.

Da ich derzeit keinen Konflikt habe, weiss ich nicht genau, ob Eclipse hier sauber aufräumt. Andernfalls musst du die <<<<<<< .mine und ======= Zeilen aus der Java-Konfliktdatei händisch löschen.

Aber würde ich damit nicht meine lokalen Änderungen (egal wieviel) sofort wieder überschreiben?

Nein, da passiert nix. Eclipse weiss schon, das du Änderungen gemacht hast und merged automatisch die Repo-Änderungen ein ohne deinen Code kaputt zu machen.