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分布式版本控制系统最大的反传统之处在于，可以不需要集中式的版本库，每个人都工作在通过克隆操作建立的本地版本库中，也就是说每个人都拥有一个完整的版本库。分布式版本控制系统的几乎所有操作包括查看提交日志、提交、创建里程碑和分支、合并分支、回退等都直接在本地完成而不需要网络连接。每个人都是本地版本库的主人，不再有谁能提交谁不能提交的限制，加之多样的协同工作模型（版本库间推送、拉回，及补丁文件传送等）让开源项目的参与度有爆发式增长。