寻求关于CM METHODOLOGY与SVN小项目开发的建议

Question

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

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

我想到的是：

• 每个开发者开始他的私人开发分支
• 完成时，它被合并集成分支。整合部门进一步稳定。
• 当整合完成后，它被合并到中继线并被标记。

我是不清楚的：

• ，我们应该在这之后开始从树干一个新的专用 ，或保持 在同一个私人 开发分支的工作？
• 我看到，svn有特殊的行为 重新集成时 特别是在中继。有 特殊集成分支的好处（或缺点）吗？

非常感谢。

Answer 1

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

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

典型的Subversion使用情况是所有开发人员在下一个版本中工作的路径。例如，您可以创建分支来为bug修复版本，实验性功能和长期运行的开发任务等单独进行并行开发。我们都知道所有场景都不是典型的，每个团队的需求都是独一无二的，但是直到我知道为什么你需要私人开发者分支机构时，我会不同意他们需要他们，并且他们会给团队，流程和服务增加不必要的负担工具配置。

Answer 2

如果需要的话，我将只从具有维护分支的树干分支开始。这通常是一个很好的默认值。这将产生惊人的少数冲突，并将推动发展朝着“经常进行小改变”这是一件好事。我已经体验了这个与1-10个开发人员的团队规模，它的工作原理。这在Subversion文档中被称为"release branches"。

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

对每个开发者都有一个分支需要你进行大量的合并，他们会很痛苦。

---

要回答你的两个不清楚的一点：你一定要做出一个新的特性分支从树干开始你已经集成了功能分支后回主干。 Subversion docs建议停止使用旧分支。

在Subversion 1.5中，一旦从分支到树干完成了重新合并，分支不再可用于进一步的工作。它无法正确吸收新的行李箱变化，也不能正确地重新集成到行李箱中。从树干出于这个原因，如果你要保持你的特性分支工作，我们建议摧毁它，然后重新创建它：

但是没有什么特别之处主干分支，它是正常的以各种方式分支。它只是与其他分支有不同的名称。因此没有特别的重新整合到中继线。 Subversion的文档谈论--reintegrate操作，但它指的是以下情况：

1. 你有支路A（在很多情况下，这将是主干）
2. 你让一个新的支路B从分支
3. 您修改支路B并且还可能支路A
4. 您合并或重新整合从分支B到分支A的更改。