Python 高手编程系列一千零六十九：集中式系统

集中式版本控制系统基于保存文件的单个服务器，并允许人们签入和签出对这些文件
所做的更改。原理很简单，每个人都可以得到他/她的系统上的文件的副本，然后对它们进行更改。从那里，每个用户可以向服务器提交（commit）他/她的更改。这些更改就会生效，
修订版本（revision）号也随之增加。其他用户可以通过更新（update）同步他们仓库
（repository）的副本来获取这些更改。
仓库贯穿所有的提交，系统将所有修订版本存档到数据库用以撤销任何更改，也可以
提供已完成的操作的信息，如图 8-1 所示。
在集中式配置中的每个用户负责将他/她的本地仓库与主仓库同步以便获得其他用户
的更改。这意味着当本地修改的文件被其他人更改和签入时，可能会发生一些冲突。在用
户系统上，有一种冲突解决机制可以处理这种情况
这将帮助你更好地理解。
1．Joe 签入更改。
2．Pamela 尝试对同一文件进行签入更改。
3．服务器提示她的文件副本已过期。
4．Pamela 更新她的本地副本。版本管理软件可能会无缝地合并这两个版本（即没有
冲突）。
5．Pamela 提交一个新版本，其中包含 Joe 和她自己的最新更改。
这个过程在涉及几个开发人员和少量文件的小型项目上是非常好的。但是对于更大的
项目来说，它就会有问题。例如，复杂的更改涉及大量文件，也非常耗时，并且在整个工
作完成之前将一切保持在本地是不可行的。这种方法的问题如下。
● 这是危险的，因为用户可能保留他/她的计算机更改，而不一定备份。
● 很难与其他人共享，直到文件被签入并共享。在完成之前，仓库一直处于不稳定状
态，因此其他用户也不想共享。
集中式的 VCS 通过提供分支（branch）和合并（merge）来解决这个问题。可以从主干修订版本上进行派生，分开进行更改，然后把更改再合回主干修订版本。
在图 8-3 中，Joe 从修订版本 2 开始一个新分支，以开发
新功能。每当有更改签入时，修订版本号就在主干和其分支
上增加。在修订版 7 中，Joe 完成了他的工作，并将其更改提
交到主干（主分支）。这需要，大部分时间用来解决冲突。
尽管它们有优势，但是集中式 VCS 中仍有几个严重的缺陷。
● 分支和合并难以处理。简直就是一场噩梦。
● 由于系统是集中式的，因此不可能离线提交更改。当
用户恢复在线时，这可能对服务器发起一次巨大的单
一提交。最后，对于一些项目它可能无法很好的工作，
例如 Linux，许多公司永久维护自己的软件分支，没有
人人都有一个账户的中央仓库。
对于后者，一些工具可以离线工作，如 SVK，但更根本
的问题是集中式的 VCS 如何工作。
尽管存在这些缺陷，集中式 VCS 仍然在许多公司中颇受
欢迎，主要是由于企业环境的惰性。许多组织使用的集中式
VCS 主要是 Subversion（SVN）以及 Concurrent Version System（CVS）。由于集中式架
构的版本控制系统有明显的问题，所以，大多数开源社区已经切换到架构更可靠的分布式
VCS（Distributed VCS，DVCS）。
分布式系统
分布式 VCS 可以很好地解决集中式 VCS 的缺陷。它不依赖于人们使用的主服务器，
而是基于对等（peer-to-peer）原则。每个人都可以拥有和管理他/她自己的项目的独立仓库，
并且与其他仓库同步，如图 8-4 所示。
在图 8-4 中，我们可以看到这样一个使用中的系统的例子。
1．Bill 从 HAL 的仓库中拉取文件。
2．Bill 对这些文件进行更改。
3．Amina 从 Bill 的仓库中拉取文件。
4．Amina 也更改这些文件。
5．Amina 向 HAL 推送更改。
6．Kenny 从 HAL 的仓库拉取文件。
7．Kenny 进行更改。
8．Kenny 定期地向 HAL 推送他的更改。
关键概念在于人们向或者从其他仓库推送（push）或者拉取（pull）文件，这种行为会
根据人们的工作方式和项目管理方式而改变。由于没有主仓库，项目的维护者需要为人们
定义一个推送和拉取更改的策略。
此外，当他们使用多个仓库进行工作时，人们不得不变得更加聪明一点。在大多数分
布式版本控制系统中，修订版本号对每个仓库都是本地的，并且没有任何人可以指向全局
的修订版本号。因此，标签（tags）可以用来使事情更清楚。它们是可以附加到修订版本的
文本标签。最后，用户负责备份自己的仓库，而在集中式基础设施中则不是这样，通常是
管理员设置备份策略。
分布式策略
当然，如果你在一个公司环境中工作，所有人都朝着共同的目标工作，DVCS 仍然需
要中央服务器。但是该服务器的目的与集中式 VCS 完全不同。它只是一个中心，允许所有
的开发人员在一个地方分享他们的变化，而不是在他们彼此的仓库之间进行拉取和推送。
这样的一个中央仓库，通常称为上游（upstream），也可以作为追踪所有团队成员的各个仓
库中的所有更改的备份。
可以使用不同的方法与 DVCS 中的中央仓库共享代码。最简单的方法是设置一个像普
通集中式服务器一样的服务器，项目的每个成员都可以将他/她的更改推送到一个公共流
中。但这种方法有点简单。它没有充分利用分布式系统的优势，因为人们就像在集中式系
统一样使用推送和拉取命令。
另一种方法包括一个提供多个仓库的服务器，该服务器有不同的访问级别。
一个不稳定的仓库，每个人都可以向它推送更改。
● 一个稳定的仓库，对于除了发布管理员之外的所有成员都是只读的。允许他们从不
稳定的仓库中拉取更改，并决定应该合并哪些内容。
● 不同的发布仓库对应于不同的发布版本，它们是只读的，我们将在本章后面看到。
这允许人们在变更到稳定的存仓库之前，继续贡献，同时管理员可以评审。无论如何，
根据使用的工具，这可能是比较多的开销。在许多分布式版本控制系统中，这也可以利用
适当的分支策略来处理。
可以指定不同的策略，因为 DVCS 提供无限的组合。例如，使用 Git（http://git-scm.com/）
的 Linux 内核基于一个星型模型，其中 Linus Torvalds 维护官方仓库，并从一组他信任的开
发人员中拉取更改。在这个模型中，希望将更改推送到内核的人尝试将它们推送到受信的
开发人员，以便通过他们将更改推送给 Linus。