從工作至今，一直使用 svn管理軟體版本。其中碰到的一些問題和坑，分享一下。
存在的現象，
1）提交版本的說明一般是簡短的一句話，例：修復bug，增加某某功能。
究竟修改了什麼bug，增加了什麼功能
2）模組完成後，提交移植模組的**到主幹版本上面。
大型模組**的移植可能需要幾天、周。
其中模組依賴的變數，邏輯可能變化。
模組本身也需要存檔。
3）多人對同乙個工程的**管理，公共部分**修改未全部通知搭檔
公共部分**的修改，**上傳需要review，確保相關同事的**、邏輯不受影響，防止新bug引入。
4）svn down 下來的**需要額外的去配置，尋找專案依賴的庫檔案
目標：svn down下來的**是可編譯的，對應依賴庫的版本同步上傳。
使用心得：
1）單一功能增加應該提交svn。
理想狀態
2）svn 提交日誌詳細描述。
例：【bug】修復某某bug，修改某某東西....。【功能】新增某某模組的某某。【版本 v1.0.0.0】版本號對應的相應版本的**。
3）不擅自修改責任模組之外的**。
碰到模組之外的bug，更好的idea，和同事討論改之，如果是公共**，告知所有可能使用它的同事。
4）發布的穩定版本很可能不是svn最新的版本。
穩定軟體版本的**是落後於最新的svn版本。新增的**、功能需要測試後，變成發布的穩定版本。
版本定位：1，對應的版本號。在svn 上拉出發布的版本，（更希望的方式）
2，對發布的版本單獨進行提交，且說明。（僅僅跟蹤作用）
所有開發人員統一思想，去維護svn**。避免區域性個人的**影響整個軟體。
使用SVN管理軟體版本，解決協作問題
size medium 聽大家說，svn現在用得很廣，所以就先下手研究它了。昨天剛開了公司裡研發部門第一次會議，很快就有了幾個專案要做，雖然有乙個辦公室，而且很快就可以入住了，但是平時協作開發過程中，來回的copy也不是個好辦法，所以就準備用svn來管理。接下來就沒有什麼問題了，很快就裝好了，然後，...
專案管理的一些工具軟體集合
1 msp 單機版 msp的功能很多，實際上我主要用來做wbs 工作分解結構 採用的任務管理方式還是工期型，即通過開始結束時間來定義任務。對於大的專案，如果專案組織分層管理，則我的專案計畫中只分解到小組任務的粒度，各小組長自己使用msp或者excel來做更細粒度的任務分解。這些檔案一般例行每週更新並...
如何管理軟體開發專案？一些實踐原則！
在軟體開發的過程，如下的15條實踐比較經濟實用 1 控制專案組的團隊規模 不超過10人 人員要少而精。2 需求文件化 無論大小專案必須清晰的描述需求。3 採用 用例 介面原型描述需求 採用這2種手段強制使 需求描述 的完備而清晰。4 專案的階段計畫與2周計畫，階段計畫 定義總體承諾，2周計畫定 義近...