有没有人比通常推荐的(并行目录称为" tags"和" branch")提出更好的技术来管理Subversion中的标签和分支？

解决方案

回答

在拥有分支机构的同时，除了拥有并行目录之外，我们还能做的另一件事是，只要我们想在一个或者另一个分支上工作，就可以在两个分支之间进行SVN切换。也许我们应该澄清一下我们希望对该系统"更好"的内容，并且人们可以提出建议。

回答

从根本上说，使用存储库名称空间来传递诸如分支/标签/等之类的信息。如果我们想要的是其他型号，则我们可能真的想要SVN以外的产品。

SVN中缺少像CVS样式标签这样的元数据是一个故意的设计决策。无论我们在树中选择哪种分支/标签/项目排列，都将减少每种用途的并行目录集。剩下的就是为分支机构和标签选择正确的命名策略，以使事情变得更加清晰。

我喜欢的一个约定是将完整的重量级分支和轻量级的"树枝"分开。我所在小组的惯例是，长期的开发工作在一个分支中进行，发布工程师必须了解每个分支并对其负部分责任，但是任何工程师都可以创建一个短暂的树枝来用作临时空间对于一个太大而无法放入一个值机的问题，但问题又不足够大，需要发布工程支持。此处的小树枝位于与分支类似的单独的并行"小树枝"目录中，命名约定通常包含创建者的用户ID和该小树枝要解决的问题的错误ID号。

回答

我们使用"主干，标签，分支和流"策略。

应该将"主干"放置在生产中的最新版本中。

当流完成时，"标签"是发生"复制到"的位置，我们需要存储流的状态以用于存档。它还允许从特定点继续开发。

"分支"是指发生与主流发展完全不同的事情。通常，分支非常罕见。

"流"是我们最常用的。开发流是基于任务的焦点，例如特定修复或者开发工作(例如，变更请求的完成)的流。允许流彼此合并，但是基于svn策略对不同的流进行排名。例如，我们有一个流用于cr发布，而另一个流则用于推出应用程序支持发布。由于CR流除了自身的更改外还必须包含应用程序支持修复程序，因此它的排名较高。排名较高的流将较低的流(根据需要)合并到其中。最终，流变为可以投入生产的状态。对其进行标记，然后"复制到"主干，然后将其用作(通常，尽管有时使用标签)主干作为其他流的基础。

但是，流的最佳用途是用于耗时不到两周的简短任务。这些流可以快速合并为多个较高级别的流，然后再将其合并到其他任何较高级别的流中。例如，由于应用程序支持低于cr，因此可以将任何应用程序支持快速修复程序复制到流中，然后进行处理，合并到应用程序支持中，然后将其合并到cr流中。