svn - 颠覆标签和分支

Question

有没有人想出比通常推荐的更好的技术来管理颠覆中的标签和分支（称为“标签”和“分支”的并行目录）？

Answer 1

我们使用“主干、标签、分支和流”策略。

“主干”是应该放置生产中的最新版本的地方。

“标签”是在流完成时发生“复制到”的地方，我们需要存储流的状态以用于存档目的。它还允许开发从特定点继续。

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

“流”是我们最常用的。开发流是基于任务的焦点，例如特定修复或开发工作的流（例如，更改请求的完成）。允许流相互合并，但不同的流根据 svn 策略进行排序。例如，我们有一个用于 cr 版本的流，另一个用于推出应用程序支持版本的流。由于 CR 流除了自己的更改之外还必须包含应用程序支持修复，因此它的排名更高。排名较高的流将较低的流（根据需要）合并到其中。最后，流变为生产就绪。它被标记，然后“复制到”主干，然后将其用作（通常，尽管有时使用标签）作为进一步流的基础。

然而，流的最佳用途是用于完成不到两周的短期任务。这些流可以快速合并为多个更高级别的流，然后再合并到任何其他更高级别的流中。例如，由于应用程序支持低于 cr，任何应用程序支持快速修复都可以复制到流中，然后进行处理，合并到应用程序支持，然后再合并到 cr 流中。

Answer 2

使用存储库命名空间来传达分支/标签/等信息，本质上是 SVN 模型；如果您想要的是不同的模型，那么您可能真的想要 SVN 以外的东西。

SVN 中缺少像 CVS 样式标签这样的元数据是一个有意的设计决定。无论您在树中选择什么样的分支/标签/项目排列，都将减少为用于每个目的的并行目录集。剩下的就是为你的分支和标签选择正确的命名策略，让你更清楚。

我喜欢的一个约定是完全重量级分支和轻量级“树枝”之间的分离。我工作的小组的惯例是长期开发在一个分支中进行，并且发布工程师必须了解每个分支并对其部分负责，但是任何工程师都可以创建一个短期树枝作为暂存空间对于一个太大而无法放入一次签入但又不足以需要发布工程支持的问题。这里的 Twigs 存在于与分支类似的单独的并行“twigs”目录中，命名约定通常包含创建者的用户 ID 和 twig 打算在其中解决的问题的错误 ID 号。

Answer 3

除了在拥有分支时拥有并行目录之外，您唯一可以做的另一件事是，只要您想在其中一个分支上工作，就在两个分支之间进行 SVN 切换。也许你应该澄清你想在这个系统上“更好”什么，人们可以提出建议。