引言

Subversion（SVN）是一款众所周知的开源的传统代码管理工具。由于其安装和使用简单的特点，能满足基本的代码管理需求，所以被广泛使用。IBM Rational Team Concert（RTC）是构建在 IBM Rational 面向软件交付技术的下一代协作平台 Jazz 平台上的第一个商用产品、一个协作式的软件开发环境，它包含了集成的源代码控制、工作项管理和构建管理等功能。RTC 可以说是一款强大的跨时代的开发管理工具。从其名字中我们就可以看出，它不光是针对代码管理，更注重于将代码管理集成到整个代码的开发周期和团队协作中去。作为产品级开发管理平台软件，有其创新的代码管理的理念及独特实现方式。

本文将面向熟悉 SVN 的 RTC 普通用户，介绍了如何从传统的 SVN 代码管理平台向 Rational Team Concert 2.0 进行迁移，和 RTC 的代码管理理念和方式，以及一些笔者在 RTC 实践当中的小技巧。

在做代码管理迁移前，首先要理解 SVN 和 RTC 在代码管理中一些基本元素和概念的差别，以及两者之间的相似之处

Subversion vs. Rational Team Cconcert 源代码管理中的差异

Check-In/Out 的基本单位

SVN 中，文件是最基本元素，即使当你对一批文件进行 Checi-In/Out 操作时，实际还是对每个文件进行 Check-In/Check-Out。

RTC 中，是以 Change-Set 为最基本单位进行操作。如图 1 所示在一个 Change-Set 中，可以包含若干文件和目录。

图 1. 在 RTC 中，是以 Change-Set 为最基本单位进行操作

RTC 中的代码变更是一个变更集的概念，以一批文件或目录的变更作为一个变更集 Change-Set 来进行管理。这一特性将贯穿到整个 RTC 的代码管理中。

Check-In/Out 控制环境

SVN 中，以命令行方式，或者借助于第 3 方的软件，类似 SmartSVN，TortoiseSVN，RapidSVN 等进行代码的 Check-In/Out 操作。当然也可以通过一些插件与流行 Eclipse 开发环境集成在一起。

RTC 中，则与 Rational 系列软件开发环境（Eclipse）集成在一起。将代码管理控制与 Rational 系列开发工具（Eclipse）紧密集成在一起，将充分发挥 Rational 系列软件套件的优势。

Check-In/Out 版本控制

SVN 中，每次 Check-In 都会生成一个独立的版本号。会给每个 Check-In 的文件或目录打上同一个版本号。Check-Out 时，可以指定版本号进行 Update。

RTC 中，没有了这个版本号概念，这是个区别与以往传统代码管理工具很大的特征。对于如何通过版本号来追溯以前的修改，RTC 中同样提供了 Show History 的功能，如图 2 所示，任何一次的变更集，都可以追溯的到。可以通过 History 来 Discard 任何一次 Change-Set，来回滚到之前的版本

图 2. 变更集都可以追溯的到

对于其他开发者 Check-In 的 Change-Set 可以有选择性的更新到本地开发环境。如图 3 所示对于其他开发者的提交的 Change-Set，开发者在 Accept 到本地开发环境之前，可以查看到作了什么修改，可以选择立刻 Accept 到本地开发环境，或暂时不接受以不影响本地开发，以后再 Accept 下来做 Merge。

图 3. 其他开发者的 Change-Set 可以有选择性的更新到本地开发环境

RTC 独特的 Change-Set 概念可以让开发者更好的处理每次代码的变更，其灵活性这在以往传统的代码管理工具中，是无法做到的。

Tag vs. Base-Line 的差异

说到这里不得不提一下，对于大的变更的版本控制了。

SVN 中，可以通过对当前的代码打 Tag 来进行一次大的变更的记录，其实质就是在服务器端做一次镜像的 Copy。

RTC 中，可以通过对选择一些 Change-Set 集来进行做 Base-Line。其灵活性就在于，你可以根据不同的需求对 Change-Set 挑选，来做一次大的变更的记录，而又不会影响现有团队的开发。而且不同的 Base-Line 可以是有重叠的 Change-Set，也可以没有任何联系。

RTC 以其特殊的 Base-Line 管理方式，极大的方便了对于不同目的的大变更的记录以及追溯。这也是目前其他市场上任何代码管理工具都无法做到的。

代码变更与 Bug Tracking 的相结合。

SVN 中，本身不具备这一功能，但可以使用第三方的工具，例如 JIRA 的 SVN 插件，可以将 Bug Tracking 和代码相结合。

RTC 中，本身就已经集成了 Bug Tracking 功能。可以在 RTC 中，建立类似于 JIRA，Maintis 等 Bug Tracking 工具的 Work Item，将代码变更集（Change-Set）与 Work Item 做关联，可以方便的查阅。如图 4 所示

图 4. RTC 中集成的 Bug Tracking 功能

RTC 中内嵌了 Defect 管理和跟踪功能，可以和所作的 ChangeSet 作无缝关联集成，使其免去了另外构建 BugTracking 系统的成本，也使其超越了市场上任何一款商用代码管理工具。

综上所述，如表 1 我们可以罗列出 2 者的差别

表 1. SVN 和 RTC 的差异

当然了，作为 IBM 一款明星产品软件，RTC 的功能远不只这些，这里只是阐述了针对代码管理这块相关的一些功能与传统工具的差异。

RTC 确实是个好工具，对于已经在用 SVN 的用户，如何把 SVN 的代码搬到 RTC 上去，主要有 2 种方法来实现。

关于 RTC server 的构建就略去不说了，大家可以参考 RTC 的文档，这里只针对代码迁移怎么实施这块儿简单向大家介绍。

将源代码从 Subversion 迁移到 Rational Team Concert 的两种方法

使用 RTC 中提供的 SVN 接口

步骤 1：将现有的 SVN 的代码文件导出成 dump 文件。如图 5 所示：

图 5. 步骤 1

步骤 2：在 RTC 中，选择 File/Import，如图 6 所示选择 SVN Dump File，按 Next。

图 6. 步骤 2

步骤 3：根据 Wizard 提示，如图 7 所示选择刚才从 SVN 导出的 dumpfile，按 Next。

图 7. 步骤 3

步骤 4: 如图 8 选择需要导入的 Component，按 Next。

图 8. 步骤 4

步骤 5：如图 9 选择合适的 [Text file encoding]，按 Next。

这里要注意 SVN 中的文件 encoding 是否统一为选择的 encoding。如果不事先统一 SVN 中文件的 encoding，否则会导致 import 失败。

这里可以在 [Revisions to Import] 选择将 SVN 中的所有 History 版本都导入，或者指定版本导入。

如果不需要保留 SVN 中的 History 的话，推荐可以选择只把最新版导入。因为根据 Dump 文件大小，将所有 History 导入会非常耗时间。

图 9. 步骤 5

步骤 6：如图 10 一般选择不导入 SVN 中的 User，按 Next 即可。

图 10. 步骤 6

步骤 7：如图 11 所示，选择 Finish，导入即完成。

图 11. 步骤 7

作为新建文件导入

这种方式就比较简单了，就是将所有 SVN 的文件 Copy 到本地环境，然后将他们 Check-In 到 RTC 中。这里就不在做累赘说明了。

在正式开始使用 RTC 之前，要针对所有 Team Member 做如何使用 RTC 的培训。关于 RTC 介绍的资料有一大堆，本身 RTC 也自带了许多 Tutorial，都是很好的素材。这里就不做累赘的介绍了。下面是 RTC 使用中笔者的一些使用心得，相信会有助于增进读者对 RTC 的理解。

Rational Team Concert 的使用心得

RTC 中的代码管理结构的规划

SVN 中，目录结构一般为如下的 3 层构架。

SVN

---- Trunk

---- Branch

---- Tag

对于如何在 RTC 中进行规划的问题，可谓仁者见仁，智者见智。如表 2 首先必须要理解下面几个重要名称的概念。

表 2. 几个重要的概念

名称	含义	SVN 中类似项
Stream	存储代码的流，内含多个 Component。	Trunk/Branch
Component	存储代码文件的最小容器，可以按需求建多个。
Workspace	建立用于开发的 Stream 的镜像代码
Base-Line	基于 Change-Set 大变更记录	Tag
Snap-Shot	以 Stream 为单位的大变更记录	Tag

实际使用当中，Stream 和 Component 可以灵活的按需构架，只要适合你的管理需要就可以。如图 12 为项目的不同管理目的构建了 3 个 Stream，分别为 Documentation、Main Development、Release。

图 12. 为项目的不同管理目的构建了 3 个 Stream

RTC 代码流转过程。

下面这张图 13，是大家所必需理解的。不同于 SVN，在 RTC 中，为每个开发者在 RTC Server 端建立了 Personal 的 Workspace，所有的变更在 Local 完成后，将先 Check-In 到 RTC 服务器上 Personal 的 Workspace。然后通过 Deliver 将变更提交到 Stream 中，使其他 Team Member 可以通过 Accept 分享你的变更。

图 13. RTC 代码流转过程

整个过程简单的说就是

步骤 1：开发者 - 甲 Local 修改 -> Check-In -> Deliver to Stream

步骤 2：开发者 - 乙 Accept（开发者 - 甲的修改）from Steam-> Load 到 Local

比起 SVN 来，当中多了一个到 Personal Workspace 的环节，而且并非像 SVN 那样 Check-In 后，就可以直接和其他开发者共享代码。

基本操作心得

具体操作过程中，如何识别 [ RTC 代码流转过程 ] 中的操作呢？如图 14 所示。

图 14. 识别代码流转操作

[Unresolved] 是可以 Check-In 的变更集

1) 当你在 Local 更改了代码文件时，就会出现 Unresolved 目录，里面列出了所有的更改文件。

如图 15 开发者可以将更改过的文件，分成几个不同的 Chang-Set 来 Check-In。

图 15. 分成不同的 Chang-Set 来 Check-In

2) 所有 Unresolved 的变更可以通过 Undo 来随时撤销。

现有 RTC 2.0 版本中，当你打开 Excel、Word 格式的文件，不对其做过变更而直接关闭，RTC 会仍然检测为变更过，实际使用时需要留意。或许在未来版本中会解决这一问题。

[Outgoing] 是可以 Deliver 的变更集

3) 当成功 Check-In 后，会在 Outgoing 目录中出现等待 Deliver 的变更集。

4) 对于还未 Deliver 的 Change-Set，开发者可以随时再次修改，再次做 Check-In。

如果用户想把这次 Check-In 的东西固定下来，再次修改的变更作为一个新的 Change-Set 的话。如图 16 可以把已经 Check-In 的 Change-Set 标记为 Complete。就可以再次 Check-In 新的变更，而又不会影响到你上次作的变更，会在 Outgoing 中出现 2 个针对同一文件的不同的 Chang-Set。这也正是 RTC 对于 Chang-Set 概念的优势体现。

图 16. 把已经 Check-In 的 Change-Set 标记为 Complete 就可以再次 Check-In 新的变更

5) 当我们做 Bug Fixing 的时候，会希望所修改的 Change-Set 和某个 Bug 作关联时，可以如图 17 所示，选择一个 RTC 中的 Work Item 来做 Associate。

图 17. 一个 Change-Set 可以同时和多个 Work Item 来做关联。

6) 当准备做 Deliver 的 Change-Set 与其他开发者的 Change-Set 有冲突时，RTC 中会显示如图 18，这时候可以做 Discard 自己的 Change-Set 或者作 Merge。这点要比 SVN 等传统工具更加人性化，当冲突发生时你可以事先知道，选择对应方法。

图 18. 冲突

[Incoming] 是可以 Accept 的变更集

如果你 local 已经 Load 过关于这个变更集的 Component，当你 Accept 一个变更集时，会自动 Load 到你本地的环境中去。如图 19 显示为 loaded。

图 19. 已经加载的变更集

如果你 Local 没有 Load 过关于这个变更集的 Component，那么 Accept 将只是在服务器端操作。

结束语

本文通过对 Subversion 与 Rational Team Concert 在代码管理上的比较，以及一些实际使用中的经验技巧的介绍，突现了 RTC 在代码管理方面的优势，希望能吸引更多的 SVN 用户向 RTC 管理平台的转移。