每到一个阶段性的时刻，总会发生提交风暴。平时大家默默地做，一个礼拜也提交不上一次，但这个时候SVN中在一天内能长出二三十个版本。
这种提交风暴给组内的几个人协同带来了不大不小的问题，尤其是图形绘制引擎这种相对紧耦合的系统。CullVisitor是被修改最多的类，同时有三四个人修改这个类，就使刚刚调试成功以后，马上又不work了，因为被别人改了。
虽然我不断跟大家说一定要先全部update一下，然后检查conflicted的文件，再修改，再提交，但是大家还是习惯于在自己的机器上保存一个自己
的版本，每次只提交个别修改的cpp或h文件，并且一段时间以后难于说清楚自己到底跟SVN上的版本有什么不同。在这样的情况下，经常会发生在一个人自己
那里编译运行没有问题，但是换一个人就不work。这里尤其不提交的是vcproj文件，这里包含的添加文件、编译选项都无法带到另外一个人，再加上一些
路径、配置文件、dependencies等等的问题，编译不通变成了一个见惯不怪的问题。
使用SVN进行配置管理本来是一件挺容易的事儿，但现在需要总结一些经验了：
1，每个人都需要在代码顶层目录先update全部，然后检查conflicted,然后在本地修改，编译，运行，没有问题了立刻提交。
2，提交的时候要在顶层目录提交，并且切忌也不看一看哪些文件要add，哪些文件不该修改的直接点commit。顶层提交意味着包含vcproj和sln文件一并提交，这被验证是稳妥的方式。
3，关于目录的组织，在编译环境里边尽量设置相对的路径，把配置文件目录、bin目录、模型目录和vcbuild目录尽早的组织好，全组的人按照统一的方式来办会随着项目的开发进度推进和代码的累积减少低效的工作，这可能就是需要所谓的配置管理的原因吧。
4，不要等全部都做完再提交，应该给自己的工作设定若干个时间点，每个时间点到来的时候要出来一个可编译运行的版本，虽然不一定完善，但这样做可以与别人
的工作保持协同，别人会注意到你的修改，否则大家都默默地做自己的事情，到提交的时候冲突太大，有时候很难读懂别人代码的意思，问题就麻烦了。早发现问
题，早沟通，早解决。