從問題描述可以看出，這是採用配置管理工具（**版本控制工具）初期比較典型的問題，要解決此問題需要做以下調整：
採用成熟的主幹-分支**管理方法；
需要指定專職或兼職的人員來負責**規劃和管理，包括分支的建立和合併，通常稱為配置管理員（cmo）；
先簡單介紹一下主幹-分支**管理方法：
**庫中建立三個目錄：trunk、branches和tags，分別存放穩定**、開發**和用於生產環境的可發布**；
branches中可以有多個分支，可以按人員、用途或版本劃分，具體視公司情況而定。
通常把專案初始專案結構建立好，由cmo提交到trunk，cmo再基於trunk建立規劃好的分支。
可行的解決方案：
cmo建立以下初始目錄結構 trunk
branches
----dev
----test #br 測試人員將dev目錄下某個或某些開發人員的開發分支合併到test的某個子分支下，將**部署到功能測試環境，進行整合或系統測試。 效能測試人員將test目錄下通過整合或系統測試後的**部署到效能測試環境，進行效能 測試。 cmo將test目錄下通過效能測試的**合併到trunk。 當發布計畫中的功能都已就緒，產品發布人員可以將trunk中的**部署到生產預熱環境中進行試執行。 試執行沒有發現問題，cmo將trunk**建立乙個正式的發布分支到tags中，可以用版本號命名。 產品發布人員將tags中最新版本**部署到生產環境中。 隨著時間的推移，配置庫的目錄可能的結構如下所示。 trunk branches ----dev ----------john ----------tom ----test ---------test-20120901 ---------test-20121001 ---------test-20121101 ---------test-… tags ----release v 0.0.1 ----release v 0.1.0 ----release v 0.2.0 ----release … 功能盡可能的模組化，乙個功能不應涉及到兩個或多個模組的修改。 不在**庫中儲存專案的中間檔案、臨時檔案或因人而異的配置檔案。 做好寫許可權管理，避免不必要的誤修改操作。 回滾的操作過程如下 1 保證我們拿到的是最新 svn update 假設最新版本號是28。2 然後找出要回滾的確切版本號 svn log something 假設根據svn log日誌查出要回滾的版本號是25，此處的something可以是檔案 目錄或整個專案 如果想要更詳細的了解情況，可以使用sv... 1 從trunk或者branch 再 拉出乙個 branch 注 可以是從trunk拉分支，也可以是從branch裡邊再拉乙個分支出來。branch brancha branch branchb 分支 分支 svn cp m creat a new branch svn svn trunk bran... 專案發布上線效率低，負責投版人員痛苦 哀嚎聲一遍，糾其原因，沒有使用版本管控 當乙個主程開發效率高 包含速度和正確率 上線後及時有問題修復迅速，人員少，專案組也沒反應問題。隨著專案人員增加，成員水平不一，就牽涉到專案投產可能需要撤回部分需求 而以前只有乙個分支 回滾難度就非常大，有時候撤回一部分 能...svn撤銷版本修改
svn 版本管理 相關
SVN版本管理 01