寻求关于 SVN 小型项目开发的 CM 方法的建议

Question

我们是一家小型初创公司，从零开始。我们使用 Subversion，存储库位于基于 Web 的服务上。

我熟悉 CVS 并阅读了一些 SVN 的介绍，这没什么大不了的。我对 CM 方法论感兴趣，它将使我们能够在 CM 本身上花费最少的精力，但使我们能够顺利工作而不会发生冲突。我确信不需要重新发明轮子，我只是想证实我的想法。

我的想法是：

• 每个开发人员在完成后启动他的私有开发分支
• ，并将其合并到集成分支。集成分支上进行了进一步的稳定。
• 集成完成后，它会合并到主干并标记。

我不清楚：

• 我们是否应该开设一个新的私人分支机构 之后从后备箱取出，或者保留 从事同一个私人工作 开发分支？
• 我发现 svn 有一个特殊的行为 当重新融入时 特别是在主干上。有吗 拥有一个的好处（或缺点） 那么特殊的整合分支呢？

多谢。

Answer 1

为什么您觉得有必要在私人分支机构进行开发？您不能让您的开发人员在同一存储库路径中一起工作吗？我问这个问题的原因是根据我的经验，大多数认为他们“需要”这的人通常是错误的，并且不了解源代码管理以及 Subversion 的工作原理。我并不是在指责你，但我希望你能解释一下这个要求背后的原因，因为它可能会对未来的建议产生影响。

为了尝试回答您的问题，我可以告诉您，使用私有开发人员分支会给您的管理和工具配置增加不必要的负担。开发人员应该在同一存储库路径中一起工作，除非有充分的理由，例如使用分支、错误修复版本或实验工作。造成这种情况的原因有很多，但我首先想到的几个是开发是团队的努力、每个人的变化的可见性、开发过程的简单性、工具配置的简单性和管理的简化。

典型的 Subversion 用法使主干成为所有开发人员处理下一个版本的路径。您可以创建分支来对错误修复版本、实验性功能和长时间运行的开发任务等进行独立的并行开发。我们都知道，所有场景都不典型，每个团队的需求都是独特的，但在我知道为什么需要私有开发人员分支之前，我不同意它们的必要性，并且它们会给您的团队、流程和流程增加不必要的负担。工具配置。

Answer 2

如果需要的话，我只会从一个带有维护分支的主干分支开始。这通常是一个很好的默认值。这将产生令人惊讶的很少的冲突，并将推动发展朝着“经常进行小改变”的方向发展，这是一件好事。我在 1-10 名开发人员的团队规模中经历过这种情况，而且它确实有效。这称为 " 发布分支“ 在 Subversion 文档中。

功能分支是另一种常见的操作方式。在这里，您为每个新功能创建一个新分支，并将功能合并回主干。一名开发人员可能同时拥有多个功能分支，或者多个开发人员可能同时在同一功能分支上工作。

为每个开发人员建立一个分支需要您进行大量合并，这将是痛苦的。

---

回答你的两个不清楚的点：在将功能分支集成回主干之后，你绝对应该从主干开始创建一个新的功能分支。 Subversion 文档建议停止使用旧分支。

在 Subversion 1.5 中，一旦从分支到主干完成了 --reintegrate 合并，该分支就不再可用于进一步的工作。它无法正确吸收新的主干更改，也无法再次正确地重新集成到主干。因此，如果您想继续处理您的功能分支，我们建议您销毁它，然后从主干重新创建它：

但是 trunk 分支没有什么特别之处，它是一个普通分支在每一种时尚中。它只是与其他分支有不同的名称。因此，重新集成到主干没有什么特别的。 Subversion 文档讨论了 --reintegrate 操作，但它指的是以下情况：

1. 您有分支 A（在许多情况下，这将是主干）
2. 您从分支 A 创建一个新的分支 B
3. 您修改分支 B，也可能修改分支 A
4. 您合并或重新集成从分支 B 更改为分支 A。