zt 常用版本控制軟體簡介

CVS，感覺自己有點倒退了，因為之前一直用的是SVN來進行版本控制的，平時自己也愛折騰折騰Hg，Git等分散式版本控制軟體。和一個開發經理閒聊時順便了解了一下，為何一直使用CVS而不是SVN或直接上Hg、Git。那個同學很謙虛的告訴我，CVS確實有很多問題，但是這麼一直使用過來，如果換成SVN，感覺帶來的好處不足夠大。

但是有趣的是，這位同學用CVS的方式也很特別，就是使用CVS+本地Hg的方式進行管理。具體方式是目錄A同時使用CVS和Hg，同一份程式碼在目錄B使用Hg，目錄B的修改push到目錄A，在頻繁的Hg push，最終完成某個功能或Bug修復後，再透過CVS將改動提交到伺服器。（實際使用情況更復雜，他還同時還在另外一臺Linux機器用Hg管理，然後與目錄A目錄B同步。）

這樣做的好處是可以避免頻繁的入庫CVS，保證每次提交都是一個完整的功能或Bug修復，同時本地又留有每次微小變更的歷史記錄。 不過這樣的確有些累。

關於CVS和SVN的具體區別，我之前並沒有認真研究過，所以我沒辦法說服那位同學，而且他可能比我還專業。考慮到以後我還要在CVS上幹活，於是搜了一下相關的文章，找到一篇寫的不錯的，瞭解一下，可就是找不到原文出處，就直接貼下來了，如果以後知道出處，一定示出。

以下是轉帖內容：

CVS SVN VSS 使用對比

一、Subversion包含絕大部分CVS功能

Subversion 作為CVS 的重寫版和改進版，其目標就是作為一個更好的版本控制軟體，取代目前流行的CVS。Subversion 的主要開發人員都是業界知名的CVS 專家。Subversion支援絕大部分的CVS 功能/命令；Subversion 的命令風格和介面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。

二、全域性性的版本編號

一個新的版本，並得到一個自增量的版本號N+1，該版本號並不針對某個特定的檔案，而是全域性性的、針對整個版本庫的。因此，我們可以將Subversion 的版本庫看作是一個檔案系統或檔案目錄樹的陣列。

從技術的角度來說，在Subversion 中，"檔案foo.c 的第5 版本"這個說法是錯誤的；正確的說法應該是："檔案foo.c 在版本庫被修改了5 次，即執行5 次commit 後是什麼樣子？"。顯然，在Subversion 中，版本庫被修改5 次後foo.c 的內容，和被修改了6 次後foo.c 的內容很可能完全一樣，因為版本庫的第6 次修改很可能只修改了版本庫的其他部分，而並沒有對foo.c 的進行修改。相反，在CVS 中，檔案foo.c 的第1.1 版本和第1.2 版本總是不同的。

Subversion 的全域性性版本編號為Subversion 帶來了諸多的優勢：如對目錄或檔案執行複製，無論涉及多少檔案，Subversion 不需要對單個檔案依次執行複製命令，僅僅需要建立一個指向相應的全域性版本號的一個指標即可。

三、目錄的版本控制

CVS 只能對檔案進行版本控制，不能對目錄進行版本控制，因此CVS 沒有任何關於檔案"移動"（move）操作的概念。當人為進行檔案移動操作時，CVS 只能注意到，一個檔案在一個位置被刪除了，而在一個新位置建立了另外一個檔案。由於它不會連線兩個操作，因此也很容易使檔案歷史軌跡丟失。設定 CVS 儲存庫時，必須非常謹慎地為每個檔案選擇準確的位置，因為在設定之後，幾乎就要一直使用這個位置了。

同樣由於CVS 不記錄目錄的版本歷史，CVS 不支援對檔案的"重新命名"（rename），人為的對檔案進行重新命名會使得命名前後的檔案失去歷史聯絡，而記錄歷史本來是版本管理的主要目的。

還有，CVS 不支援對檔案的"複製"（copy），人為的複製對CVS 而言，只能看到新的檔案的增加，而不能記錄複製原始檔和目標檔案之間的聯絡。

綜上所述，缺乏對檔案"移動"、"重新命名"、"複製"的支援的根源在於CVS 不能記錄目錄的版本歷史，而這些操作在當前的軟體開發過程中經常發生，這正是Subversion被開發並取代CVS 的主要原因之一。

Subversion 將目錄作為一類特殊的檔案來處理（事實上，從檔案系統的角度來看，目錄確實是一類特殊的檔案，當目錄中的子目錄/檔案被刪除、重新命名、或新的子目錄/檔案 被建立時，目錄的內容將發生改變）。因此，Subversion 象記錄普通檔案的修改歷史一樣記錄對目錄的修改歷史，當發生檔案/目錄的移動、重新命名或複製操作時，Subversion 能夠準確記錄操作前後的歷史聯絡。同樣，象對檔案的不同歷史版本進行比較一樣，Subversion支援對目錄的不同歷史版本的比較，清晰展現目錄的變化 歷史。

四、原子性提交

從使用者的角度來看，CVS 和Subversion 都支援對多個檔案修改的批次提交，但二者在實現方式上存在本質的區別。

CVS 採用線性、序列的批次提交，即依次地，一個接一個地執行提交，每成功提交一個檔案，該檔案的一個新的版本即被記錄到版本庫中，提交時使用者提供的日誌資訊被重複地儲存到每一個被修改的檔案的版本歷史中。

CVS 序列批次提交模式的弊端在於 －當任何原因造成批次操作的中斷時（典型原因包括：網路中斷、客戶端當機等），版本庫往往處於一個不一致的狀態：原本應該全部入庫的檔案只有一部分入庫， 很有可能版本庫中的最新版本不能順利編譯，更為嚴重的是，隨著其他的使用者執行cvs update 操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，並存在質量隱患。另外，假如該批次提交的中斷沒有被及時發現，開發團隊往往要花更 多的時間進行軟體除錯和排錯。

CVS 即使在批次提交不發生中斷時也會造成不一致：假設使用者A 啟動一個需要較長時間才能完成的批次提交；與此同時，使用者B 執行cvs update 操作。此時，使用者B 很有可能得到一個不一致的更新，即使用者B 透過"更新"操作，得到使用者A 的部分修改檔案。

Subversion 徹底消除了CVS 的以上弊端。無論批次提交包含多少檔案修改，只有當全部檔案修改都成功入庫，該提交才變得有效，才對其他使用者可見；否則，無論任何原因造成中 斷，Subversion 都會自動執行"回滾"（rollback）操作。換一個說法，Subversion 保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是Subversion 的原子性提交（atomic commit）。

由於Subversion 的原子性提交特性和全域性版本編號方式，當提交成功完成時，一個唯一的、新的全域性版本編號產生，而提交時使用者提供的日誌資訊與該新的版本編號關聯，只進行一次儲存（區別於CVS 的按檔案重複儲存）。

五、支援變更集概念

由於Subversion 的所有提交是原子性的，每次成功提交形成的唯一的全域性版本號對應此次批次提交的所有檔案修改，也就是說，一個Subversion 版本號其實對應了一個邏輯上的變更集（change set），該變更集可能對應於對一個BUG 的修復，或者對應於對一個已有功能的改進，或者對應於一個新功能的實現。可以說，變更集是一個軟體開發活動的邏輯結果，該變更集可以透過其對應的版本號在 軟體開發的其他過程中（如軟體合併/整合過程，軟體釋出管理，變更管理系統，缺陷追蹤系統）被引用。因此，Subversion 將版本管理從單純的、單個的檔案修改的層次透過邏輯上的抽象，上升到更便於理解和交流的開發活動的層次。

六、差異化的二進位制檔案處理

由於歷史原因，CVS 主要是為早期的程式設計師設計的，CVS 能夠有效處理文字檔案（或ASCII檔案，原始碼檔案），可以對文字檔案進行差異化的儲存、新舊版本的比較，檔案合併等；但對於二進位制檔案，CVS則明顯 力不從心。在CVS 的版本庫中，對於二進位制檔案的歷史版本，CVS 唯一能做的就是對不同的版本進行獨立的、冗餘的儲存，哪怕版本之間其實只存在微小的差異。舉例而言，一個10M 的二進位制檔案（照片、圖形檔案、機械設計檔案、電子設計檔案）假如每週修改一次，無論每次修改的大小，一年下來，僅該檔案就要消耗500M 以上的儲存空間。而且，客戶端每次獲取該檔案的新版本都要消耗10M 的網路流量。

對於目前的開發團隊，無論是軟體開發，Web 站點的開發，手機等電子產品的研發，需要進行版本管理的不僅是原始碼等文字檔案，還需要管理需求文件、設計文件、測試文件、使用者手冊，圖形影像檔案，機械/電子設計檔案等諸多的二進位制檔案，CVS 顯然不是一個好的選擇。

與CVS 不同，Subversion 採用統一的二進位制差異演算法（binary differencing algorithm），即對文字檔案和二進位制檔案採用相同的差異比較演算法，並以相同的方式在版本庫中進行儲存：每次提交後版本庫中只儲存相對於先前版本的 差異，從而可以節省大量的儲存空間。

該二進位制差異演算法不僅應用在版本的儲存上，更為重要的是，Subversion 對二進位制檔案與文字檔案一視同仁，當客戶端需要獲取新的版本時（如執行svn update），在網路上只有版本的差異被傳輸，從而大大減少對網路頻寬的消耗。更多細節參見"七、雙向的差異化－壓縮網路傳輸"。

七、 雙向的差異化－壓縮網路傳輸

如上所述，CVS 對二進位制檔案不能進行有效的差異化處理。對於文字檔案，CVS 僅僅支援單向的差異化傳輸：從CVS 到客戶端的傳輸是差異化的，即執行cvs update 時，只有差異的部分從伺服器傳輸到客戶端；而當執行cvs commit 時，無論程式碼變化多少，CVS 都需要從客戶端向伺服器完整傳輸被修改檔案的全部內容，不能只傳輸差異。

相反，無論是文字檔案還是二進位制檔案，Subversion 都進行雙向的差異化傳輸，並且差異化內容還要進行壓縮/解壓縮的過程：在伺服器端獲取差異顯而易見，與CVS 類似；Subversion 在客戶端獲取差異的秘密在於 — Subversion 在客戶端的工作複製中隱含了每個檔案的一個"只讀的、乾淨的"副本（該副本隱藏在隱含目錄.svn 裡，通常不可見，該副本還有更多的妙用，參見"十二、更多的本地/離線操作"），透過比較使用者在客戶端的修改和該隱含的副本，Subversion 獲取需要真正傳送到伺服器的差異，並對差異進行壓縮後才進行網路傳輸。

對CVS 而言，操作的成本（網路頻寬消耗是最大的操作成本）與被修改的檔案的大小成比例，而與修改本身的大小無關；對Subversion 而言，操作成本只與修改本身的大小成比例，而與被修改的檔案的大小無關。因此，與CVS 相比，Subversion 消耗更少的網路頻寬（以客戶端的儲存空間換取更少的頻寬消耗在目前的計算環境下應該是個相當不錯的選擇！）。Subversion 更加適合基於網際網路（或廣域網）進行協作開發的地理上分佈的團隊 — 版本伺服器集中、單一；客戶端廣泛分佈。

八、高效、快捷建立分支和基線

CVS 和Subversion 都支援分支（branch）和基線（tag），透過分支與合併，可以有效支援大專案的並行開發模式；透過基線管理，可以準確標識一組檔案的版本，有效進行軟體釋出管理和必要時的歷史回溯。

但CVS 和Subversion 在實現分支和基線的方式上存在很大的不同。CVS 在建立分支的時候，需要對所有進行分支的檔案進行依次的操作，因此分支的建立成本（主要是建立分支所需的時間，或消耗的計算資源）與參與分支的檔案數量成 比例，專案越大，版本庫越大，檔案越多，分支的建立成本越高；基線（tag）的建立與此類似。

Subversion 的分支和基線是透過執行"複製"來建立的：回想一下在沒有引入版本管理工具的時候我們是如何進行所謂的"分支"和"基線"管理的？答案顯然是"複製" — 我們透過"複製"或"備份"來建立基線；同樣，為支援多個開發人員可以同時進行開發，我們為每個開發人員建立一份"複製"。由此看 來，Subversion 透過"複製"來建立分支和基線顯得非常自然，有點"返樸歸真"的意思。

由於Subversion 的全域性版本號特性，Subversion 中分支或基線的建立過程，或Subversion中的"複製"過程，真正的操作是在版本庫中建立一個到某一全域性版本號的指標（pointer），不再需要 針對眾多的單個檔案依次執行操作。因此，該操作的成本為一個很小的常數，與專案大小，版本庫大小，檔案數目的多少無關；並且，分支或基線的建立不需要進行 版本的冗餘儲存，新建立的分支或基線基本不佔用版本庫空間，分支的後續儲存空間的開銷也只與修改的大小有關。

九、整合Apache Web Server，提供更多的特性

Subversion 透過與Apache Web Server 的整合，可以提供基於http/https 協議的版本庫訪問機制，從而支援Subversion 跨越防火牆的安全訪問。除此以外，Subversion 還可以利用更多的Apache 特性，包括但不限於：Apache 豐富的使用者認證機制（包括透過LDAP伺服器如Windows Active Directory 伺服器的使用者認證），基於目錄路徑的精細粒度的訪問控制，對傳輸的網路流量進行壓縮/解壓縮，瀏覽版本庫目錄結構等等。

十、支援WebDAV

WebDAV（Web-based Distributed Authoring and Versioning）是一種基於 HTTP 1.1 協議的通訊協議.它擴充套件了HTTP 1.1，在GET、POST、HEAD 等幾個HTTP 標準方法以外新增了一些新的方法，使應用程式可直接對Web Server 直接讀寫，並支援寫檔案鎖定(Locking)及解鎖(Unlock)，還可以支援檔案的版本控制。

Microsoft windows2000/XP 及IE, Office 還有Adobe/MicroMedia 的DW 等都支援WebDAV，這又大大增強了Web 應用的價值，以及效能。對於需要大量釋出內容的使用者而言，應用WebDAV 可以降低對CMS 系統的依賴，而且能夠更自由的進行創作。上傳、下載變得輕鬆自如。

Subversion 透過與Apache Web Server 的整合，支援WebDAV 協議，使得業務使用者（business users）或非技術使用者在不安裝任何版本管理客戶端的情況下輕鬆訪問Subversion 版本庫，不改變業務使用者已有使用習慣，支援分佈的業務使用者對文件的評審、修改並實現版本控制，真正將軟體開發的生命週期從開發/技術團隊擴充套件到專案的全部 干係人（stakeholder），避免透過電子郵件傳遞文件的混亂與無序、透過Windows 作業系統共享造成的安全漏洞、病毒攻擊、歷史版本被覆蓋或丟失、審計困難等諸多典型問題。

十一、更好的衝突標識與處理

CVS 和Subversion 都支援透過分支與合併進行並行開發，並可以自動檢測到合併時的衝突（conflicts），並在合併結果中 以<<<<<< … >>>>>>標識合併的衝突部分。

在CVS 中，經常會出現由於使用者的疏忽（如，沒有注意到衝突，或沒有完全處理好衝突）而將仍然帶有<<<<<< … >>>>>>衝突識別符號號的檔案直接進行提交（commit），從而在版本庫中產生垃圾版本。

Subversion 有效解決了CVS 的以上問題：Subversion 記錄並保持檔案的衝突狀態，只有當使用者明確執行svn resolved 命令後，該衝突狀態標識才被複位，該檔案才能被提交，從而大大減少了將仍然帶有<<<<<< … >>>>>>衝突識別符號號的檔案直接進行提交的可能性。

十二、 更多的本地/離線操作

眾所周知，CVS 客戶端的工作複製中包含了一個隱含目錄CVS，該目錄中記錄了客戶端需要的一些管理資訊；與此類似，Subversion 的客戶端工作複製中也包含了一個隱含目錄.svn，該目錄中同樣記錄了客戶端需要的一些管理資訊，如版本庫URL，當前訪問版本號等。

與CVS 不同的是，Subversion 的.svn 目錄中還包含了工作複製中每一個檔案的一個"只讀的、乾淨的"副本。正是由於該副本的存在，使得Subversion 與CVS 相比，可以執行更多的本地/離線操作，即某些操作不需要訪問版本庫伺服器，因此不需要存在從客戶端到伺服器的網路連結，當然也不消耗任何網路頻寬，這進一 步增強了Subversion 對廣域網的友好支援。

Subversion 的以下命令可以進行離線操作：

svn status － 顯示工作複製上的本地修改概況；

svn diff －顯示工作複製上的本地修改細節，比較修改前後的內容；

svn revert － 撤銷工作複製上的本地修改；

十三、 對符號連結進行版本管理

在Unix 檔案系統中，符號連結（symbolic links，包括硬連結和軟連結）是一種重要的檔案系統元素。CVS 不能對符號連結進行版本管理；Subversion 則可以對符號連結進行版本管理。

十四、 後設資料管理

與CVS 相比，Subversion 增加了後設資料（metadata）管理機制。即可以對版本庫中的檔案或目錄附加任意的"屬性"（property），並記錄屬性的變化歷史，也就是對元數 據進行版本管理。一個Subversion 屬性是一個"屬性名稱/屬性值"的二元組，如"BugNumber= 100"就是一個屬性，可以將該屬性附加到版本N 上，以說明版本N 改正了編號為100的BUG。

Subversion 後設資料的目的是提供附件的資訊以滿足流程或過程自動化的需要，以增強Subversion 的管理能力和自動化程度。Subversion 自身就透過"屬性"來儲存一些特殊的資訊。一個使用Subversion 後設資料的例子：可以在一些批處理的指令碼程式或Subversion的鉤子程式（hooks）中建立、訪問、修改"屬性"後設資料來滿足流程自動化的要求。

十五 VSS CVS 比較

VSS適合小團隊使用，基本的配置管理功能都有。VSS最大的特點就是部署比較簡單，上手比較快。VSS最大的缺點就是安全性問題，目錄共享、檔案方式儲存等。當然VSS還只能在Windows下使用。

CVS瞭解過，應該說特點也很鮮明。首先CVS是開源軟體，根據長期的流傳，已經演變了很多版本，適合於不同的平臺。因此，在CVS客戶端上是多種多樣的。其次，CVS的部署稍微複雜點，現對VSS來說，這是其一缺點。最後，CVS在配置管理的理念上，比VSS有所進步。

十六 Vss與Svn 的對比

1. SVN支援重新命名，這對 Java開發來說非常重要。

為了得到更好的程式碼，開發中需要經常進行重構，重構就經常涉及到檔案的重構名，而重新命名中 VSS 中是不被支援的。

2. 開發的時候不一定要鎖定。

一方面導致重構不方便，另一方面，不能離線開發，使用 SVN 就不同，可以帶回家繼續開發，回來後，提交就行了。

3. 多平臺。
可以支援多個平臺下的操作


4. 更好的客戶端支援。
Eclipse 中的 VSS Plugin 不如它的 SVN Plugin 好用。一個在 Windows 下用的 SVN 客戶端 TortoiseSVN 也比 VSS 的客戶端好用（VSS 只有微軟提供的一個 GUI 客戶端）。

5. 更好地與外圍工具整合。

各種各樣的外圍工具（主要是伺服器端），滿足多種需要。如果有需要，也可以自己寫外掛或管理指令碼，開放的架構，允許我們這樣做。

6. 方便。

一個例子：部署應用的時候，以前的做法是找出一個專案中修改過的檔案，更新到伺服器上去，現在可以在伺服器上執行 svn export 命令，把程式碼庫中的最新版本匯出，完成部署（也可以替換回老版本）。

7. 速度與穩定性看起來都不錯。

學習它的管理、它的工作方式，是值得的。而 VSS 是一個已經被逐漸拋棄的軟體。如果時間不是多得沒處用，那麼就把時間花在最值得花的東西上面。

最後再補充一點：

使用者、許可權管理

cvs：管理員很難清楚的知道一個專案到底有多少個使用者各使用者的許可權和密碼是什麼 只能用分組的方式管理使用者而且密碼和許可權還是不清晰
svn：檢視、修改配置檔案即可

[@more@]
常用版本控制軟體
根據檢視網路上的資料，看到一般的公司使用的版本控制軟體大致如下：
（其中的等級評語來自 但其中沒有介紹關於Perforce，StarTeam）
1.Clear case --------〉中堅級
2.CVS --------〉開源奇葩
3.Visual SourceSafe --------〉入門級
4.PVCS --------〉小工作組級
5 Perforce --------〉
6.CCC --------〉元老級
7.StarTeam --------〉
8.RCS --------〉元老級
9.SCCS --------〉元老級
10．Hansky Firefly --------〉新秀級
11.Others（還有一些比較少見或某個公司專用的軟體，如Seapine，北大青鳥的JBCM等）


1．Clearcase是Rational公司(2003年被IBM收購)的一款重量級的軟體配置管理(SCM Software Configuration Managemen)工具。不同於CVS和VSS，Clearcase涵蓋的範圍包括：版本控制、建立管理、工作空間管理和過程控制。從最初的軟體配置計劃，到配置項的確立，從變更控制到版本控制，它貫穿於整個軟體生命週期。 ClearCase支援現有的絕大多數作業系統。ClearCase 安裝、配置、使用相對較複雜，需要進行團隊培訓。

2. CVS 是Concurrent Versions System 的縮寫，它是開放原始碼軟體世界的一個偉大傑作，由於其簡單易用、功能強大，跨平臺，支援併發版本控制，而且免費，它在全球中小型軟體企業中得到了廣泛使用。其最大的遺憾就是缺少相應的技術支援，許多問題的解決需要自已尋找資料，甚至是讀原始碼。CVS是一個典型的Server/Client端軟體，有UNIX版本的CVS 、Linux版本的CVS，和WINDOWS版本的CVS，在下載的軟體包中已經包含了Server端和Client端，但是因為我們在工作中一般都是使用Windows作業系統，所以我們可以再下載一個Windows下CVS的Client端軟體WinCVS。在以下網站可以獲取最新版本的CVS。。CVS支援遠端管理，專案組分佈開發時用CVS。

3.VSS微軟的產品。簡單好用，區域網中用VSS。用於Team級還可以，企業級不好。僅支援Windows 作業系統。
4.PVCS MERANT 公司的核心產品PVCS，PVCS的最新版PVCS8.0。在PVCS8.0中，過程支援的功能與PVCS進行了整合。看到網上對它的介紹不多，據說曾經贈送給國內很多大的機構使用。主要功能：軟體配置管理;問題管理;過程控制與自動化, 幫助軟體開發組織自動提高軟體產品質量。


5．Perforce是美國perforce軟體公司的軟體配置產品家族，其特點是易用性強，速度快。主要特性【smchina.net 觀點 】： 安裝、配置和管理非常簡單，安裝過程幾分鐘就可以搞定 ；基於TCP/IP的客戶伺服器架構，不依賴於其他網路協議如NFS等 ；採用流式傳輸協議提高傳輸效率 ；易用，命令列客戶端容易上手 ；檔案間分支技術更自然符合開發人員工作習慣 ；與變更管理整合，並提供開放介面，支援第三方變更管理工具
6．CCC 上個世紀七十年代初期加利福利亞大學的Leon Presser教授撰寫了一篇論文，提出控制變更和配置的概念，之後在1975年，他成立了一家名為SoftTool的公司，開發了自己的配置管理工具：CCC，這也是最早的配置管理工具之一。
7．Borland StarTeam一個用於管理配置和變更的整合環境。主要特性:改善分散式開發團隊的溝通及工作表現;提高對應用軟體開發生命週期的觀測力和控制力;利用現有的技術投資並提高投資回報(ROI);定製滿足機構要求的解決方案. StarTeam和Microsoft Source Code Control介面（API）相容，從而能夠同支援該介面的眾多工具平臺進行無縫整合。StarTeam還可以與特定開發工具進行整合，例如Microsoft、IBM、和Borland的主流開發工具，包括Borland JBuilder、Borland Delphi、Borland C++ Builder。StarTeam還可以與很多第三方軟體整合，從而充分發揮開發機構用於開發、測試和需求等活動的現有投資價值。全部軟體開發資產被妥善地儲存在StarTeam Server中，有助於減少生命週期中不同環節之間的障礙，提高團隊協同工作與資訊共享的效率，從而提升開發機構的投資回報率並加速軟體交付市場。
8．RCS是另一種基本的原始碼管理工具,是WALTER.f.Tichy 於1980 年在Indina的 Purdue 大學開發的. RCS和SCCS 類似,也是基於單一檔案的版本維護系統.
9．SCCS的全稱是Source Code Control System。是一種基本的原始檔版本控制工具,它適用於任何正文檔案的版本維護.它基於單一檔案的版本控制,通常,它的軟體儲藏室和要維護的檔案在同一目錄下. SCCS 工作時,有一個專門的SCCS 格式的檔案保留其原始檔的編碼版本,其記錄了足夠的資訊來生成新的版本,並記錄了誰對檔案有修改權,擁有該版本的”鎖”.
10．H a n s k y 公司軟體開發管理套件中重要一員的Firefly，可以輕鬆管理、維護整個企業的軟體資產，包括程式程式碼和相關文件。Firefly是一個功能完善、執行速度極快的軟體配置管理系統，可以支援不同的作業系統和多種整合開發環境，因此它能在整個企業中的不同團隊，不同專案中得以應用。Firefly基於真正的客戶機/伺服器體系結構，不依賴於任何特殊的網路檔案系統，可以平滑地執行在不同的LAN、WAN 環境中。它的安裝配置過程簡單易用，Firefly 可以自動、安全地儲存程式碼的每一次變化內容，避免程式碼被無意中覆蓋、修改。專案管理人員使用Firefly可以有效地組織開發力量進行並行開發和管理專案中各階段點的各種資源，使得產品釋出易於管理；並可以快速地回溯到任一歷史版本。系統管理員使用Firefly的內建工具可以方便的進行儲存庫的備份和恢復，而不依賴於任何第三方工具。