Mein Team bei der Arbeit startet ein neues Projekt und verwendet Subversion als unser VCS (Sie können dieses Set für die Zwecke dieser Frage in Stein gemeißelt betrachten). Wir befinden uns noch in der Anfangsphase des Projekts und versuchen, uns auf ein Verzweigungsmodell zu einigen. Unser vorheriges Projekt basierte auf einem nicht standardmäßigen Versionsmodell, das zu Problemen bei der Verwaltung von Hotfixes und Patches für vorhandene Releases führte.
Ich habe festgestellt, dass verschiedene Verzweigungsmodelle ziemlich kompliziert sind, aber ein Modell, das ich ziemlich klar verstehe, ist Git Flow . Ich bin gespannt, wie schwer / unerwünscht es wäre, eine Variation davon in Subversion zu implementieren. Offensichtlich würde es einen Unterschied in Bezug auf die Mitarbeiter in Zweigstellen geben. Die Feature-Zweige müssten zentralisiert und nicht auf lokale Repositorys beschränkt werden, aber die anderen Konzepte des Modells sollten nach meinem Verständnis in Subversion reproduzierbar sein.
Was wären die Nachteile oder Herausforderungen dieses Ansatzes? Was ich gehört habe ist, dass in SVN "Zusammenführen teuer ist" im Vergleich zu Git. Ich bin mir jedoch nicht ganz sicher, was dies in der Praxis bedeutet oder wie sich dies auf unsere Fähigkeit auswirken würde, ein Git-Flow-ähnliches Verzweigungsmodell zu verwenden.
Was wäre das größte Problem bei diesem Ansatz? Gibt es einen ähnlich klaren Ansatz, der in Subversion natürlicher ist?