SVN und ständige Probleme

[freez]

Hallo,

ich komme aus einem Bereich, in dem straight im HEAD von einem CVS Server gearbeitet wurde. Ab und zu gab es mal ein Branch, aber die Regel wird im HEAD gearbeitet. Das funktioniert auch soweit ganz gut mit Eclipse Helios.

Nun muss ich auf einem SVN Server arbeiten. Es wurde die aktuellste Version von VisualSVN eingesetzt und ich habe privat ein Repository bei freerepository. Bei beiden erhalte ich immer wieder diverse Fehlermeldungen beim merging, egal wie rum ich merge. Nur weiss ich nicht, wie ich die tree conflicts lösen soll. Ich habe schon im den Eclipse Einstellung die out of date checkbox aktiviert und update nach dem commit immer brav die Ordner (warum auch immer ich das machen muss).

Ich weiß, dass ist nun alles recht vage, aber wenn mir Eclipse nur einen Fehlermeldung namens "tree conflict" präsentiert und mir nicht sagt,warum, und wie ich ihn lösen kann, komme ich nicht weiter. Könnt ihr mir Hinweise geben? Ich habe bedenken, dass ich falsch arbeite.

Übrigens, habe ich alles mit einem Testprojekt durchgeführt, wo ausschließlich ich arbeite. Habe ein Trunk Projekt erstellt, gebrancht und wollte einfach mal nach Änderungen im Trunk dies mit dem Branch mergen. Dann kommen die Fehler mit tree conflict:

merge --depth=infinity --ignore-ancestry https://svn.freepository.com/xxxxxxxxxxx/svn01/trunk@HEAD https://svn.freepository.com/xxxxxxxxxxx/svn01/branches/svn01_ProjektX@HEAD C:/Workspace/svn01Branch
    --- Merging differences between repository URLs into C:/Workspace/svn01Branch
      C C:/Workspace/svn01Branch/src/package2
      C C:/Workspace/svn01Branch/src/package
    Merge complete.
    ==== Conflict Statistics: =====
    Tree conflicts: 2

Ich habe lediglich im trunk ein neues package "package2" mit einer Klasse "Test".

 

[kama]

Hi,

zuerst einmal in Deinem Falle, wenn der Branch richtig erzeugt wurde, kannst Du das mergen des Branches in den Trunk ganz einfach wie folgt machen:

svn merge https://svn.freepository.com/xxxxxxxxxxx/svn01/branches/svn01_Proj

Dabei ist lediglich die Voraussetzung, dass Deine Working Copy aktuell auf dem trunk steht und unbedingt keine Änderungen mehr enthält die noch nicht committet sind!

Unter dem richtigen Erzeugen eines Branches verstehe ich, dass der Branch per

svn copy URL/trunk URL/branches/BRANCHNAME -m"- ...."

Das Ganze mit "ignore ancestry" ist nicht notwendig!

Gruß
Karl Heinz Marbaise

 

[freez]

Hi,zuerst einmal in Deinem Falle, wenn der Branch richtig erzeugt wurde,

Nun, "SVN Repsotires" rechts angeklickt, "branch/tag", neuen Ort gewählt, HEAD Revision und GO! Dann den Branch in ein separates Java Projekt ausgecheckt.

Dann Änderung im Branch -> commit (neues package mit klasse)
Dann Änderung im Trunk -> commit (neues Package mit anderen Namen mit Klasse)

Rechte Maus auf Branch Projekt -> Team -> Merge

Dann kommt der tree conflict

PS:

Dabei ist lediglich die Voraussetzung, dass Deine Working Copy aktuell auf dem trunk steht und unbedingt keine Änderungen mehr enthält die noch nicht committet sind!

Ich habe eine working copy auf den trunk und eine auf den branch. Dann mache ich vor dem merge auf alle Fälle noch ein commit.

 

[schalentier]

Die wichtigsten Regeln:

1. Nutze unbedingt und ausschliesslich (alle im Team + Server) Version 1.6
2. Merge IMMER den kompletten Branch, niemals (NIEMALS) nur einen Unterordner oder aehnliches
3. Pass auf, dass du NIEMALS an den SVN-Merge-Info Properties rumschraubst

Mit diesen Regeln sollte es eigentlich klappen, aber wir haben trotzdem staendig Probleme. Vor allem bei den "unbedarfteren" Kollegen.

Deshalb arbeiten wir, um diese Konflikte moeglichst zu umgehen, so:

1. Immer im "entferntesten" Branch arbeiten (z.B. Bugfix im aktuellen Produktiv Branch)
2. Sobald die Arbeit abgeschlossen ist, schrittweise nach vorne Mergen (Merge by Revision), also zuerst Merge in aktuellen Release Branch, zuletzt in den Trunk -> Ja, jeder muss seine Commits direkt und selbst mergen.
3. Viel Hoffen (fuer die Glaeubigen, viel Beten)

Aktuell steigen wir grad auf Git um und ich muss sagen, nach der anfaenglichen Verwirrung: Die beste Entscheidung in den letzten Jahren!

 

[freez]

@schalentier: Klingt ja nicht gerade danach, als wenn man es nicht problemlos einsetzen kann.
@schalentier: Was ist beim GIT in Bezug aufs mergen besser/anders?

Ich muss sagen, ich habe bis jetzt im CVS solche Probleme mit dem mergen nie gehabt. Kann das jemand bestätigen,oder habe ich bis jetzt zu wenig gemergt 🙂

 

[bygones]

@schalentier: Was ist beim GIT in Bezug aufs mergen besser/anders?

alles.. einfach alles 😀

Ich muss sagen, ich habe bis jetzt im CVS solche Probleme mit dem mergen nie gehabt. Kann das jemand bestätigen,oder habe ich bis jetzt zu wenig gemergt 🙂

definitiv zu wenig gemergt... wenn man erstmal git nutzt sieht man wie man mergen kann/sollte...

 

[maki]

Ich muss sagen, ich habe bis jetzt im CVS solche Probleme mit dem mergen nie gehabt. Kann das jemand bestätigen,oder habe ich bis jetzt zu wenig gemergt 🙂

Es gab doch mal die These, dass Leute, die mit CVS zufrieden sind, es schlicht nicht wirklich nutzen 😉

Branching, Merging etc. pp. sollten zumindest seit SVN zur täglichen Arbeit gehören, nicht weil man sie erst mit SVN brauchte, sondern weil das mit CVS so komplex, umständlich und riskant war, dass Leute es schlicht nicht machten.

 

[schalentier]

Was ist beim GIT in Bezug aufs mergen besser/anders?

Git ist fuers Mergen entwickelt, SVN fuers Branchen. Klingt bloede, is aber so. SVN schmueckt sich ja damit, dass Branches einfach, schnell und "preiswert" (in Bezug zu den dafuer benoetigten Resourcen) sind. Das stimmt auch, nur leider haben die Entwickler das Mergen vergessen.

Git ist anders und anfangs ziemlich verwirrend. Der Hauptunterschied ist, dass bei Git jeder Commit ein Knoten in einem grossen "Commit"-Graphen ist, der Kanten zu seinen "Parent"-Commits hat. Jeder Commit hat also mindestens 1 Parentcommit (ausser der erste), ein Mergecommit hat mehrere. Der Vorteil dabei ist, dass man aus jedem Commit den kompletten Sourcecodebaum erstellen kann und genau weiss, welche Commits wohin gemergt wurden. Diese Info fehlt bei SVN und wurde mit diesem komischen SVN-Merge-Properties nachtraeglich eingebaut.

Ein Branch im Git ist uebrigens einfach nur ein Zeiger auf einen bestimmten Commit.

Die vielen Git Kommandozeilen Tools machen nun im Grunde nichts anderes, als den Graphen zu bearbeiten. Zusaetzlich ist der Graph auch noch verteilt auf mehrere Repositories und kann bei Bedarf synchronisiert werden (fetch).