我正在寻找有关不同源代码控制策略的概述。我只是遇到过Main-Line政策，并且想在与团队合作之前更了解其他人。

有人可以提供指向概述的链接，甚至可以给我提供一些政策名称，以便我可以在其上启动Google吗？

解决方案

我最喜欢的策略是"没有Subversion提交不引用票证+每次提交都包含Auto Trac评论"：http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

我大量使用了《实用Perforce》一书。尽管我们可能没有使用Perforce，但我认为第7章(软件如何发展)和第8章(基本代码行管理)可能会非常有用。我们也许可以在Google图书上浏览它们。

Perforce在此主题上也有很多很棒的文章。软件生命周期建模撰写有关策略的文章。
Perforce完整的技术文档。

而且，不，我既不为Perforce工作，也不为它工作。

祝你好运，
汤玛士

没有空的提交消息。

提交每个更改而不是每个文件。

这具有以下优点：

• 我们稍后可以看到为什么在此确切的文件中更改了这一行(啊哈，这是Bug＃123的错误修复)。如果我们按文件提交，则提交消息倾向于描述文件中所做的更改-无论如何，我们都可以通过diff来查看。如果我们按更改提交，则提交消息往往会解释为什么首先要做更改。
• 还原或者合并更改/错误修正要容易得多。
• 当我们清楚地关注工作中的单个错误/功能/更改时，它有助于更​​好地组织工作。完成后就提交。

有人认为此策略产生的提交次数更多，但根据我的经验，我们毕竟获得的提交次数更少。例如，我们正在执行重构，该重构会影响50个文件。重构后，我们将执行一次带有消息"重构的xyz子系统"的提交。

对于较大的更改，我们应考虑"每更改一次开发分支机构"策略。

论文"流线：并行软件开发的分支模式"是对分支模式的精彩讨论，例如我们提到的"主线"模式，它以模式的形式列出了选项以及对反模式的讨论。作者之一是Perforce的Robert Orenstein。

不要签入/提交任何会破坏构建的更改。

我们在项目中使用一些实用规则作为提交策略。这些规则有助于我们将每个修订版本保持在准备部署状态。我们的规则类似于KDE提交策略，发布在这里：http://techbase.kde.org/Policies/SVN_Commit_Policy。
每次提交都应(从高优先级到低优先级)：

• 成功检查(编译，测试，检查，FxCop'ed等)
• 原子(应仅包含一个逻辑更改，例如单个错误修正，重构等)
• 非冗余(不应添加未使用的代码，不要提交注释的代码，不要删除它，不要意外地提交格式更改等)
• 正确且完整地评论
• 匹配当前的开发阶段(例如，版本支持分支中不允许重构)
• 尽可能小以匹配以前的规则。

我们开发了一个简单的工具SvnCommitChecker，女巫可以帮助我们在提交svn之前检查其中一些规则。我计划在不久的将来通过一篇有关保持良好的svn更改历史的好处的文章将其放在sourceforge上。

这两个基本相同：
多个敏捷团队的版本控制
配置管理分支策略

我们正在使用这种策略来使中继稳定，并使开发人员能够在分支机构上执行所需的任何操作。

Subversion存在一些问题，因为它无法处理循环合并，但是可以通过在每次重新集成到主干后删除开发分支来解决(与其他版本控制系统无关)