1.1. 版权信息

本文档版权归 � 2001 Vivek Venugopalan 所有。根据 GNU 自由文档许可证 1.1 版或自由软件基金会发布的任何后续版本的条款，允许复制、分发和/或修改本文档，无需不变章节、封面文本和封底文本。许可证副本可在 附录 A 中找到。

只要所有副本都保留此版权声明，本文档可以完整或部分地以任何物理或电子媒介复制和分发。允许并鼓励商业再分发；但是，作者希望收到任何此类分发的通知。

所有翻译、衍生作品或包含本文档的聚合作品都必须受此版权声明的约束。也就是说，您不得从本文档创作衍生作品并对其分发施加额外限制。在某些条件下可以批准对这些规则的例外情况；请通过以下地址联系作者。

简而言之，我们希望通过尽可能多的渠道传播此信息。但是，我们确实希望保留本文档的版权，并希望收到任何再分发计划的通知。

1.2. 免责声明

对于本文档的内容，我们不承担任何责任。使用本文档中的概念、示例和其他内容，风险自负。由于这是本文档的新版本，因此可能存在错误和不准确之处，这些错误和不准确之处当然可能会对您的系统造成损害。请谨慎操作，尽管这种情况极不可能发生，但作者不承担任何责任。

除非另有明确说明，否则所有版权均归其各自所有者所有。在本文档中使用术语不应被视为影响任何商标或服务标记的有效性。

特定产品或品牌的命名不应被视为认可。

强烈建议您在进行重大安装之前备份您的系统，并定期进行备份。

1.3. 新版本

本文档版本：0.7。

可以从以下位置获取本文档的最新版本（按最新版本可用性排序）

1. 我的网站

2. Linux 文档项目

1.4. 鸣谢

以下是不分先后顺序为此论文提供信息和更正的人员列表。

1. Jens-Uwe Mager

2. Jorgen Grahn

3. Thomas S. Urban

4. Cam Mayor

5. Sally Miller

6. Niels Jakob Darger

1.5. 反馈

非常欢迎您对本文档提供反馈。没有您的提交和投入，本文档将不会存在。请将您的添加、评论和批评发送至以下电子邮件地址<vivekv at yahoo dot com>.

3.1. 使用 GUI CVS 客户端

本文建议在组织中首次部署 CVS 时使用此类 GUI 客户端。

开发人员通常使用集成开发环境，这些环境将 CM 工具集成到其中。这些工具最大限度地减少了开发人员学习 CVS 使用复杂性的过程，而是让他们从第一天起就能高效工作。习惯于其他 CM 工具的开发人员会觉得 CVS 命令行界面令人生畏。通过使用 CVS 客户端的 GUI 工具，可以提高 CVS 的采用率和使用率。

CVS 的 GUI 工具可在 http://cvsgui.sourceforge.net/ 获取。GUI 界面适用于大多数流行的平台（Windows、Mac 和 Linux）。此外，在 Windows 平台上，有一个 SCC 扩展，允许将 CVS 集成到流行的 IDE 中作为配置控制工具。

4.1. 保持系统时钟同步

CVS 通过使用文件上的时间戳来跟踪对源文件的更改。如果每个客户端系统的日期和时间不同步，则 CVS 肯定有可能变得混乱。因此，必须使用中央时间服务器或类似机制使系统时钟保持同步。

CVS 从一开始就被设计为处理多个时区。只要主机操作系统已正确设置和配置，CVS 就能够正确跟踪更改。

4.2. 不要共享沙箱

沙箱对于每个开发者或目的都必须是唯一的。它们不应同时用于多种用途。沙箱可以是开发人员的工作区，也可以是最终版本的构建区。如果共享此类沙箱，则沙箱的所有者将不知道对文件所做的更改，从而导致混乱。

在 CVS 中，当使用 cvs checkout {项目名称} 命令为 CVS 项目检出工作副本时，会自动创建沙箱。

在非常大的项目中，开发者检出整个源代码到本地沙箱中是没有意义的。在这种情况下，他们可以定期从构建团队获取二进制文件，用于应用程序中所有未被他们更改的组件，并且仅检出由开发者构建的部分。

例如，在 Java 项目中，构建团队可以将他们上次成功构建的结果以 JAR 文件的形式保存在网络文件服务器上的标准位置。个人开发者将使用标准的类路径设置，该设置在标准路径上挂载了网络驱动器。因此，开发者将自动获取他们所需文件的最新版本。

4.3. 与代码仓库保持同步

为了获得在上述沙箱中工作的好处，开发者必须使其沙箱与主代码仓库保持同步。定期使用带有适当标签或分支名称的 cvs update 将确保沙箱保持最新状态。

4.4. 不要在沙箱外工作

沙箱可以被认为是 CVS 可以在其中跟踪对各种源文件所做更改的受控区域。属于其他开发者的文件将由 CVS 在开发者的沙箱中自动更新。因此，在沙箱中工作的开发者将获得并行开发的许多好处。

4.5. 完成工作后清理

确保在完成文件工作后清理沙箱。可以使用 cvs release 命令在 CVS 中完成清理。这确保了开发沙箱中不存在旧版本的文件。如前所述，可以使用构建团队预构建的二进制文件来确保应用程序的所有部分都可供开发者使用，而无需在沙箱中进行完整编译。

4.6. 经常检入

为了帮助其他开发者使其代码与您的代码保持同步，您必须经常将您的代码检入到 CVS 代码仓库。最佳实践是在一段代码完成、审查和测试后立即检入，使用 cvs commit 检入更改，以确保您的更改已提交到 CVS 代码仓库。

CVS 促进并行开发。只有当所有其他开发者定期了解正在进行的更改时，并行开发才有可能。这种意识可以称为 “情境意识”

常见的 “不良” 做法之一是通过电子邮件在开发者之间共享文件。这与上面提到的大多数最佳实践背道而驰。要在两个开发者之间共享更新，必须使用 CVS 作为通信媒介。这将确保 CVS “意识到” 更改并可以跟踪它们。因此，如果需要，可以建立审计跟踪。

5.1. CVS 访问控制

我一直被问到的一个重要问题是，是否能够对 CVS 代码仓库内的文件/文件夹/分支等进行访问控制，以供各种用户使用。不幸的是，CVS 没有内置的访问控制功能，但它确实通过 CVSROOT 代码仓库中的 readers/writers 文件支持一种基本的访问控制形式。我整理了一组脚本，使用 readers/writers 文件来提供稍微可用的访问控制版本。这在 http://cvspermissions.sarovar.org 上作为一个开源项目提供。请随意使用它，并让我知道它对您有何作用。

5.2. 服务器端脚本

服务器端脚本是指在事件发生时使 CVS 服务器执行某些脚本的能力。一个有用的常见脚本是验证所有 cvs 提交都包含开发者输入的注释。该过程涉及设置CVSROOT/verifymsg文件，以便在检入文件时运行脚本。

------CVSROOT/verifymsg---------

#Set the verifymsg file to fire a script
DEFAULT /usr/local/bin/validate-cvs-log.sh


------/usr/local/bin/validate-cvs-log.sh ---------

#!/bin/sh
#
# validate-cvs-log.sh logfile
 
# test that log message has some characters in it
if [ `cat $1 | wc -c ` -lt 10 ] ; then
echo "log message too short; please enter a description for the changes"
    exit 1
else
    exit 0
fi

5.3. 服务器通知

可以将 CVS 服务器配置为在发生提交时通过电子邮件通知。这可以用于验证在每日/发布构建过程中是否正在发生提交。如果发生此类提交，则根据项目策略，可以忽略提交或自动重新启动整个构建。

6.1. 为主干和分支分配所有者

源代码树的主干和各个分支应分配所有者，他们将负责：

1. 维护分支或主干的可配置项列表。

   所有者将是分支或主干的内容列表的维护者。此列表应包含项目名称和关于该项目的简要描述。此列表至关重要，因为新的工件总是在不断地添加到代码仓库或从中删除。此列表将能够跟踪各个分支的代码仓库的新增/删除项。

2. 建立分支或主干的工作策略。

   所有者将建立检入和检出策略。该策略将定义何时可以检入代码（编码后或审查后等）。谁负责合并同一文件上的更改并解决冲突（作者或最近更改文件的人）。

3. 识别并记录策略偏差

   一旦建立策略，往往会有例外情况。所有者将负责识别解决方法并跟踪/记录相同的方法以供将来使用。

4. 负责与主干合并

   分支所有者将负责确保分支中的更改可以在合理的时间点成功合并到主干中。

6.2. 标记每个发布版本

作为发布过程的一部分，必须使用标识符标记整个代码库，该标识符可以帮助唯一标识该版本。标签为一个开发人员的工作副本（通常，该工作副本是完全最新的，因此标签名称附加到代码仓库中的 “最新和最棒” 修订版本）所代表的修订集合提供标签。

标签的标识符应提供足够的信息，以便在未来的任何时间点标识该版本。建议的标签标识符形式如下。

release_{主版本号}_{次版本号}

正如一位读者向我指出的那样，这里的一个好的做法是首先标记发布版本。使用标签检出整个代码库，然后在进行实际发布之前，继续完成构建/部署/测试过程。这将绝对确保 “出门” 的是经过验证和测试的代码库。

6.3. 在每次发布后创建分支

在每次软件发布之后，一旦 CVS 代码仓库被标记，就必须立即创建一个分支。此分支将用作该版本的错误修复基线。仅当该版本首先不是错误修复或补丁版本时，才创建此分支。将来任何时候必须为此版本制作的补丁都将在此分支上开发。主干将用于正在进行的产品开发。

通过这种安排，正在进行的开发的代码更改将在主干上进行，而分支将为热修复和错误修复版本提供单独的分区。

分支名称的标识符可以是以下形式。

release_{主版本号}_{次版本号}_patches

6.4. 仅在分支上进行错误修复

此实践从先前在主要版本发布后创建单独分支的实践延伸而来。该分支将用作所有错误修复和必须进行的补丁版本的代码库。因此，存在一个单独的代码仓库 “沙箱”，可以在其中独立于主流开发来开发热修复和补丁。

此实践还确保对以前版本进行的错误修复不会神秘地影响主流版本。此外，添加到主流版本的新功能不会意外地渗入到补丁版本中。

6.5. 仅从分支进行补丁发布

由于给定版本的所有错误修复都在其对应的分支上完成，因此补丁版本是从分支制作的。这确保了对作为补丁版本一部分发布的功能集没有混淆。

在制作补丁版本之后，必须使用发布版本标记实践标记分支（请参阅 标记每个发布版本）。

7.1. 发布后将分支与主干合并

在每次从分支发布之后，对分支所做的更改应与主干合并。这确保了对补丁版本所做的所有错误修复都已正确纳入应用程序的未来版本中。

根据对主干和要合并的分支所做的更改量，此合并可能会非常耗时。实际上，它可能会导致 CVS 中出现大量冲突，从而导致手动合并。合并后，必须测试主干代码库以验证应用程序是否处于正常工作状态。在准备项目计划时必须牢记这一点。

如果分支上的更改持续很长时间，即使在发布版本制作之前，也可以定期将这些更改合并到主分支。合并频率基于分支演变中的某些逻辑点完成。为了确保不会发生重复合并，可以采用以下实践。

除了分支标签之外，还应创建一个名为 {分支名称}_MERGED 的标签。最初，这与分支的最后一个发布版本标签处于同一级别。然后通过使用 -F 选项在每次中间合并后 “移动” 此标签。这消除了中间合并期间的重复合并问题。

8.1. 尽早并经常构建 (BEBO)

这个格言的变体在开源社区中已经流传了一段时间，称为“尽早发布并经常发布”，尽管原因不同。BEBO 帮助开发团队识别可能因检入错误文件而引起的问题。BEBO 将解决应用程序级别的集成问题，这些问题可能已在单个开发者构建中被忽略。当团队看到应用程序的工作版本时，它也将提高团队士气。

必须定期进行构建。应分配专门的资源来执行相同操作。必须对整个项目团队进行培训，以将每日构建视为一项重要活动，而不是一项苦差事。必须定期完成构建，且不能出现任何失败。构建失败必须是罕见事件，应以最严肃的态度对待。项目团队应确保成功构建是他们的首要任务。可以通过设置打破构建的惩罚来强调其严肃性。

可以使用标准命名约定在 CVS 中标记每个构建。这可以帮助开发者从每日构建中检出一个完整的系统工作版本，以进行本地开发。

8.2. 完全自动化构建过程

软件构建的另一个关键实践是完全自动化构建过程。自动化过程还必须包括从 CVS 代码仓库自动检索正确的源文件。这确保了构建过程是完全可重复和一致的。此外，在很大程度上减少了使用错误版本的应用程序源文件进行构建的可能性。

通过自动化构建过程，经常构建的任务变得不那么繁重。

8.3. 所有必要文件必须在构建前检入

这个格言乍一看似乎微不足道，但即使是经验丰富的开发团队，由于疏忽，这个问题也很常见。疏忽问题不容易解决，因为责任在于个人开发者，以确保他的文件已检入。应以培训和构建前公告的形式向团队灌输这种实践，以确保代码仓库中提供正确版本的源代码。

如上所述的自动化构建过程将有助于在一定程度上发现此问题，因为它们将自动从 CVS 代码仓库获取源代码并执行软件构建。任何遗漏的项目都将在构建过程本身（makefile 等）或产品回归测试期间（检入的旧版本文件）浮出水面。

可以建立基于惩罚的系统来处理错误的检入。为项目结束后聚会设立一个 kitty，每个进行错误检入的人都将贡献固定金额，这将是一个很好的惩罚系统。

9.1. 实施变更管理流程

所有组织都必须实施良好的变更管理流程 (CMP)。良好的 CMP 将定义如何接收、记录、跟踪、执行和交付变更。CVS 为您的项目提供版本控制。变更管理解决了如何接收、跟踪和关闭增强功能和错误问题的 “大局”。CVS 将在这个大局中发挥较小的但非常重要的作用。通过在组织中建立正式的变更管理流程，诸如 CVS 之类的工具将被视为辅助此流程，而不是充当一般的开发开销。

变更管理是一个非常广泛的主题，在此无法公正地介绍。请查找其他关于变更管理的信息来源。

9.2. 将 CVS 使用纳入目标

为了将 CVS 制度化，可以将其作为开发者在项目中绩效目标的一部分，即使用 CVS。此外，也可以将其作为项目经理在其项目中部署 CVS 的目标的一部分。

然后，可以将对此的遵守情况作为员工评估周期的一部分进行审查。

9.3. 收集 CVS 使用指标

可以收集 CVS 使用指标，例如在组织中的部署百分比、处理的项目规模等。此信息将促使其他部门经理和项目经理将 CVS 视为一种可以帮助他们日常运营的工具。

10.1. 初始阶段

考虑一个软件项目，其中 1.0 版本刚刚投入生产，每个人都庆祝完毕。下一步是开始处理后续版本的新功能。此外，系统的用户已开始全职使用它，并且各种级别的错误报告已开始涌入。

在投入新的增强功能或错误修复之前，应遵循 分支与合并 的最佳实践。一些重要的实践是 标记每个发布版本 和 在每次发布后创建分支。这些实践将有效地建立两个 “开发环境”，一个用于常规增强功能，另一个用于上次发布的错误修复和小增强功能。

让我们假设发布版本被标记为

release_1_0

然后使用分支名称创建分支

release_1_0_patches

10.2. 开发与交付

现在，我们准备开始工作了。让我们来检查一下缺陷修复和增强跟踪。假设有三个缺陷，其中两个是高优先级的，应该立即修复（可能在一周内），第三个可以在稍后交付（比如 4 周后）。在这个时间表的中间，计划在三周后进行一次常规发布。考虑到我们接下来会有一个繁忙的月份，让我们看看如何才能准确地使用最佳实践来轻松度过接下来的日子。

下个月各种发布的计划时间表如下所示。

             Fix       Enhancement  Fix 
     Today   Release 1  Release    Release 2
	 |_______|______________|_________|
		    Time -->

我们有两个团队，一个团队在缺陷修复分支上工作，另一个团队在主干上为下一个版本开发新功能。这些团队必须确保他们从沙箱中的正确版本开始工作。

1. 缺陷修复团队将使用命令行检出代码

   cvs checkout -R -r release_1_0_patches {项目名称}

2. 从事下一个版本开发的团队将使用命令行

   cvs checkout -R {项目名称}

一旦缺陷修复团队完成了两个最高优先级的缺陷，他们将更新、验证构建成功，并将他们的更改提交到缺陷修复分支，使用命令行

团队应该在此处执行构建，以验证更新是否没有破坏分支上的任何代码。一旦构建成功，分支应该被提交回代码仓库。

尽早构建，频繁构建 : 每天，每个开发人员都会向 CVS 提交代码，为了确保代码的健全性，缺陷修复分支上将进行每日构建，方法是从干净的环境中从 CVS 检出代码并完全重建。这些每日构建可以使用以下命名约定在 CVS 中标记

build_1_1_yyyymmdd : 用于分支
build_2_0_yyyymmdd : 用于主干

遵循构建-测试-修复的常规流程，使版本准备好交付。标签将帮助开发人员在必要时检出最新构建的工作副本。

当源代码发布到外部世界时，必须遵循两个实践。

1. 标记每个发布版本 : 这确保了缺陷修复版本被正确标记，因此可以在以后必要时追溯出来。

2. 在发布后将分支与主干合并 : 这确保了缺陷修复被合并回主干，从而确保所有未来的发布都是真正的累积交付。