Wie arbeite ich gleichzeitig an Version 1.1 und Version 2.0?

Question

Die Situation:Wir haben die Beta-Phase hinter uns und Version 1.0 wurde für mehrere Kundenstandorte veröffentlicht.Team A ist bereits damit beschäftigt, an Version 1.1 zu arbeiten, die inkrementelle Bugfixes und Verbesserungen der Benutzerfreundlichkeit beinhalten wird, während ein anderes Team an Version 2.0 mit umfangreichen Änderungen arbeitet, bei der der Kern des Produkts möglicherweise komplett neu gestaltet wurde.Nun müssen die meisten der für 1.1 vorgenommenen Änderungen irgendwann ihren Weg in 2.0 finden, und einige der im 2.0-Zweig vorgenommenen Fehlerbehebungen müssen möglicherweise tatsächlich für eine frühere Version geplant werden.Das Problem besteht darin, dass 2.0 grundlegende Unterschiede aufweist und daher keine Änderungen aus 1.1 ohne manuelle Konvertierung übernommen werden können und umgekehrt.

Meine Frage:Was sind die besten Methoden zur Revisionskontrolle, um Zusammenführungskonflikte und doppelte Arbeit in einer solchen Situation zu minimieren?Wie kann ich sicherstellen, dass meine Teams so wenig Zeit und Mühe wie möglich mit Revisionskontrollproblemen verbringen und gleichzeitig den Kunden regelmäßig Patches zur Verfügung stellen?

Answer 1

Eine gute Möglichkeit besteht darin, jeden Fehler im Stable-Zweig zu beheben und den Stable-Zweig mit dem Entwicklungszweig zusammenzuführen.Dies ist das Parallele Wartungs-/Entwicklungslinien Muster, und der Schlüssel liegt darin, früh und oft zusammenzuführen.Eine seltene und späte Zusammenführung führt dazu, dass der Entwicklungszweig im Vergleich zum stabilen Zweig nicht erkennbar ist oder der Fehler nicht auf die gleiche Weise wiederholt werden kann.

Subversion Enthält seit Version 1.5 eine Zusammenführungsverfolgung, sodass Sie sicherstellen, dass derselbe Änderungssatz nicht zweimal zusammengeführt wird, was zu albernen Konflikten führt.Es gibt noch andere Systeme (z.B. Git, Mercurial, Accurev, Notgedrungen) Mit deren Abfragen des Typs "Welche Änderungen in Zweigstellen A wurden nicht in Branch B zusammengeführt?" und Kirschige die Korrekturen, die Sie über den Entwicklungszweig benötigen.

Answer 2

Der Artikel Hier (Alltäglich mit Subversion) erwähnt, dass eine Methode darin besteht, Version 2 ständig mit Daten aus dem Build der Version 1.1 zu aktualisieren.In dem Artikel sagt der Typ, dass man das jeden Tag machen soll.

Der Teil, den Sie lesen möchten, trägt den Titel „Kellner, in meinem Kofferraum ist ein Käfer!“.Es ist ungefähr die Hälfte des Artikels.

Answer 3

Zu diesem Zweck würde ich mich wahrscheinlich auf ein Problemverfolgungssystem verlassen und sicherstellen, dass jede Änderung, die weitergeleitet werden muss, im Trunk-Code markiert wird.Sie können dann sicherstellen, dass die Eincheckkommentare für jede Änderung auf das relevante Problem verweisen und die Absicht der Codeänderung klar zum Ausdruck bringen, sodass sie bei der erneuten Implementierung im Trunk leicht verständlich ist.

Answer 4

So ziemlich das, was alle anderen gesagt haben, aber ich dachte, ich würde meine Erfahrung mit der Abwicklung der Entwicklung in mehreren Zweigen mithilfe von SVN einbringen

Bei unserem Hauptprodukt müssen wir gleichzeitig in mehr als zwei Versionen entwickeln.

Ursprünglich habe ich den Hauptstamm als „Hauptentwicklungsversion“ verwendet, wobei Tags für jede tatsächliche Version verwendet wurden.Zweige wurden für erhebliche Entwicklungsanstrengungen für einen neuen Funktionsumfang verwendet.Später, als wir anfingen, an 2, 3 und 4 Releases gleichzeitig zu arbeiten, begann ich, für jede Revision einen Zweig zu verwenden.

Da ich das Repository verwalte und mich auch um das Pushen von QA-Builds kümmere, stelle ich sicher, dass ich jeden Morgen „Rollups“ durchführe, die darin bestehen, Änderungen im Baum zusammenzuführen, beginnend mit dem niedrigsten derzeit aktiven Zweig.Am Ende füge ich also Änderungen von 1.1 in 1.2 zusammen, die mit allen anderen Änderungen von 1.2 seit der letzten Zusammenführung usw. in 1.3 zusammengeführt werden.

Wenn ich einen Commit durchführe, stelle ich sicher, dass ich den Commit immer mit etwas wie „kommentiere“.

zusammengeführt 1.1 Rev. 5656-5690

Es kann etwas mühsam sein, aber es funktioniert :)

Answer 5

Führen Sie frühe und häufige Zusammenführungen durch und stellen Sie sicher, dass die Qualitätssicherung in der Hauptlinie die in jedem Patch der Wartungsversionen behobenen Fehler kennt und regressiert/überprüft.

Es ist wirklich einfach, etwas herauszurutschen und einen Fehler in einer späteren Version zu „beheben“, und ich sage Ihnen: Den Kunden ist es egal, wie kompliziert es werden kann, mehrere Filialen zu verwalten – das ist Ihre Aufgabe.

Stellen Sie sicher, dass Sie ein Versionsverwaltungssystem verwenden, das Verzweigungen und Zusammenführungen unterstützt (ich habe Erfahrung mit Perforce und SVN, und obwohl Perforce besser ist, ist SVN kostenlos).

Ich glaube auch, dass die regelmäßige Durchführung der Zusammenführungen durch eine einzige Person gewährleistet werden kann, die für die konsistente Durchführung der Zusammenführungen verantwortlich ist.Im Allgemeinen war es ich oder einer der leitenden Leute in unserem Team.

Answer 6

Die Art und Weise, wie wir bei meiner Arbeit damit umgehen, besteht darin, den Trunk-Zweig als modernsten Code beizubehalten (dh in diesem Fall 2.0).Sie erstellen einen Zweig für den 1.x-Code und nehmen dort alle Korrekturen vor.Alle Änderungen an 1.x sollten (ggf. manuell) im Trunk-Zweig (2.0) zusammengeführt werden.

Ich würde dann darauf bestehen, dass 1.x-Entwickler sowohl die Revisionsnummer für den 1.x-Commit als auch die Revisionsnummer für die 2.0-Merge im Ticket für diesen Fehler notieren.Auf diese Weise fällt es leichter auf, wenn jemand vergisst, seine Änderungen zusammenzuführen, und die Tatsache, dass er den Überblick behalten muss, hilft ihm, sich daran zu erinnern.

Answer 7

Ein wichtiger Punkt ist darin festgehalten Dieses Bild von The Build Doctor:nur in eine Richtung zusammenführen.

Answer 8

Um diese spezielle Frage zu beantworten, sind viele Entwickler von Subversion auf Git umgestiegen.Kasse github.com.