我们正在使用Subversion开发一个PHP项目。到目前为止，我们正在使用trunk（/ trunk）进行开发，最后我们发布了1.0版本（首先发布到/branch/RB-1.0，然后我们将其标记为/tag/REL-1.0）。
我的想法是将错误修复程序发布为1.0.x并将新功能发布到1.x，只有在我们进行了一些重要更改时才会发布新的大版本（2.0，...）。
我不知道何时建议做新的分支/标记。只有主要版本（1.0,2.0，...），普通版本（1.1,1.2,2.1，...）或错误修复（1.0.x）？
当我想发布错误修复时，是否建议将其修复到trunk或RB-1.0并将其合并到TAG-1.0而不创建新的分支/标记？标记/分支必然会占用大量空间，不是吗？因此版本号（1.0.x）不会反映在subversion中，只会在我的更新日志中。
是否存在关于何时分支/标记的“非官方”建议？
THX
答案 0 :(得分：1)
您不应合并到代码。制作新标签。制作后，标签应该大部分是不可变的，否则它们就毫无意义。您应该能够说出“tag_1.0”并确切地知道这意味着什么，它应该在3年内意味着同样的事情。
不要担心空间。在服务器上，如果在创建标记或分支时未进行任何修改，则不会为标记占用额外空间（用于存储名称和某些元数据的空间除外）。在工作副本中，如果您检出整个存储库树标签，分支和所有内容，它将只占用额外的空间，而且您不应该这样做。当您执行进行更改时，只有更改自身的空间（实际更改的两行或三行）将占用空间。
至于合并方向：我认为SVN的通常做法是在trunk上进行修复，然后将 backport 更改为您主动维护的所有分支。 SVN book chapter on branch patterns讨论了这种方法。这在SVN中运行良好，因为SVN可以像完全分支合并一样轻松（甚至更容易）进行cherry-pick合并，并且在合并方向上没有任何真正的优势。
其他项目，尤其是使用其他版本控制系统时，反过来。例如，Mercurial项目（使用Mercurial）grafts bugfixes forward from release branches而不是从其“默认”分支（相当于SVN中的trunk）向后移植更改。显然Mercurial中的合并机制在这方面效果更好，但正如我所提到的，我不认为SVN有任何明显的优势。
分支策略完全取决于您，但我建议保留一个1.0.x分支和一堆1.0.1,1.0.2等标记。也许再次分支1.1.x，1.2.x等。
您可以随时重新访问分支策略，并根据需要重命名/删除分支。如果您需要再次查看它们，它们将始终在您的历史记录中可用。