每到一個階段性的時刻，總會發生提交風暴。平時大家默默地做，一個禮拜也提交不上一次，但這個時候SVN中在一天內能長出二三十個版本。
這種提交風暴給組內的幾個人協同帶來了不大不小的問題，尤其是圖形繪制引擎這種相對緊耦合的系統。CullVisitor是被修改最多的類，同時有三四個人修改這個類，就使剛剛調試成功以后，馬上又不work了，因為被別人改了。
雖然我不斷跟大家說一定要先全部update一下，然后檢查conflicted的文件，再修改，再提交，但是大家還是習慣于在自己的機器上保存一個自己
的版本，每次只提交個別修改的cpp或h文件，并且一段時間以后難于說清楚自己到底跟SVN上的版本有什么不同。在這樣的情況下，經常會發生在一個人自己
那里編譯運行沒有問題，但是換一個人就不work。這里尤其不提交的是vcproj文件，這里包含的添加文件、編譯選項都無法帶到另外一個人，再加上一些
路徑、配置文件、dependencies等等的問題，編譯不通變成了一個見慣不怪的問題。
使用SVN進行配置管理本來是一件挺容易的事兒，但現在需要總結一些經驗了：
1，每個人都需要在代碼頂層目錄先update全部，然后檢查conflicted,然后在本地修改，編譯，運行，沒有問題了立刻提交。
2，提交的時候要在頂層目錄提交，并且切忌也不看一看哪些文件要add，哪些文件不該修改的直接點commit。頂層提交意味著包含vcproj和sln文件一并提交，這被驗證是穩妥的方式。
3，關于目錄的組織，在編譯環境里邊盡量設置相對的路徑，把配置文件目錄、bin目錄、模型目錄和vcbuild目錄盡早的組織好，全組的人按照統一的方式來辦會隨著項目的開發進度推進和代碼的累積減少低效的工作，這可能就是需要所謂的配置管理的原因吧。
4，不要等全部都做完再提交，應該給自己的工作設定若干個時間點，每個時間點到來的時候要出來一個可編譯運行的版本，雖然不一定完善，但這樣做可以與別人
的工作保持協同，別人會注意到你的修改，否則大家都默默地做自己的事情，到提交的時候沖突太大，有時候很難讀懂別人代碼的意思，問題就麻煩了。早發現問
題，早溝通，早解決。