Wie aktualisiere ich eine Feature -Filiale aus dem Kofferraum ordnungsgemäß?

Question

SVN -Buch sagt:

...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

Ich finde diesen Ansatz aus mehreren Gründen sehr unpraktisch in großen Entwicklungen, hauptsächlich im Zusammenhang mit dem Wiedereingliederungschritt.

1. Aus SVN v1.5 erfolgt die Zusammenführung von rev-by-rev. Das Kirschverpalten der zu verschmolzenen Bereiche würde dazu führen, dass wir die Konflikte für Kofferraum-Branch zweimal lösen (eine, wenn wir Rumpfrevisionen an die FB und noch einmal bei der Verschmelzung verschmelzen).
2. Repository -Größe: Kofferraumänderungen können für eine große Codebasis von Bedeutung sein, und das Kopieren der Differenzdateien (im Gegensatz zu SVN -Kopie) von Trunk an anderer Stelle kann ein signifikanter Overhead sein.

Stattdessen tun wir das, was wir als "Neubranche" bezeichnen. In diesem Fall wird bei einem erheblichen Teil des Kofferraumwechsels ein neuer Feature -Zweig aus dem aktuellen Kofferraum geöffnet und der Zusammenschluss immer nach unten (Feature -Zweige -> Stabile stabile Zweige). Dies geht nicht mit den SVN -Buchrichtlinien und Entwicklern betrachten es als zusätzliche Schmerzen.

Wie gehen Sie mit dieser Situation um?

Answer 1

Nach der Forschung:

Nach vielen Brainstorming -Sitzungen bei VisionMap, F2F -Diskussionen, einschließlich Artyom, Öffnen eines SVN -Buchkoffers usw. - sieht es so aus, als ob dies nicht möglich ist. Eine Feature -Niederlassung ist völlig nicht wie das Arbeitskopie. Die einzige Arbeitsweise, um es zu aktualisieren, besteht darin, wie oben beschrieben eine neue Filiale nachzubilden.

Answer 2

Aus SVN v1.5 erfolgt die Zusammenführung von rev-by-rev. Das Kirschpick der zu verschmolzenen Gebiete würde dazu führen, dass wir die Konflikte für Kofferraum-Branchen lösen zweimal (Einer bei der Verschmelzung von Rumpfrevisionen an das FB und noch einmal, wenn Sie zurückverführen)

Dann machst du etwas falsch!

Mal schauen:

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

Wenn Sie im Jahr 11-20 Änderungen vornehmen möchten, ist die Best Practice im Allgemeinen, 1-20 in FB zu verschmelzen und alles dort zu bekommen.

Wenn FB dann fertig ist, verschmelzen Sie 20-30 und dann Kopieren FB zum Kofferraum (keine Zusammenführung!).

Wenn Sie sich entscheiden, nur R11: 20, OK zu verschmelzen, müssen Sie am Ende R1: 10 und R20: 30 und dann zusammenführen Kopieren FB zum Kofferraum.

Es gibt keine Möglichkeit, Änderungen zweimal zusammenzuführen!

Ich gehe davon aus, dass Sie wahrscheinlich folgen:

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

Sie können dies nicht tun, weil Sie 11:20 zweimal zusammenführen würden. Sie sollten immer nur Code in eine Richtung zusammenführen.

Der richtige Weg:

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

Bearbeiten

Die richtigen Schritte sind also:

1. Erstellen Sie Feature Branch (FB) aus dem Trunk (Kopieren Sie den Kofferraum, um Zweig mit SVN-Copy zu finden).

   FB_0=trunk_0
   

2. Arbeit an FB.

   FB_1=FB_0 + change_a
   

3. Führen Sie alle bevorstehenden Änderungen von Trunk zu FB zusammen.

   trunk_1=trunk_0 + tr_change_a;
   FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a
   

4. Arbeit an FB

   FB_3 = FB_2 + change_b
   

5. Fusion alle bevorstehend Unvergeeinigte Änderungen Von Koffer nach FB.

   trunk_2=trunk_1 + tr_change_n;
   FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b
   

6. Zu diesem Zeitpunkt haben wir einen Feature -Zweig, aus dem bestehen alle Neue Funktionen undalle Änderungen im Kofferraum. Wir kopieren also nur den Unterschied zwischen zwei Zweigen.

   trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b
   

   Jetzt hat FB gelöscht, als Trunk alle Änderungen hat, die wir benötigen.

   Der letzte Schritt wird ausgeführt von:

   svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
   svn ci
   

   Oder in gewöhnlicher Sprache einen Unterschied zwischen Kofferraum und Zweig und bringen Sie sie in den Kofferraum und machen sie gleichwertig.

Dieses Muster wird in beschrieben http://svnbook.red-tean.com/en/1.4/svn.branchmerge.commonus.html#svn.branchmerge.commonus.patterns.Feature

Wenn dies für Sie nicht funktioniert, verstehe ich die Frage nicht.

Edit2: Für SVN-1.5

Wenn Sie mit SVN-1.5 arbeiten, können Sie viel einfacher zusammenführen:

Wenn Sie an der Feature -Niederlassung arbeiten, fusionieren Sie nur Änderungen von Kofferraum zu Zeit:

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

Es wird Ihr FB mit allen Änderungen im Kofferraum ausrichten. Am Ende von FB führen Sie diese Prozedur noch einmal aus, um sicherzustellen, dass alles auf dem neuesten Stand ist. Das du gehst zum Kofferraum und renne

$ svn merge --reintegrate /path/to/fb
$ svn ci

Im letzten sollte es keine Konflikte geben, wenn Sie wie gezeigt arbeiten.

Answer 3

Wir sind ein kleines Unternehmen, daher weiß ich nicht, ob unsere Lösung für Ihre Situation gilt. Was wir tun, ist eine Rev-by-rev, die vom Kofferraum bis zum stabilen Zweig verschmilzt. Wir können es auf 2 verschiedene Arten tun: - Wirklich benötigte Fix, wir verschmelzen kurz, nachdem wir uns für Kofferraum - gefährliche Fix/Veränderung verpflichtet haben. Wir warten einige Tage, bis die Änderung im Kofferraum geweiht ist und dann verschmelzen wir dann

Mit dieser kontinuierlichen Verschmelzung vermeiden wir Tonnen von Konflikten.

Meine 2 Cent.

Answer 4

Leider kann alles erwähnt werden als Hacks. Die Aktualisierung von Trunk in einem Zweig kann zu sehr schwerwiegenden Problemen führen, wenn sie wieder in den Kofferraum gebracht werden, und eröffnet die Möglichkeit für die schlimmsten aller Konflikte, Baumkonflikte. Dies liegt daran, dass Verzeichnisse nicht als erstklassige Bürger behandelt werden. Der beste Ansatz ist die Verwendung von Merkurial mit der SVN -Erweiterung als Standard -SVN -Client. Sie können SVN weiterhin verwenden und gleichzeitig die Kraft des Ordnerhandhabers von Mercurial erhalten.

Anschließend können Sie auf der WworkStation -Seite eine Reihe von Ansätzen verwenden, die eine Reihe von Funktionen für viele Situationen über SVNs einzelner bieten. Sie können regelmäßiges Patching, Patch -Warteschlangen, Aktualisierungen von einer lokalen Kopie von Trunk verwenden, ohne den gemeinsam genutzten Kofferraum und verschiedene andere Ansätze zu beeinflussen.

Dieser Ansatz arbeitet um alle Downn -Seiten von SVN. Ich hatte aufgrund ähnlicher Umstände auf diesen Ansatz wechseln. Auch wenn Sie diesen Ansatz nicht sofort verwenden, sollten Sie ihn zumindest so schnell wie möglich versuchen.

Answer 5

Ich denke, ich muss die Cudgels für @artyom hier aufnehmen. Ich denke auch das, wenn Sie müssen

Lösen Sie die Konflikte für Kofferraumbranch zweimal

Irgendwas stimmt nicht. Und ich denke, dass @artyoms Argument/Lösung ziemlich solide ist.

Ich glaube, eines der kleinen Dinge, die @artyom klarer hätte geschrieben haben können, ist, dass Sie am Ende "kopieren", wenn Sie "kopieren" fb zu trunk Sie verwenden nicht svn copy aber svn merge (oder svn merge --reintegrate). Dies könnte der Grund sein, warum Sie das Muster "Copy-Merge" nicht finden Gemeinsame Verzweigungsmuster.

Ich bin mir nicht sicher, was ich sonst noch sagen soll.

Hier ist was ich höre:

Stattdessen tun wir das, was wir als "Neubranche" bezeichnen. In diesem Fall wird ein neuer Feature -Zweig aus dem aktuellen Kofferraum geöffnet, wenn ein erheblicher Teil von Kofferraumwechsel erforderlich ist ...

Jetzt haben Sie einen neuen Zweig (nennen wir ihn B2), der dem Kofferraum entspricht, oder? Und wo Ist der "bedeutende Teil der Kofferveränderungen benötigt"? Ich nehme an in FB?

... und die Zusammenführung ist immer nach unten (Feature -Zweige -> Koffer -> Stabile Zweige).

Aber als Sie gerade B2 aus Trunk erstellt haben, gibt es nichts, was man sich in den Kofferraum verschmiert, nein? Und Sie verschmelzen auch keine Änderungen von B2 zu FB (da dies das gleiche wäre wie das Zusammenführen von Rumpf zu FB ...). Wie kommen die "bedeutenden Teile von Veränderungen" in FB? Und wenn sie sobald sie da sind, warum sollten Sie sie wieder zum Kofferraum verschmelzen (da sie hierher kamen)?

Eigentlich die folgenden Links Der Abschnitt mit dem Titel "Tracking fusioniert manuell" und/oder Der Abschnitt mit dem Titel "Einen Zweig zu einem anderen verschmelzen" Bereitstellung in der Dokumentation SVN 1.4 (ich weiß, Sie verwenden SVN 1.4 nicht, aber ich glaube, dass es trotzdem gilt) unter Gemeinsame Verzweigungsmuster Könnte helfen, einige Dinge zu klären. Diese Links fehlen in der 1.5 -Dokumentation (wahrscheinlich wegen der neuen --reintegrate Option in merge).

Sie scheinen wirklich zweimal die gleichen Veränderungen zu verschmelzen und ich denke wirklich, dass Sie das nicht tun sollten.