配置項如何進行版本控制

Ⅰ 分析一下如何進行版本控制

目標：
1）保證各個環境(開發、測試、主幹)的獨立，避免相互影響；
2）減少最終發布時合並主幹出現沖突的概率；
3）降低沖突處理的難度。
原則：
多個版本（開發版本，測試版本，發布版本）；
多次合並。產品經理一定要對版本進行把控，不合適了及時更新，不知道什麼時候更新多去黑馬程序員社區看一些產品經理的知識！

Ⅱ 配置管理流程

制定配置管理計劃
配置管理員制定《配置管理計劃》，主要內容包括配置管理軟硬體資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。
配置庫管理
配置管理員為項目創建配置庫，並給每個項目成員分配許可權。各項目成員根據自己的許可權操作配置庫。配置管理員定期維護配置庫，例如清除垃圾文件、備份配置庫等。
版本控制
在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由於不能保證新版本一定比老版本「好」，所以不能拋棄老版本。版本控制的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速准確地查找到配置項的任何版本。
配置項的狀態有三種：「草稿」、「正式發布」和「正在修改」，本規程制定了配置項狀態變遷與版本號的規則。
變更控制
在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。
修改處於「草稿」狀態的配置項不算是「變更」，無需CCB的批准，修改者按照版本控制規則執行即可。
當配置項的狀態成為「正式發布」，或者被「凍結」後，此時任何人都不能隨意修改，必須依據「申請→審批→執行變更→再評審→結束」的規則執行。
配置審計
為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規范，質量保證人員要定期審計配置管理工作。配置審計是一種「過程質量檢查」活動，是質量保證人員的工作職責之一。

Ⅲ 如何為VS2010添加版本控制

網路搜索 Visual Source Safe 2005 安裝文件，下載並保存。
2，運行setup.exe文件
3，按照步驟執行安裝，默認安裝配置即可
4，安裝完成
5，注意！！！這里要以管理員身份運行Microsoft Visual SourceSafe
6，進入設置向導，點擊下一步
7，選擇簡歷一個新的database
8，任意選擇一個文件夾來存放資料庫數據，點擊下一步，然後任意輸入資料庫的名稱
9，選擇-Modify-Merge-Model，點擊下一步，然後點擊完成
10，打開VS2010,選擇工具——選項——源代碼管理——下來列表中選擇（當前源代碼管理插件）Microsoft Visual SourceSafe——確定
11，打開現有解決方案，選擇文件--源碼管理--將解決方案添加到源代碼管理，即可

Ⅳ 如何為VS2010添加版本控制

運行setup.exe文件

按照步驟執行安裝，默認安裝配置即可，安裝完成。
注意，這里要以管理員身份運行Microsoft Visual SourceSafe
進入設置向導，點擊下一步
選擇簡歷一個新的database
任意選擇一個文件夾來存放資料庫數據，點擊下一步，然後任意輸入資料庫的名稱
選擇-Modify-Merge-Model，點擊下一步，然後點擊完成
打開VS2010,選擇工具——選項——源代碼管理——下來列表中選擇（當前源代碼管理插件）Microsoft Visual SourceSafe——確定
打開現有解決方案，選擇文件--源碼管理--將解決方案添加到源代碼管理，即可。

Ⅳ 網站開發時，怎麼進行版本控制具體裝什麼軟體，怎麼配置

伺服器安VisualSVN-Server-2.1.3,客戶端安TortoiseSVN-1.6.10.19898-win32-svn-1.6.12，可以把一個人的電腦作為伺服器，固定IP就行。

Ⅵ svn在項目開發過程中到底有什麼作用呢 怎麼叫版本控制呢還有自己可以用它看到別人的代碼嗎

簡單的說，SVN就是把大家的代碼集中到一起進行管理，並且把每個歷史版本都存起來。

SVN是C/S架構的，所有的代碼上傳到伺服器端統一管理，每個人可以從伺服器端隨時拿到最新版本的代碼（能拿到哪些代碼受許可權控制），可以在本地客戶端新增、修改、刪除後再上傳到伺服器端，形成新的最新版本。

當然了，要講到版本控制，就必須理解代碼基線、分支等概念，這個不是幾句話能說清的，建議你看看我的網路文庫，裡面有篇在Windows環境下使用SVN的PPT，相信你看完後就明白SVN是幹嘛的了。

Ⅶ 配置管理和變更管理方法

變更常有

所在銀行科技部已經建立了比較完善的項目管理體系和質量保障體系，但要應對分行或支行需求變更和相關軟體版本配置管理的問題，如果沒有一整套的解決措施和工具的支持，就會出現以下問題：

1)分行反映的缺陷更改不能快速響應，不能快速分配缺陷到指定的開發人員，只能依靠口頭或文檔的傳輸，缺乏一個整合開發商服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、分行領導的信息傳遞和交流的平台。

2)分行的需求變更不能快速響應。分行的需求變更和軟體版本配置只能依靠手工備份，因而，自身不能快速有效地管理各系統的版本，缺乏版本基線的管理策略。

針對以上問題，可以考慮採用軟體配置管理這一關鍵域的思路系統地解決以上問題。配置管理是整個集成軟體項目正常運作的一個管理支撐平台，其目的就是將有關該項目的客戶、客戶服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、高層領導等項目干係人的工作協同起來，實現高效的溝通，及時地共享工作成果。

配置管理的基本功能包括配置標識、變更控制、配置狀態發布和配置審計。變更控制是配置管理的重要內容，其目的是為了在動態中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規范、受控、有完整記錄，受影響的各方均能及時了解情況，並協調一致。

控制不可少

變更控制是通過創建產品基線，在產品的整個生存周期中控制它的發布和變更。配置控制指在配置項標識正式確定之後，對配置項特別是對已提交的代碼、相關文檔和數據等的變更進行系統地跟蹤和控制的過程，主要包括變更的'提出、確定配置項的控制等級、變更的評價、變更的處置、實施經批準的變更、對變更進行驗證和結束變更。變更控制的目的是建立一套控制軟體修改的機制，保證生產符合質量標準的軟體和保證每個版本的軟體包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什麼，如何控制，誰控制變更、何時接收變更、批准和檢驗。

配置項級別

1)已基線化的配置項是指已完成該配置項的審核和批准，並且成為創建或修改其他配置項的輸入。例如：一個設計文檔已審核、通過、簽發，並且成為編碼活動的基礎。

2)受管理和受控的配置項是指已提交審核，但還沒有批准通過的配置項。例如：一個正在進行審核的設計文檔。

3)受控的配置項指已置於版本控制，但項目組不能直接進行改動的配置項。例如：用戶提供的軟體、購買的工具、產品標准等等。

變更請求的狀態

軟體變更、軟體優化和軟體bug都是產生變更的原因。變更申請人(用戶或產品經理)提出變更時，首先要對受控的配置項的修改提出一個變更請求，說明對軟體變更的需求。這是因為變更控制過程是通過變更請求的流動來實現的，而且對軟體的任何請求都必須和相應的變更請求對應。

變更請求的狀態包括：

1)提交：變更請求提交給配置管理員;

2)拒絕：變更控制委員會拒絕變更請求;

3)接受：變更控制委員會接受變更請求;

4)掛起：變更請求被掛起，以後再作決定;

5)已驗證：更改已執行和驗證;

6)關閉：驗證並歸檔配置項，更新的配置項提交給用戶(例如：通過版本發布)。

變更請求的類型

1)增強型：變更請求要求對已批準的項目功能進行增強。

2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。

3)糾錯型：變更請求對錯誤進行修正(諸如bug)。

變更請求的優先順序

在評價變更請求的優先順序時，要對請求變更的配置項進行系統的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據。變更請求的優先順序可分為三類：

1)高：嚴重地影響一些用戶或許多用戶。

2)中：對用戶造成不方便，或是可以採取相應的變通方法處理的主要問題。

3)低：小問題。

修改完後簽入(Check in)

對變更的處理，要按照變更控制規程，將變更請求及其相關附件提交軟體配置控制委員會審批。配置管理組根據審批意見處理變更請求。

只有配置管理員具有Check in許可權。在進行Check in之前，確認下面的事項：

1)所有對配置項所做的修改被批准;

2)所有的更改都經過審核或驗證;

3)所對應的變更請求已經被保存起來;

4)所有相關的審核記錄被保存;

5)Check in時須註明Check in因，如對應的變更請求。

從資料庫中簽出(Check out)

1)對於文檔，配置管理員在更改審批人同意後，從配置庫中Check out配置項，發給項目組成員修改。

2)Check out時須註明Check out原因，如將要修改的問題。

3) 配置管理員一定要在配置狀態發布中跟蹤被Check out出來的配置項。

Ⅷ 如何使用SVN進行版本控制

Android studio如何使用SVN進行版本控制？
如題，有哪位大神在實際工作中使用了Android studio和SVN的，能說明一下具體的操作嗎？下圖是我測試SVN時初始化導入到SVN後，本地項目就變成一片紅了，然後點擊更新也沒用；修改了內容後提交時，提示我沒有任何修改，無法提交，真真的是郁悶啊！
添加評論 分享
默認排序

按時間排序
25 個回答
161
贊同
反對 知乎用戶 Android Studio關聯SVN相關操作
161 人贊同 通過這兩天對Android Studio的研究，終於搞通了Android Studio的基本操作及與SVN的相關關聯操作（這樣才能在公司的開發工作中使用）；Google年底將會停止ADT插件的更新和支持，全面轉向Android Studio（果然是自己的孩子啊），因此使用Android Studio進行安… 顯示全部
通過這兩天對Android Studio的研究，終於搞通了Android Studio的基本操作及與SVN的相關關聯操作（這樣才能在公司的開發工作中使用）；Google年底將會停止ADT插件的更新和支持，全面轉向Android Studio（果然是自己的孩子啊），因此使用Android Studio進行安卓項目的開發也是大勢所趨，項目得閑之時研究一下Android Studio的使用；Android Studio的基本編輯操作現在網上已經很多了，需要的可以找著看看，下面是這幾天摸索出來的Android Studio關聯SVN的相關操作，時間較短，如果有疏漏或錯誤的地方還望指正。
一、Android Studio配置SVN
Android Studio關聯配置SVN很簡單，在Settings裡面，找到Version Control->Subversion；在這個頁面的控制面板中的General中將Use command line client打勾勾選上，然後瀏覽本地的SVN安裝目錄，選到"\svn.exe"即可；
在Use command line client下面還有一個Use system default Subversion configuration directory，這個默認是勾選上上的，這個是svn相關配置信息的路徑，保留默認路徑就行，目前沒有發現需要修改什麼東西；以上操作如下圖：

二、Android Studio項目關聯SVN資源庫及添加忽略文件
在Android Studio中新創建一個Android項目，成功後我們先來添加要忽略的文件；在Android Studio中添加忽略文件同Eclipse有所不同，在Eclipse上我們什麼時候添加忽略文件都可以，但是在Android Studio中只有在未關聯SVN之前添加忽略文件才有效（試了好多次才將忽略文件忽略成功啊！）。Android Studio添加忽略文件同樣是在Settings->Version Control（跟版本控制有關的設置都在這個目錄下）下的Ignored Files里，點擊加號進行忽略文件的設置，Android Studio默認給出了三種忽略方式，供開發者進行選擇：忽略指定的文件、忽略文件夾下所有文件和忽略符合匹配規則的文件；如圖所示：
點擊右側的「+」進行添加，「-」刪除；Android Studio創建的Android項目一般需要忽略.idea文件夾、.gradle文件夾、所有的build文件夾、所有的.iml文件及local.properties文件。
忽略完文件後，我們進行項目同SVN的關聯，選擇VCS->Import into Version Control->Share Project(Subversion)；這里說明一點，在Import into Version Control下有Import into Subversion和Share Project(Subversion）兩個選項：第一個是直接將項目導入到SVN伺服器上，但是這樣做本地的項目同SVN伺服器沒有建立起關聯，在導入後項目所有的文件都會變成紅色，而且在要提交到SVN伺服器時會提示項目不是SVN下的工作副本；第二個是將Android Studio當前項目同SVN伺服器關聯起來，但是並沒有將項目導入到SVN伺服器上，需要在完成建立連接後再次提交項目到SVN伺服器。兩種方式都可以實現將本地代碼提交到SVN伺服器的功能，但是步驟有所不同，先來完成第二種方式的項目同SVN的關聯及代碼提交，第一種貌似不正規，之後再說；下圖既是第二種方式將本地項目同SVN進行關聯的：
之後會彈出選擇要分享的SVN地址及其他選項，如下圖：
在Define share target下選擇第二個可以再trunk下創建你當前項目的文件夾，相應的第一個選項是直接將整個文件都放到trunk文件夾下，第三個在項目文件夾下有創建了一個trunk文件夾，因此建議使用第二中方式；選擇完成後點擊Share就可以了，會彈出讓你選擇SVN工作副本的格式化版本（jdk版本），如下圖：
建議選擇1.8format，我之前選擇了其他的試了一下，發現項目總會報出一下錯誤，原因暫時未發現，就先這樣選擇吧；點擊OK等待一會就能創建本地項目同SVN伺服器的關聯了；成功後悔自動刷新本地的項目，待項目里的內容變成綠色的即表示已經成功了，如下圖所示：
到目前為止只是將項目同SVN伺服器建立了聯系，並沒有將代碼提交到SVN伺服器上去；如何提交呢，其實很簡單，只需點擊SVN相關操作按鈕里的commit就行了（上圖SVN相關操作按鈕左起第二個按鈕）；
點擊Commit後Android Studio會先對當前代碼進代碼分析，如果有錯誤或者警告會彈出如下的框，如果有錯誤沖突等需要解決後再提交，如果是警告可以忽略（同Eclipse相同）；第一次將整個代碼提交到SVN伺服器時時間有可能很長，請耐心等待，之後再創建項目時就不會這么慢了。
成功後我們就完成了新建項目同SVN的關聯及導入項目到SVN伺服器上了。
關於第一種方式，在將本地代碼導入到SVN伺服器後將本地代碼刪除，然後從SVN伺服器上將之前提交的代碼更新下來，這樣一來也可以同SVN建立關聯正常進行開發；第一種方式和第二種方式的區別就在於：第一種是將代碼先提交到SVN伺服器上，然後再從SVN伺服器上更新下來（本地項目同SVN伺服器建立聯系）；第二種是先同SVN伺服器監理聯系，然後將代碼提交到SVN伺服器上去。建議使用第二種方式進行新項目的SVN關聯。
三、Android Studio SVN代碼沖突的解決
關於代碼沖突解決的問題，首先要感謝一下知友ShinChven的回答建議。在使用SVN更新伺服器上的代碼時，有時會彈出代碼沖突的對話框，問你是否進行合並，並提供了三種合並方案：accept yours(使用你的)、accept theirs(使用別人的)和merge(合並)；

前兩個都是進行的覆蓋操作，就不多做解釋了；當你選擇merge合並時，會彈出代碼合並對照窗口，一共有三個屏，左右兩側時你和伺服器不同的代碼並高亮顯示不同的部分，帶有箭頭和叉號，通過點擊箭頭將兩邊沖突的代碼添加到中間的合並區域中去，點擊叉號則辨識放棄那一段代碼，待所有沖突處理完成後merge就成功了。

Ⅸ 如何使用SVN進行版本控制

SVN全名Subversion，即版本控制系統。SVN與CVS一樣，是一個跨平台的軟體，支持大多數常見的操作系統。作為一個開源的版本控制系統,Subversion管理著隨時間改變的數據。這些數據放置在一個中央資料檔案庫(repository)中。這個檔案庫很像一個普通的文件伺服器,不過它會記住每一次文件的變動。這樣你就可以把檔案恢復到舊的版本,或是瀏覽文件的變動歷史。Subversion是一個通用的系統,可用來管理任何類型的文件,其中包括了程序源碼。
SubVersion：實現服務系統的軟體。
TortoiseSVN：是SVN客戶端程序，為windows外殼程序集成到windows資源管理器和
文件管理系統的Subversion客戶端。
SVNService.exe：是專為SubVersion開發的一個用來作為Win32服務掛接的入口程序。
AnkhSVN：是一個專為VisualStudio提供SVN的插件。
Subversion提供以下主要功能：
目錄SVN版本控制
CVS只能跟蹤單個文件的歷史,不過Subversion實作了一個「虛擬」的版本控管文件系統,能夠依時間跟蹤整個目錄的變動。目錄和文件都能進行版本控制。
真實的版本歷史
自從CVS限制了文件的版本記錄，CVS並不支持那些可能發生在文件上，但會影響所在目錄內容的操作，如同復制和重命名。除此之外，在CVS里你不能用擁有同樣名字但是沒有繼承老版本歷史或者根本沒有關系的文件替換一個已經納入系統的文件。在Subversion中，你可以增加（add）、刪除（delete）、復制（）和重命名（rename），無論是文件還是目錄。所有的新加的文件都從一個新的、干凈的版本開始。
自動提交
一個提交動作，不是全部更新到了檔案庫中，就是完全不更新。這允許開發人員以邏輯區間建立並提交變動，以防止當部分提交成功時出現的問題。
納入SVN版本控制的元數據
每一個文件與目錄都附有一組屬性關鍵字並和屬性值相關聯。你可以創建,並儲存任何你想要的Key/Value對。屬性是隨著時間來作版本控管的,就像文件內容一樣。
選擇不同的網路層
Subversion有抽象的檔案庫存取概念,可以讓人很容易地實作新的網路機制。Subversion可以作為一個擴展模塊嵌入到ApacheHTTP伺服器中。這個為Subversion提供了非常先進的穩定性和協同工作能力，除此之外還提供了許多重要功能:舉例來說,有身份認證,授權,在線壓縮,以及文件庫瀏覽等等。還有一個輕量級的獨立Subversion伺服器，使用的是自定義的通信協議,可以很容易地通過ssh以tunnel方式使用。
一致的數據處理方式
Subversion使用二進制差異演算法來異表示文件的差異,它對文字(人類可理解的)與二進制文件(人類無法理解的)兩類的文件都一視同仁。這兩類的文件都同樣地以壓縮形式儲存在檔案庫中,而且文件差異是以兩個方向在網路上傳輸的。
有效的分支(branch)與標簽(tag)
在分支與標簽上的消耗並不必一定要與項目大小成正比。Subversion建立分支與標簽的方法,就只是復制該項目,使用的方法就類似於硬連接（hard-link）。所以這些操作只會花費很小,而且是固定的時間。

Ⅹ 關於項目管理中配置管理的實現過程，配置項的知識請教以及相比版本管理的差異

你的理解更多是「產品集成」的概念，即怎麼把幾個產品模塊或構件組合成一個產品，但這不是配置管理的概念。
配置管理：簡稱CM（Configuration Management的縮寫），標識、控制和管理變更的一種管理活動。它控制配置項的修改和發行；記錄和報告配置項的狀態和變更；保證配置項的完整性、一致性和正確性；以及控制配置項的儲存、裝載和交付。
根據這個定義，配置管理的主要工作包括：
1）配置庫的管理活動。配置庫現在工具非常多，例如GIT、SVN、CVS、VSS等等。通常會根據開發所處的階段，設立開發庫、受控庫與產品庫。
2）標識配置項，即需要定義如何去標識配置項。配置管理中受控制的對象被稱為配置項，是生命周期中創建的信息，包含程序、數據、文檔，分基線配置項和非基線配置項兩類。特別是你的產品最終是如何標識的，比如怎樣定義V1.0.0的規則。
3）基線的管理。是一組經過正式審查並且達成一致的規范或工作產品，是下一階段工作的基礎。怎樣確定、發布基線，怎樣管理基本的變更。
4）配置項變更管理。可以根據不同的配置項、不同的開發周期，明確變更的管理規則。
5）配置項狀態管理與配置審計 。

而產品集成是如何把一個產品逐步的從一個個模塊或組件，最後組合成一個產品的過程。
1）首先產品的技術結構上要能夠支持，如果模塊不能相互獨立和拆解，談不上靈活的組合。
2）在開發實現上，需要有一個集成的策略，哪些先實現，哪些後實現，哪些可以先進行集成
3）需要建立 集成的環境，使開發好的模塊可以在集成環境中進行調試
4）通常開發完成後，需要進行源代碼的編譯，並打包成一個測試包，然後裝在集成環境中，進行調試，以確認各個模塊之前是否可以兼容和運轉，這時通常會進行測試工作。
5）如果你想進行ABC組合，或者AC組合，那麼都需要進行相應的編譯、打包（例如形成EXE）過程，然後在集成環境中進行聯調和測試。