Subversion Merging

Heute möchte ich über das heikle Thema Merging in Subversion berichten. Jeder der mit SVN arbeitet und mit Merging in Kontakt kam, hat sicher schon einige negative Erfahrungen gemacht. Ich werde euch zwar nicht vor Problemen bewahren können. Aber ich liste einen Leitfaden auf, welcher Aufzeigt, wie man ohne grössere Probleme durch das Merging hindurchkommt. Dies ist übrigens eine Zusammenfassung aus dem excellenten Manual vom svnbook, dass auf dem Netz frei verfügbar ist.

Leitfaden Merging

In den nächsten Zeilen folgt ein Leitfaden, wie Merging grundsätzlich funktioniert (gist Codeschnipsel)

Bei Merging haben sich ausserdem folgende wichtige Erkenntnisse bei mir durchgesetzt:

  • Aufpassen, das man die Befehle mit der richtigen Datenbasis absetzt (trunk oder branch)
  • Bevor Befehle ausgeführt werden, sollte das lokale Arbeitsverzeichnis synchron mit dem SVN Repository sein
  • Regelmässig mergen (mind. 1 mal pro Woche)! Wenn man zu lange wartet, hat man teilweise so viele Konflikte, dass es äussert mühsam ist, die 2 Datenstämme wieder zusammenzuführen.

Habt ihr noch spezielle Tips für’s Mergen?

9 Responses

  1. Hallo Daraff,

    zum regelmässigen mergen habe ich eine andere Meinung: denn das überführen eines noch nicht fertigen features in den trunk läuft ja gerade dem Zweck des branching zuwider. Wenn es um die Kompatibilität des trunks mit dem in Entwicklung befindlichen feature geht, dann solltest Du den trunk in einen zweiten branch auschecken und dann diesen mit dem feature-branch mergen. So bleibt der main-trunk funktionsfähig, und gleichzeitig stellst Du sicher, dass das neue feature zu ihm kompatibel ist.

    Ansonsten guter Artikel!

    Gruß,

    Torsten

  2. Hi Torsten

    Danke für dein Feedback.
    Es gibt natürlich verschiedene Varianten, wie man die Stabilität eines Trunks oder Branches sicherstellen kann. Bei meiner Variante (wie in Punkte 5 ersichtlich), muss das Feature im Branch fertig entwickelt werden. Erst dann darf von branch -> trunk reintegriert werden. Das merging von trunk -> branch sollte aber regelmässig gemacht werden.

    Zum Thema, wo jetzt nun die aktuell lauffähige Version im SVN sein soll (im Trunk oder in einem Version Branch) gibt es sehr unterschiedliche Meinungen und Diskussionen. Aber ich denke, jeder muss selber entscheiden, wie er es macht. Wichtig ist, dass allen klar ist, wie die Regeln sind 🙂

  3. Ich will ja nicht meckern, aber welche Aussage hat dieser Artikel? 😉
    Du wiederholst in meinen Augen nur was in der Dokumentation steht.

    Bei den Erkenntnissen kommen wir der Eigenleistung etwas näher. Hier würde ich noch Refactoring anführen: Wer in einem Branch refaktoriert sollte beim Merge ein paar Schritte manuell machen, denn komplette Vorgänge (Umbenennung, Löschung, Verschiebungen) kann SVN nicht gut abbilden. Kommen dann noch Konflikte ins Spiel, wird der Commit fehlschlagen.

    => Lieber in kleinen Schritten mergen…

  4. Hi Sven

    Du hast Recht.
    Der 1. Teil ist keine Aussage, sondern eine Zusammenfassung. Mich und viele andere nervt es wahrscheinlich, sich immer alles aus einem Manual zusammensuchen zu müssen.
    Ich mag es kompakt und dies dient auch für mich als Referenz.

    Den 2. Teil deiner Aussage kann ich nur unterstützen. Sobald man etwas “speziellere” Operationen verwendet, wird es anstrengend.
    Wenn ich die Wahl habe (sprich private) nehme ich nur noch DVCS (git oder mercurial), denn diese Versionierungssysteme haben in diesem Bereich massiv Vorteile.

    Ich werde diese Woche übrigens noch einen kleinen Vergleich bezüglich git und mercurial posten.

  5. Vielleicht wäre noch erwähnenswert wie man einzelne revisions merged.
    Folgendes Szenario: Bugfixing auf einem Versionsbranch (z.B. Revision 100-102 auf branch v_1_0), dann mergen des Features in den trunk:

    cd trunk
    svn merge -r 99:110 http://.../branches/v_1_0/

    Auch hilfreich, Änderungen rückgängig machen:

    svn merge -r 110:99 http://.../branches/v_1_0/

    Gruß

Leave a Reply

Your email address will not be published. Required fields are marked *