在Subversion中使用Git Flow的障碍

我的工作团队正在使用Subversion作为我们的VCS来启动一个新项目（出于这个问题的考虑，您可以将其视为一成不变的）。我们仍处于该项目的早期阶段，并试图就分支模型达成共识。我们之前的项目基于非标准版本模型，该模型导致管理现有版本的修补程序和修补程序时出现问题。

我发现不同的分支模型相当复杂，但是我确实很清楚地理解的一种模型是git flow。我很好奇在Subversion中实现这种变化会有多么困难/不期望。显然，在分支机构上进行协作的人会有所不同。功能分支必须集中而不是局限于本地存储库，但是据我所知，该模型的其他概念应该可以在Subversion中重现。

这种方法的缺点或挑战是什么？我听说相对于Git，在SVN中“合并成本很高”。但是我尚不清楚这在实践中意味着什么，或者它将如何影响我们使用像分支模型这样的git flow的能力。

这种方法最大的担忧是什么。有没有一种类似的清晰方法在Subversion中更自然？

Gitflow基于源代码版本控制和分支的最佳实践。关于此的非常好的文章是高级SCM分支策略

万斯在链接文章中提出的观点是，不同的分支机构具有不同的作用。他确定了以下角色：

1. 主线（从这里开始的所有分支）
2. 开发（完成开发工作）
3. 维护（完成维护工作）
4. 积累（为发布做好准备）
5. 打包（打包发布的内部版本）

在gitflow中，这些是：

1. 发展
2. 功能分支
3. 修补程序分支
4. 发布分支
5. 主

关于分支的文章是在考虑Perforce的情况下编写的。Perforce是一个集中化的VCS，就像svn一样。他所描述的分支模式完美地映射到了svn。

实现的关键在于，它不是将gitflow移植到s​​vn，而是如何将分支的相同基本概念以及分支的角色应用于不同的VCS结构。

我强烈建议您阅读这篇文章，我对此没有多大贡献。其中的描述方式基于主干/主干构建原则，您会发现将svn轻松映射至该主干/主干构建原则。