Перешкоди використанню Git Flow в Subversion

Моя команда на роботі починає новий проект, використовуючи Subversion як наш VCS (ви можете розглянути цей набір з каменю для цілей цього питання). Ми ще на ранніх стадіях проекту і намагаємося домовитись про модель розгалуження. Наш попередній проект базувався на нестандартній моделі версії, яка спричинила проблеми під час управління гарячими виправленнями та виправленнями існуючих версій.

Я знайшов різні моделі розгалуження досить складними, але одна модель, яку я досить чітко розумію, - це git flow . Мені цікаво, як важко / небажано було б реалізувати варіацію цього в Subversion. Очевидно, була б якась різниця у співпраці людей у ​​галузях. Гілки функцій повинні бути централізованими, а не обмежуватися локальними сховищами, але інші поняття моделі повинні бути відтворені в Subversion, наскільки я це розумію.

Які б були недоліки чи проблеми цього підходу. Я чув, що у SVN "злиття дорого" щодо Git. Але мені не зовсім зрозуміло, що це означає на практиці чи як це може вплинути на нашу здатність використовувати git flow, як модель розгалуження.

Які найбільші проблеми стосуються цього підходу. Чи існує аналогічно чіткий підхід, більш природний для Subversion?

Gitflow ґрунтується на кращих практиках версії та розгалуження вихідного коду. Дуже хороша стаття щодо цього - розширені стратегії розгалуження SCM

Ванс, який вказує Венс у пов'язаній статті, полягає в тому, що різні галузі мають різні ролі . Він визначає ролі:

1. Основна лінія (всі відділення звідси)
2. Розвиток (там, де проводиться робота по розробці)
3. Технічне обслуговування (там, де проводяться роботи з обслуговування)
4. Накопичення (об'єднання речей під час підготовки до випуску)
5. Упаковка (упаковка збірки для випуску)

У gitflow це:

1. Розвивайте
2. особливості гілок
3. Виправлення гілок
4. Випустіть гілки
5. Майстер

Стаття про розгалуження була написана на увазі Перфорса. Perforce - це централізований VCS, як і svn. Шаблони розгалуження, які він описує, ідеально відображають на svn.

Ключовим моментом є те, що його полягає не в тому, як gitflow переноситься на svn, а в тому, як застосовувати однакові фундаментальні концепції розгалуження та ролі гілок до різних структур VCS.

Я настійно рекомендую прочитати статтю, я не можу зробити їй велику суму. Те, як описано все там, базується на філософії побудови магістралі / магістралі, до якої вам легко знайти карту svn.