有没有人提出一种更好的技术来管理subversion中的标签和分支，而不是通常推荐的（并行目录称为'tags'和'branches'）？
答案 0 :(得分：3)
使用存储库命名空间传递分支/标签等信息基本上是SVN模型;如果你想要的是一个不同的模型，你可能真的想要除了SVN以外的东西。
SVN中缺少像CVS样式标签这样的元数据是一个有意的设计决策。无论您在树中选择什么样的分支/标签/项目，都会为每个目的减少到并行目录集。剩下的就是为您的分支和标签选择正确的命名策略，以便让您更清楚。
我喜欢的一个惯例是全重量级分支和轻量级“树枝”之间的分离。我工作的小组中的约定是长期开发在一个分支中，并且发布工程师必须知道每个分支并且对每个分支负部分，但是任何工程师都可以创建一个短暂的枝条用作临时空间对于一个太大而无法容纳一个签入但问题不足以要求发布工程支持的问题。这里的树枝生活在一个单独的平行'twigs'目录，类似于分支，命名约定通常有创建者的用户ID和树枝打算在其中解决的问题的错误ID号。
答案 1 :(得分：3)
我们使用“主干，标签，分支和流”策略。
“主干”是应该放置生产中的最新版本的地方。
“标记”是当流完成时发生“复制到”的地方，我们需要存储流的状态以用于存档目的。它还允许从特定点继续开发。
“分支”是指与主流发展完全不同的东西。通常，分支机构非常罕见。
“Streams”是我们最常用的。开发流是基于任务的焦点，例如用于特定修复或开发工作的流（例如，变更请求的完成）。允许流彼此合并，但是基于svn策略对不同的流进行排名。例如，我们有一个用于cr版本的流，另一个用于推出app支持版本的流。由于CR流除了自己的更改之外还必须包含应用程序支持修复程序，因此排名更高。排名较高的流将较低的流（根据需要）合并到它们中。最后，流变为生产就绪。它被标记，然后“复制到”主干，然后使用（通常，虽然有时使用标签）作为进一步流的基础。
然而，流的最佳用途是用于完成不到两周的短期任务。这些流可以快速合并到多个排名较高的流中，然后将其合并到任何其他更高排名的流中。例如，由于应用支持低于cr，任何应用支持快速修复都可以复制到流然后继续工作，合并到app支持，然后将其合并到cr流。
答案 2 :(得分：0)
除了拥有Branches之外，除了拥有并行目录之外，唯一可以做的就是在两个分支之间进行SVN切换，只要你想在其中一个上工作。也许你应该澄清你想要对这个系统“更好”的东西，人们可以提出建议。