cvs採用客戶端/伺服器架構設計，版本庫位於伺服器端，實際上就是乙個rcs檔案容器。每乙個rcs檔案以「,v
」作為檔名字尾，用於儲存對應檔案的歷次更改歷史。rcs檔案中只保留乙個版本的完全拷貝，其他歷次更改僅將差異儲存其中，使得儲存變得更加高效。圖1-1展示了cvs版本控制系統的工作原理，可以看到作為rcs檔案容器的cvs版本庫和工作區目錄結構的一一對應關係。
cvs成功地為後來的版本控制系統確立了標準，像提交（commit）、檢入（checkin）、檢出（checkout）、里程碑（tag或譯為標籤）、分支（branch）等概念早在cvs中就已經確立。cvs的命令列格式也被後來的版本控制系統競相模仿。
vn成熟的標誌是其完成了後端儲存上的變革，即從一開始的bdb（簡單的關係型資料庫）到fsfs（檔案資料庫）的轉變。fsfs相對於bdb具有更高的穩定性、免維護性，以及實現的可視性。圖1-2展示了採用fsfs作為儲存後端的svn版本控制系統的工作原理。
svn的每一次提交，都會在伺服器端的db/revs
和db/revprops
目錄下各建立乙個以順序數字編號命名的檔案。其中db/revs
目錄下 的檔案（即變更集檔案）記錄與上乙個提交之間的差異（字母a
表示新增，m
表示修改，d
表示刪除）。在db/revprops
目錄下的同名檔案（沒有在圖1-2中體現）則儲存著提交日誌、作者、提交時間等資訊（稱作版本屬性）。
svn相對cvs在本質上並沒有突破，都屬於集中式版本控制系統，即乙個專案只有唯一的乙個版本庫與之對應，所有的專案成員都通過網路向該伺服器進行提交。單點故障是集中式版本控制的死穴，並由此帶來資料備份和資料恢復的管理成本。此外集中式版本控制系統還存在著提交瓶頸。
git分布式版本控制系統最大的反傳統之處在於，可以不需要集中式的版本庫，每個人都工作在通過轉殖操作建立的本地版本庫中，也就是說每個人都擁有乙個完整的版本庫。分布式版本控制系統的幾乎所有操作包括檢視提交日誌、提交、建立里程碑和分支、合併分支、回退等都直接在本地完成而不需要網路連線。每個人都是本地版本庫的主人，不再有誰能提交誰不能提交的限制，加之多樣的協同工作模型（版本庫間推送、拉回，及補丁檔案傳送等）讓開源專案的參與度有爆發式增長。
版本控制 SVN簡介
在學習svn的時候，我們不可避免的會問 svn是什麼？我們為什麼要學習svn？它能幫我們做什麼？怎麼用它？是維護工程藍圖的標準作法，能追蹤工程藍圖從誕生一直到定案的過程。此外，版本控制也是一種軟體工程技巧，藉以在軟體開發的過程中，確保由不同人所編輯的同一程式檔案都得到同步。1 程式 1 更改原始檔，...
版本控制入門簡介
版本控制已經出現有些年頭了。然而，我還是會被人問起一些，諸如版本控制是什麼或者它是如何工作的，這樣基礎的問題。本文會概括地解釋版本控制解決的重要問題，本文使用的場景針對的是源 版本控制。目前有很多不同型別的版本控制系統 version control system，vcs 一些vcs，比如subve...
AWS Lambda 版本控制簡介
在建立 lambda 函式時，只有乙個版本 即 latest版本。當您發布版本時，aws lambda 在 latest版本中建立了 lambda 函式 的快照副本 和配置 已發布的版本是不可變的。也就是說，您無法更改 或配置資訊。新版本具有包含版本號字尾的唯一 arn，如下所示。每個 lambda...