2010-05-07 11 views
6

Ich vermute, ich habe Mergeinfo beschädigt, aber ich bin mir nicht sicher. Weiß jemand, wie ich eine Entscheidung treffen würde und welche Ressourcen da sind, um Probleme zu beheben?Wie stelle ich fest, ob svn: mergeinfo beschädigt ist und wie würde ich es beheben?

Hier ist das Problem. Mein Team ist kürzlich zu agil gewechselt und nutzt Feature-Zweige (Story-Zweige), in denen verschiedene Teams gleichzeitig an denselben Quellen arbeiten. Wenn die Geschichte eine hohe Bereitschaft erreicht, geht das Team in den Stamm über. Die Zusammenführungen dauern aufgrund fehlender Änderungen, unerwarteter Änderungen und Konflikte Tage oder Wochen. Wir sprechen über Teams von 5-10 Leuten und die Mühe/Abwanderung scheint viel zu hoch.

Menschen nutzen die diese merge Muster a) PULL - fusioniert Stamm-zu-Zweig, lösen, zu testen, begehen b) PUSH - fusioniert Zweig-zu-Stamm, lösen, zu testen, begehen c) neu erstellen Zweig (oder in der Regel erstellen Sie eine neue Geschichte Zweig und Drop-alt, seit es fertig ist)

Am Ende dieser sollte der Zweig und Stamm in Ausrichtung sein.

Probleme sehen wir:

  1. Änderungen nicht während berichtet Stamm-zu-Zweig verschmelzen in den nachfolgenden Zweig-zu-Stamm
  2. Konflikte auf svn zeigen: mergeinfo Eigenschaften während merge
  3. Datei fehlt, aber lokale Bearbeitung für neue Datei in Zweig hinzugefügt und an Stamm
  4. eingehende + lokale löschen (Datei am Stamm gelöscht und Zweig zeigt als Konflikt)

(1) Sollte nicht passieren. Das Ziehen von Zweig zu Stamm sollte die beiden für alle Änderungen, die bereits am Stamm vorgenommen wurden, synchronisieren. Die Änderungen bei der Zusammenführung von Zweig zu Stamm sind Änderungen, die am Stamm vorgenommen wurden. In der ersten Zusammenführung sollten sie sich also zur Verzweigung ausgebreitet haben, aber nicht. Dies deutet auf eine Beschädigung von Mergeinfo-Daten hin, die Stammänderungen "verbergen".

(2) Sollte nicht passieren. SVN sollte die Änderungen im Merge-Tracking verwalten. Dies deutet auch auf eine Beschädigung der Mergeinfo-Daten hin.

(3) Sollte nicht passieren. Dies ist ein Fall einer neuen Datei, die in einem Zweig hinzugefügt wurde. Es sollte als neue Datei angezeigt werden, die dem Stamm hinzugefügt wurde. Dies deutet auch auf eine Beschädigung der Merge-Infodaten hin.

(4) Ich glaube, das ist ein SVN-Bug und das können wir nicht beheben. Wenn das unser einziges Problem wäre, wäre ich glücklich

Wir sind derzeit auf Svn 1.5.x Server mit Clients mit Svn 1.6.x und Svn + SSH für die Verbindung. Wir planen, zu den neuesten und größten SVN zu gehen, da einige Korrekturen unsere Probleme beeinflussen können.

Trotzdem sieht es so aus, als wären unsere Mergeinfo-Daten falsch.

  • Merges, die nicht melde alle Änderungen
  • Konflikte in merge von mergeinfo Eigenschaften

Jedes gute Plätze für mich zu Beginn der Suche?

+0

SVN 1.6.11 Client kann meine Antwort sein. Ich benutzte die Wandisco-Upgrade-Site (die rockt) und die Merge-Hölle ist viel weniger hellacious –

+0

Verwenden Sie die "- Reintegrate" -Flag für die "Push" -Fusion? Die Tatsache, dass du einen "Entschlossenheits" -Schritt nach mir hast, suggerierst du nicht. Ich kann keine spezifische Dokumentation finden, die besagt, dass Zwei-Wege-Zusammenführungen ohne "- Wiedereingliederung" nicht funktionieren können, aber die bloße Existenz von "- Wiedereingliederung" deutet darauf hin, dass das Verschmelzen von svn der Aufgabe ansonsten nicht gewachsen ist. – slowdog

Antwort

2

Ich habe einige Experimente mit SVN Branching/Merging durchgeführt, und ich habe herausgefunden, dass es Situationen gibt, in denen das Zusammenführen nicht funktioniert - zum Beispiel werden Änderungen vom Trunk überschrieben. Wenn Sie SVN für Feature-Zweige verwenden, werden Sie in der Welt der Schmerzen sein.

Ich machte ähnliche Experimente mit Git und ich habe keinen Weg gefunden, falsche Zusammenführung zu bekommen. Wenn der Wechsel zu Git vom Team/Management akzeptiert werden kann, empfehle ich dringend, es zu verwenden.

+0

Ich höre das, aber dass die Konflikte auf mergeinfo Eigenschaften scheinen ein tieferes Problem anzuzeigen –

+1

Ich denke, ich sollte mich klarer machen: Ich versuchte, Merge in SVN zu brechen, und mir gelang es bei meinem zweiten Versuch, aber ich konnte nicht erstellen korrumpiert/inkorrekt in Git zusammengeführt. So können Sie versuchen, die Ursache von Mergeinfo-Problemen zu verfolgen, oder Sie können Ihre Zeit effektiver nutzen und zu einem branchentauglicheren Versionskontrollsystem wechseln. – chalup

+1

Das Verschieben auf git in dem Zeitrahmen, in dem ich arbeite, ist keine Option. Also, ich muss mein Problem lösen in SVN –

2

Wir hatten ähnliche Probleme aufgrund ähnlicher Umstände und haben sie weitgehend gelöst.

Die große Gefahr, ist dies:

Wenn Sie in Ihren Zweig vom Stamm nach der Verzweigung Schöpfung verschmelzen, um Sie mit dem Zweig Flag Stamm benötigen commit (svn merge --record-only verwenden), sonst, wenn Sie versuchen, wieder in den Stamm zu reintegrieren, es versucht, das Commit von Stamm an den Zweig zurück in den Stamm zu verschmelzen.

Das ist offensichtlich enden Änderungen zurückkehrt nach dem späteren trunk-> Zweig gemacht Stamm begeht, neigt massive Konflikte (insbesondere Baum Konflikte, wenn Sie eine neue Datei oder ein Verzeichnis in Stamm erstellt) verursachen, usw.

So unser Verfahren ist es, entweder nie Sync Stamm in einem Zweig, nachdem es (funktioniert gut für kurzlebige Filialen) erstellt wird worden ist, oder die folgenden Funktionen ausführen:

  • Zweig b vom Stamm
  • verpflichtet sich Stamm und Zweig
  • reintegrieren Stamm in den Zweig und commit (Konflikte zu lösen, aber ansonsten keine Änderungen vorgenommen haben, auch zu kompilieren)
  • sofort ein svn merge tun --record-nur von der Stamm-zu-Zweig begehen Revision
  • beheben Sie alle anderen Probleme mit der Verzweigen Sie und setzen Sie die Entwicklung fort
  • Reintegrat von der Verzweigung zum Stamm, wenn Sie fertig sind.

Ich fand: http://www.collab.net/community/subversion/articles/merge-info.html hilfreich beim Ausarbeiten, was wir falsch gemacht haben.

+0

siehe auch http://stackoverflow.com/questions/3309602/subversion-branch-reintegration-in-v1-6 – Malcolm