最近必须解决Version Control的问题了，目前使用的svn，并采用主干活跃，分支稳定的开发策略（平时的修改都在trunk进行，主干版本发布后需要修改bug才创建分支，并在分支工作，完成后merge主干），目前发现和想到的问题有以下几点：

1. 版本库过大导致检出代码太慢（3个月过去有7000+版本，检出一次50GB）；
2. 平时工作代码的提交都在主干进行，所以主干必须能够编译，由此引出以下问题：
   • 复杂的模块儿完成时间较久，成员很久都不提交，并且提交后这段时间没有自己的修改历史日志；
   • 成员机器的硬盘在这个长时间有可能挂掉，导致工作成果丢失的风险；
3. 成员之间交换工作成果通过svn在主干进行，违背了主干 必须能编译，并导致大量的垃圾提交。

针对以上问题目前想到的解决方法：

1. 改用分布式版本控制工具，Mercurial和GIT，准备分别试一下；
2. 充分利用分布式管理工具创建分支容易，速度快的特点：
   • 每个人都创建属于自己的分支，平时的工作都在分支上进行，并定期（阶段成果完成后）向主干合并
   • 自己的修改每步都可以commit到本地，每天push一次
3. 分离美术和程序的svn目录：美术的svn目录定期干掉头1000版本。

做到以上几点后，所有提出的几点问题都应该迎刃而解。这样每个人接到工作任务后的操作顺序是以下几步：

1. 创建属于自己的分支，可以按季度创建；
2. 平时的工作都在此分支上进行，同时自己的每步重大修改都commit；
3. 2天或3天视工作进度和其他人对你工作部分代码的需求而push到远程库；或者在放假前需要对代码做备份防止硬盘挂掉，也push分支工作成果到远程库；
4. 任务完成后，测试通过后，从分支merge到主干；
5. 新季度开始，回到操作1。

完成，临睡觉前粗糙的想了一下，应该还有很多不足之处，希望看见的兄弟多指正。

Tagged with: git • Mercurial • subversion • VersionControl • 源代码 • 项目管理