tldr;我团队的SVN分支策略并没有重新投入后备箱。这感觉就像是一个反模式，我无法立即解释原因。这是一个问题，这些问题是否足够大以推动变革？
详细信息 -
我团队达成的分支策略是创建每月发行分支。将.EAR文件交给另一个团队以部署的方式来处理版本，而不是将其指向我们的SVN存储库。
我们在生产每个分支之前先保留最后一个提交的标签，以供以后使用。我们每天都在开发环境中建立捕捉破碎的建筑物。
但是，当我们为下一个版本创建一个分支时，我们将从现有版本分支分支 - 从不回到或与中继线交互。分支后的分支后释放的任何后更改都合并到先前的版本最终确定为止。
。Trunk
|
| April
|
| May
.
. June...
.
.
我们已经在项目分支机构上遇到了问题，这些分支已合并为预计将推出的版本。
我们不使用特征分支，因此从发行版中滚回或删除更改是一个麻烦，因为每个版本分支既是开发部门和错误修复分支。
>除此之外，是否有基本的SVN功能受到该分支策略的影响，对存储库的影响或其他风险？
正如您所说的，我可以想象'向后滚动或从发行版中删除更改是令人讨厌的'，但仍然可行。
当您使用此SVN设置聘请新的新开发人员时，您将失去宝贵的时间。他们将为这个存储库学习，贡献和故障排除。就像具有可读代码重要的方式一样，拥有可读的存储库很重要。
如果您的团队遇到了存储库的问题，则很难从书籍，网站和其他人那里寻求外部建议。
如果您想将任何类型的第三方软件合并到您的存储库中，则可能很难，因为使用中继线的SVN约定已被忽略。
您的存储库组织似乎尴尬地受到每月节奏的限制。如果您需要在一个月内进行两个代码卷怎么办？您会创建半个月的分支机构吗？
您的团队缺少SVN标签的概念。标签是最终确定的版本，不需要编辑。这些标签通常具有版本号，例如Application-1.2.3。版本号是整数的三联体：major.minor.patch。这表明了开发人员应用程序的变化的大小，以及一个版本与另一个版本有何不同。
看这本在线书，我发现它很有用：
http://svnbook.red-bean.com/en/1.8/svn.basic.html