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