# Eclipse + Subversive synch



## Der Müde Joe (28. Mai 2009)

Ich bin gerade Subversion am anschauen. Dazu verwende ich Eclipse mit Subversive. Nun habe ich ein Szenario, in welchen 2 Personen 1 Klasse im SVN modifizieren (jeweils 1 Methode hinzufügen) und der ein comited. Nun macht der 2 ein synch und es kommt zum Konflikt. Eigentlich kein Problem, ich möchte die Methode übernehmen und dann meine Änderungen comiten. Mit einem normalen update gibts so einen <<<<<mine Zeugs. Eigentlich möchte ich die Methode vom remote übernehmen. Nun muss ich das <<< Zeugs manuell entfernen, als merged marken und dann commiten. Dünkt mich etwas komisch. (Kenns halt nur vom CVS her. Änderungen vom remote reinsaugen (Pfeil nach local), saven, marken, commit). Gibts da eine komfortablere Lösung dafür oder mach ich einfach was falsch? Vor allem bei vielen Änderungen dünkt mich das nicht gerade einfach? Irgend wie blicke ich da nicht so ganz durch im Moment. Vielleicht weiss ja jemand was davon.:bahnhof:


----------



## maki (28. Mai 2009)

Wenn beide Personen dieselbe Zeile (Methode) ändern, gibt es einen Konflikt, daher dieses <<<< mine, ist mit CVS auch nix anderes 
Der Merge Algorythmus von SVN ist zwar um einiges besser, aber in so einem Fall kann wohl nur ein Mensch entscheiden.

Wenn du die Methode aus dem Repo übernehmen möchtest, gehen deine Änderungen verloren, dazu "Override and Update" auswählen.


----------



## Der Müde Joe (28. Mai 2009)

>dieselbe Zeile (Methode)

Naja Zeile ist es schon die selbe..aber Methode eben nicht. Die ein ist x die andere y. Oder hab ich da was falsch verstanden?


----------



## maki (28. Mai 2009)

Naja, SVN versteht kein Java 

Für SVN ist das diesselbe Zeile, geht auch gleich los, aber dann anders weiter 

Die Konfilkte kannst du auch vor dem update ansehen, werden Rot markiert, ist zu empfehlen sich die vor dem eigen. Update anzusehen, denn da kann man ja noch sehr einfach manuell eingreifen.

Bin persönlich der Meinung dass SVN da richtig reagiert, einer von euch hat die Methode umbenannt, ein autom. Merge kann da nicht viel helfen, nur ein Refactoring, und das wäre etwas viel für SVN.


----------



## Der Müde Joe (28. Mai 2009)

>Naja, SVN versteht kein Java

hast ja recht... ;-)

>Die Konfilkte kannst du auch vor dem update ansehen...

Genau darum gings mir eigentlich. Irgendwie klapp das auch bei diesen Beispiel. Hab mich nur gewundert, weils mir teils so Zeugs (siehe pic) zusammen kopiert hat, was ich irgendwie gar nicht so lustig fand. y12 wurde sauber übernommen, die 2. Methode so irgendwie zusammengewurstelt. Dachte dabei mehr an so ein kopiers an ein anderes Ort oben oder unter, aber nicht so ein Chaos.

Beim CVS konnte ich immer eine Klasse updaten, wenn sie nicht im Konflikt stand. Wobei zwei verschiedene Methoden nie ein Konflikt bedeuteten. Die eine wurde einfach reingeupdated und gut wars. Dann mein commit..

naja. gut mal soweit...testet gerade das branch mergen und solch lustige Sachen, da kommt sicher noch was zusammen.

danke mal soweit


----------



## Wildcard (28. Mai 2009)

Der Müde Joe hat gesagt.:


> Wobei zwei verschiedene Methoden nie ein Konflikt bedeuteten. Die eine wurde einfach reingeupdated und gut wars. Dann mein commit..


CVS spricht auch kein Java. Wenn du die gleiche Zeile änderst hast du in der Regel einen Konflikt, auch bei CVS.


----------

