源代码控制策略

我正在寻找不同源代码控制策略的概述.我只是遇到了主线政策,并希望在与团队合作之前更好地了解其他人.

有人可以提供概述链接,甚至可以给我一些政策名称,以便我可以启动谷歌吗？

没有空提交消息.

论文"流线:并行软件开发的分支模式"是对分支模式的极好讨论,例如您提到的"主线"模式 - 它以模式的形式列出了选项以及反模式的讨论.其中一位作者是Perforce的Robert Orenstein.

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

成功检查(编译,测试,审查,FxCop'ed等)

Atomic(应该只包含一个逻辑更改,fe single bugfix,重构等)

非冗余(不应添加未使用的代码,不提交注释代码,删除它,不要意外地进行格式更改等)

正确而充分地评论

匹配当前开发阶段(例如,版本支持分支中不允许重构)

尽可能小以匹配以前的规则.

我们开发了一个简单的工具SvnCommitChecker,它帮助我们在提交到svn之前检查一些这些规则.我打算在不久的将来把它放到sourceforge上,附上一篇关于保持良好的svn变化历史的好处的文章.