Ok, lassen Sie mich das Szenario überprüfen - ich nehme an, Sie versuchen, die Entwickler vollständig vom Stamm zu isolieren, damit niemand direkt in den Stamm überträgt. Ich nehme an, dass Ihre Plattform diese Zweige automatisch erstellt und die Entwickler irgendwann sagen können, dass sie mit dem Zweig fertig sind und ihn wieder einbinden lassen. Der Code folgt also dem Zyklus:
- Zweigstelle
- bearbeiten
- Zur Verzweigung verpflichten
- Zweig vom Stamm umbinden
- Update Kofferraum-WC
- Wiedereingliederung der Abzweigung zum Stamm-WC
- Commit-Stamm wc
Ich bin eigentlich dafür, wenn ihr so arbeiten wollt, großartig.
Ich kann mir keinen Grund vorstellen, warum es komplett versagen sollte, aber Sie müssen folgende Dinge überprüfen:
- Kein Code darf jemals eingecheckt werden, ohne dass ein Entwickler ihn sich vorher angesehen hat.
- Fehler werden immer auf Trunk auftreten, und Entwickler brauchen vielleicht irgendwann eine Möglichkeit, direkt auf Trunk zu hacken.
- Selbst wenn es keine Merges gibt, kann die Reintegration subtile Fehler einführen, wenn der Entwickler nicht auf den neuesten Trunk zurückgreift.
Punkt 1 ist der wichtigste. Das bedeutet, dass die Wiedereingliederung, wenn sie denn stattfindet, tatsächlich ein No-op sein muss. Wenn in Ihrem 2.2-Schritt irgendeine Art von Zusammenführung stattfindet, würde ich sagen, dass Sie debe den Commit verwerfen und den Entwickler dazu bringen, erneut vom Stamm zu erstellen. Selbst wenn svn sagt, dass die Zusammenführung erfolgreich und konfliktfrei war, kann man sich nicht darauf verlassen, dass es das Richtige getan hat, um es zu löschen und zu vergessen. Wenn Sie automatisieren wollen, garantieren Sie, dass das, was der Entwickler committed hat, auch zusammengeführt wird, und nicht irgendein automatisch erzeugter Hybrid. Sie können überprüfen, ob die Zusammenführung "sauber" war, indem Sie sich die Ausgabe der Zusammenführung ansehen - wenn eine der Dateien "zusammengeführt" wurde, gibt es ein Problem. Wenn sie nur aktualisiert wurden, ist alles in Ordnung.
Punkt 3 ist interessant, aber immer ein Problem, auch bei normaler Arbeit. In diesem Szenario würde Entwickler A sagen, dass er fertig ist, seine Arbeitskopie neu aufsetzen und dann eine Weile damit verbringen, zu überprüfen, ob alles in Ordnung ist. In der Zwischenzeit schleicht Entwickler B ein Update in den Stamm ein. Entwickler A entscheidet, dass alles in Ordnung ist und integriert erneut. Die von Entwickler B vorgenommenen Änderungen führen jedoch dazu, dass der Code nicht mehr funktioniert, obwohl er keine der von Entwickler A geänderten Dateien berührt hat.
Es wird davon ausgegangen, dass Entwickler A das Problem entdeckt hätte, wenn er die Änderungen von Entwickler B berücksichtigt hätte. Ihre Plattform hat die Möglichkeit, diese Situation zu erkennen (z.B. wenn svn-merginfo sagt, dass es Stammrevisionen gibt, die in den Zweig übertragen werden können, dann ist sie nicht auf dem neuesten Stand). Ich würde aber auch davor warnen, einen ewigen Merge-Zyklus zu schaffen, wo es nicht notwendig ist. Vielleicht sollte man den Entwicklern eine Warnung geben, dass ein Commit gemacht wurde, seit sie re-basiert haben, aber ihnen erlauben, trotzdem weiterzumachen.
Eine letzte Anmerkung: Ich habe oben die Verwendung von svn-mergeinfo erwähnt. Sie können sich nicht darauf verlassen, dass ein re-integrate merge in Ordnung ist. Wenn Sie das tun, gibt es eine Wettlaufsituation zwischen der Überprüfung und dem Commit der Zusammenführung - jemand könnte in der Zwischenzeit eingedrungen sein. Sie müssen immer noch die Ausgabe des eigentlichen Zusammenführungsbefehls überprüfen, um zu sehen, was wirklich passiert ist.
Seien Sie sich auch der Situation bewusst, wenn mehrere Entwickler gleichzeitig versuchen, das System neu zu integrieren. Wenn Sie jedes Mal eine neue Arbeitskopie auschecken, können Sie so viele haben, wie Sie wollen, aber die Übertragungen können mit dem alten Fehler "Datei ist veraltet" fehlschlagen. Auch in diesem Fall wird die erneute Integration fehlschlagen und Sie müssen die Entwickler dazu bringen, ihre Zweige neu zu basieren.
Alles in allem gefällt es mir. Es ist ein bisschen kompliziert, aber das ist ja der Sinn eines solchen Systems - es kümmert sich um die komplexen Dinge, damit die Entwickler es nicht tun müssen. Alles, was sie tun müssen, ist, ihre Zweige so lange neu zu basen, bis das System eine erfolgreiche Reintegration ermöglicht.
