Ich habe weiter im Trunk gearbeitet, als ich einen Zweig für einige wichtige Änderungen hätte erstellen sollen (Subversion, TortoiseSVN)

Ich empfehle, jedes Mal einen Versionszweig zu erstellen, wenn Sie Release-Kandidaten erstellen. Trunk bleibt live für die Arbeit an Dingen, die nicht in der Veröffentlichung sind (Version .next wie wir sagen). Der Release-Zweig ist nur für Fehlerkorrekturen und solche Sachen reserviert, die in der Veröffentlichung enthalten sein müssen. Es ist eine gute Übung, diese immer zuerst an den Stamm zu übergeben, und dann mit der Auswahl "Kirschen" in den Freigabezweig zu überführen. Versuchen Sie immer, FROM-Stamm in andere Zweige zusammenzuführen, da dies die Dinge leichter macht. Das Wiedereingliedern von "Feature Branches" in den Trunk ist in Ordnung, aber es sollte vermieden werden, einen Fehler in einem Release Branch zu beheben und ihn dann wieder in den Trunk zu integrieren.

Nachdem ein Release in der freien Wildbahn ist, wird der Release-Zweig beibehalten, um zusätzliche Bugs zu beheben und eventuell kleinere Point-Releases durchzuführen. Sie sollten die Bugs immer noch in Trunk beheben (kein Punkt, der sie in der .next-Version liefert) und sie mit jedem Release-Zweig zusammenführen, den Sie noch aktiv pflegen.

Die gute Nachricht ist, dass Sie diese Methode nach der Tat starten können. Gehen Sie zurück zur Stammversion, aus der Ihre aktuelle Version erstellt wurde, und erstellen Sie daraus einen Versionszweig. TortoiseSVN verfügt über ein praktisches Menü zum Erstellen von Tags und Zweigen aus bestimmten Revisionen, wenn Sie im Log Viewer mit der rechten Maustaste auf die Revision klicken.

Sobald Sie Ihren Release-Zweig haben, müssen Sie ihn auschecken und anfangen, die Fehlerbehebungen, die Sie veröffentlichen möchten, zusammenzuführen. Alle deine neuen Arbeiten im Kofferraum bleiben genau dort, wo sie sind. Wenn trunk und release branch stark divergiert haben, müssen Sie die Korrekturen vielleicht direkt im release-Zweig vornehmen, aber versuchen Sie, sie im trunk zu erstellen und mit dem release-Zweig zu verschmelzen, wenn Sie können.

Noch eine Sache. Jedes Mal, wenn Sie ein Release aus dem Release-Zweig versenden, sollten Sie eine Kopie an Tags mit dem Versionskennzeichen des Releases anlegen. Es kann später nützlich sein, herauszufinden, was sich zwischen den Releases geändert hat, oder, wenn nötig, ein altes Release neu zu erstellen. Wir gehen bis zum Versand des Releases sogar einen kompletten Build vom Tag aus, da wir die SVN-Revisionsnummer in unsere Produktversion einbetten. Wenn ein Kunde einen Fehler meldet, wissen wir genau, welchen Code er ausführt (da SVN-Revisionen einzigartig sind) über das Repository).

Hoffe, dass hilft und viel Glück.

Ein Ansatz besteht darin, für jede Hauptversion eine Verzweigung zu erstellen, auf der Sie Fehlerkorrekturen unabhängig von allen im Stamm ausgeführten Aufgaben anwenden können.

Um die Verzweigung nachträglich zu erstellen, versuchen Sie:

@1101 ist eine Peg-Revision - im Wesentlichen sagen wir: "Finde heraus, auf welche trunk in Revision 1101 Bezug genommen wurde, dann kopiere das, um eine Verzweigung zu erstellen."

(Das SVN-Buch hat eine unheimliche Erklärung von Peg-Revisionen, wenn du fühlst dich mutig)

Nun, es ist ein bisschen durcheinander, egal wie man es betrachtet, aber Sie haben auch nichts offen falsch gemacht. Sie haben einfach in Ihrem Stamm weiter entwickelt - was korrekt ist - aber jetzt müssen Sie zu einer vorherigen Revision zurückkehren und einige der Änderungen hinzufügen und dann erneut veröffentlichen.

Das Problem scheint so zu sein, als ob Sie eine Reihe von Revisionen mit Fehlerbehebungen und neuen Funktionen haben und Sie versuchen, die Fehler seit einem bestimmten Zeitpunkt zu beheben und alles andere zu ignorieren. Es wäre ein wenig einfacher, wenn die Fehlerbehebungen in diskreten Revisionen vorgenommen würden (zumindest zu Identifikationszwecken), aber oft begleiten sie andere Änderungen.

Zwei Optionen:

1. Nimm einen Zweig der letzten Revision, die du freigegeben hast, und gehe dann manuell über deine Fehlerkorrekturen.
2. Nimm einen Zweig der letzten Revision, der einen Bugfix hatte, dann entferne die neuen Features.

Abhängig von der Ausgewogenheit zwischen neuen Funktionen und Fehlerbehebungen ist eine dieser Funktionen wahrscheinlich einfacher als die andere. So oder so, Sie möchten gerade für diese Version mit einem Zweig enden.

Eine Möglichkeit, dies zu beheben, ist

• mache einen funktionierenden Zweig von HEAD of trunk
• Stamm löschen
• Erstellen Sie Stamm aus der Stammrevision vor Ihren versehentlichen Änderungen

Auf diese Weise sehen Sie nicht die zufälligen Commits und Reversions im Log / Tadel auf den Stamm. Aber Vorsicht beim Aktualisieren von Arbeitskopien - ich bin mir nicht sicher, wie gut svn update das Löschen und Wiederherstellen eines Repository-Standorts behandelt.