什么时候用 subversion 创建一个新的 branch/tag？
When to create a new branch/tag with subversion?
我们正在使用 Subversion 开发一个 PHP 项目。到现在我们都是用主干（/trunk）开发，最后我们发布了1.0版本（先是/branch/RB-1.0，然后我们把它标记为/tag/REL-1.0）。
我的想法是将错误修复发布为 1.0.x 并将新功能发布为 1.x，仅当我们已经完成时才发布新的大版本（2.0，...）一些重要的变化。
不知道什么时候推荐做一个新的branch/tag。仅适用于主要版本 (1.0, 2.0, ...)，普通版本 (1.1, 1.2, 2.1, ...) 或错误修复 (1.0.x) ?
当我想发布错误修复时，是否建议在主干或 RB-1.0 上修复它并将其合并到 TAG-1.0 而无需创建新的 branches/tags？ Tagging/branching 肯定占用了很多不必要的 space 吧？因此版本号 (1.0.x) 不会反映在颠覆中，只会反映在我的更新日志中。
是否有关于何时branch/tag的"un-official"建议？
感谢
您不应合并到标签。做一个新标签。标签在你创建之后应该大部分是不可变的，否则它们就没有意义。你应该会说 "tag_1.0" 并确切地知道那是什么意思，并且它应该在 3 年内表示同样的意思。
不用担心 space。在服务器上，如果您在创建标签或分支时未进行任何修改，则不会为标签采用额外的 space（除了用于存储名称和一些元数据的 space）。在工作副本中，如果你检查整个存储库树——标签、分支和所有——它只会花费额外的 space，无论如何你不应该这样做。当您做 更改时，只有space 更改本身（实际更改的两三行）会占用space.
关于合并方向：我认为在SVN中通常的做法是在主干上进行修复，然后backport更改到您主动维护的所有分支。 SVN book chapter on branch patterns 讨论了这种方法。这在 SVN 中效果很好，因为 SVN 可以像完整分支合并一样容易（甚至更容易）进行精选合并，并且在合并方向上没有任何真正的优势。
其他项目，尤其是使用其他版本控制系统时，则相反。例如，Mercurial 项目（使用 Mercurial）grafts bugfixes forward from release branches 而不是从其 "default" 分支（相当于 SVN 中的主干）向后移植更改。显然，Mercurial 中的合并机制以这种方式工作得更好，但正如我所提到的，我认为 SVN 的任何一种方式都没有明显的优势。
分支策略完全取决于您，但我有点建议保留一个 1.0.x 分支和一堆 1.0.1、1.0.2 等标签。也许再次分支 1.1.x、1.2.x 等
您随时可以根据需要重新访问您的分支策略和 rename/delete 个分支。如果您需要再次查看它们，它们将始终在您的历史记录中可用。
我们正在使用 Subversion 开发一个 PHP 项目。到现在我们都是用主干（/trunk）开发，最后我们发布了1.0版本（先是/branch/RB-1.0，然后我们把它标记为/tag/REL-1.0）。
我的想法是将错误修复发布为 1.0.x 并将新功能发布为 1.x，仅当我们已经完成时才发布新的大版本（2.0，...）一些重要的变化。
不知道什么时候推荐做一个新的branch/tag。仅适用于主要版本 (1.0, 2.0, ...)，普通版本 (1.1, 1.2, 2.1, ...) 或错误修复 (1.0.x) ?
当我想发布错误修复时，是否建议在主干或 RB-1.0 上修复它并将其合并到 TAG-1.0 而无需创建新的 branches/tags？ Tagging/branching 肯定占用了很多不必要的 space 吧？因此版本号 (1.0.x) 不会反映在颠覆中，只会反映在我的更新日志中。
是否有关于何时branch/tag的"un-official"建议？
感谢
您不应合并到标签。做一个新标签。标签在你创建之后应该大部分是不可变的，否则它们就没有意义。你应该会说 "tag_1.0" 并确切地知道那是什么意思，并且它应该在 3 年内表示同样的意思。
不用担心 space。在服务器上，如果您在创建标签或分支时未进行任何修改，则不会为标签采用额外的 space（除了用于存储名称和一些元数据的 space）。在工作副本中，如果你检查整个存储库树——标签、分支和所有——它只会花费额外的 space，无论如何你不应该这样做。当您做 更改时，只有space 更改本身（实际更改的两三行）会占用space.
关于合并方向：我认为在SVN中通常的做法是在主干上进行修复，然后backport更改到您主动维护的所有分支。 SVN book chapter on branch patterns 讨论了这种方法。这在 SVN 中效果很好，因为 SVN 可以像完整分支合并一样容易（甚至更容易）进行精选合并，并且在合并方向上没有任何真正的优势。
其他项目，尤其是使用其他版本控制系统时，则相反。例如，Mercurial 项目（使用 Mercurial）grafts bugfixes forward from release branches 而不是从其 "default" 分支（相当于 SVN 中的主干）向后移植更改。显然，Mercurial 中的合并机制以这种方式工作得更好，但正如我所提到的，我认为 SVN 的任何一种方式都没有明显的优势。
分支策略完全取决于您，但我有点建议保留一个 1.0.x 分支和一堆 1.0.1、1.0.2 等标签。也许再次分支 1.1.x、1.2.x 等
您随时可以根据需要重新访问您的分支策略和 rename/delete 个分支。如果您需要再次查看它们，它们将始终在您的历史记录中可用。