两种在 Rational Team Concert 中融合不同步代码的方法

转自:http://www.ibm.com/developerworks/cn/rational/r-cn-rtccodesync/index.html

软件开发过程中,由于软件越来越复杂,开发规模越来越大,不可避免地出现多个软件工程师修改同一文件的现象。这就直接导致了软件工程师开发环境上的代码与服务器上的代码不同步的问题。在这种情况下,软件工程师必须将自己的修改融合服务器上最新的代码后,再上传到服务器上。

Rational Team Concert(RTC)是一个功能强大的软件生命周期管理工具,它的源代码控制管理模块使用简单、灵活。本文主要介绍两种在 RTC 中如何将不同步的代码进行融合的方法,并对这两种方法进行了比较,提出它们各自的适用情形。本文适用于所有使用 RTC 进行软件开发的工程师,帮助他们更加了解 RTC 的源代码控制功能,以期提高他们的工作效率。

Rational Team Concert(RTC)是 IBM 基于灵活、可扩展的 Jazz 平台上推出的一个集软件生命周期各阶段所需管理功能为一体的工具,功能强大、使用方便,且易于定制。它提供基于 Eclipse、Microsoft Visual Studio 和网页浏览器的三种客户端。RTC 功能之强大,是目前市场上少有的,它可以为软件架构师提供软件需求和架构设计管理功能;为项目经理提供软件规划,项目管理,报表功能;为 build 团队提供软件版本构建的管理功能;测试团队提供简单快捷的测试管理工具;为开发团队提供灵活易用的开发环境和丰富的源代码控制功能。

RTC 的源代码控制模块以组件来管理源代码、文档和其他附件,类似于其他源代码管理工具中的分支,它由多个组件组成;组件,则是源代码、文档和其他附件的集合,它们之间的关系如图 1 所示。开发人员可以使用 RTC 进行软件开发、源码共享、更新和同步等操作。本文将以 RTC 的 Eclipse 客户端为例,介绍如何使用 RTC 的源代码控制功能融合不同步代码。


图 1.RTC 源代码控制管理层次图
图 1.RTC 源代码控制管理层次图

在 Rational Team Concert 中如何发现代码不同步

在 RTC 中,提交一份代码需要如下步骤:创建一个变更集 , 将在本地工作区修改过的代码添加进变更集中,然后将变更集检入到用户在代码服务器上的存储库工作区,在该工作区上的代码只对用户本身可见,对于其他用户是不可见的。最后,将变更集交付到代码服务器上,这些修改过的代码才是真正地进行了发布,其他用户才可以看见它们。

RTC 有一种代码控制视图叫暂挂的变更。在该视图里,用户可以看到自己工作区中的代码跟代码服务器上的代码的差异。这些差异代码在该视图中被分为三种子集 : 未解决传出传入。其中,未解决子集包含了用户在本地工作区中做了修改,但并未进行检入操作的代码;传出子集包含了用户在本地工作区中做了修改,并已经检入到用户在代码服务器上的存储库工作区中,但是并未最终的交付的代码;而检入子集则是包含了其他用户已经修改,并进行检入交付的代码。同其他的代码控制工具相比,这种以集合的方式显示代码差异,十分直观、清晰。并且暂挂的变更视图是实时刷新的,一旦团队里的其他成员更新了服务器上的代码,传入集合会即时更新,这种无延时的信息传递,将大大提高团队协作效率。

如果存在某些代码文件,既在未解决检入集中,又在传入集中,则该用户本地工作区的代码跟代码服务器上的代码出现了潜在冲突。在 RTC 中,潜在代码冲突用图标 潜在代码冲突用图标 表示,值得注意的是,如果潜在冲突代码还未进行检入操作,则该图标不会出现在暂挂的变更视图上,它只会出现在包资源管理器视图上冲突文件图标的左边,如图所示:


图 2. 未检入的冲突代码
图 2. 未检入的冲突代码

如果潜在冲突代码已经被检入到用户在服务器上的存储库工作区上,则在暂挂的变更包资源管理器这两个视图上都可以看到潜在冲突文件及其图标。作者建议在暂挂的变更视图上查看冲突的文件更为直观。在该视图下,点击传出集合中的一个潜在冲突文件,传入集合中的相应文件会高亮显示,反之亦然。暂挂的变更视图下,已检入的潜在代码冲突如图所示:


图 3. 已检入的冲突代码
图 3. 已检入的冲突代码

如何使用 Rational Team Concert 进行代码融合

当软件工程师发现代码不同步时,应该如何使用 RTC 同步呢?RTC 提供了两种方式融合不同步代码。一种是传统的合并方法,另一种是独特的打补丁方法。

传统的代码“合并”方法

和所有的代码管理工具一样,RTC 提供的传统合并方法也分为自动合并手动合并功能。其中,自动合并功能只能合并非冲突性的变更,即变更是简单的非同一行内的添加或者删除代码。如果变更中含有冲突性变更,则无法使用自动合并功能。所以,在大多数情况下,用户还是需要使用手动合并功能。下面介绍一下如何手动合并冲突性代码。

  1. 接受其他用户的变更集

在进行代码合并之前,用户需要先接受其他用户的变更集。具体操作是,右键点击其他用户的变更集,在弹出的菜单中选择接受项,如图 4 所示。


图 4. 接受其他用户的变更集
图 4. 接受其他用户的变更集

如果此时,你的本地工作区中尚有未检入的变更,RTC 会出现如图 5 所示的提示,要求用户选择后续动作。检入并接受表示先检入用户当前的变更,再接受其他用户的变更;接受则是在不检入用户当前变更的情况下,接受其他用户的变更,此选项不会导致其他用户的变更直接覆盖掉自己本地工作区上的变更。点击接受按钮,当 RTC 在执行接受动作时,如果发现所接受的变更集里有文件已经在本地被当前用户修改过,则此变更集跟本地工作区的代码具有潜在性的冲突,会弹出如图 6 所示的对话框,询问用户是否需要 RTC 自动解决此潜在性冲突。用户可以点击自动解决让 RTC 先帮你自动合并代码。


图 5. 未检入的变更提示
图 5. 未检入的变更提示

图 6. 自动解决冲突
图 6. 自动解决冲突

  1. 手动合并冲突性变更

如果变更中存在冲突性的变更,则用户需要进行手动合并。如何进行手动合并呢?RTC 使用 Eclipse 的比较编辑器来实现用户手动处理冲突代码的功能,将比较编辑器集成于 IDE 环境,能够做到实时编译所做的修改,即时知道所做修改是否带来编译冲突,提高工作效率。用户接受了其他用户的变更后,会在暂挂的变更视图中的未解决子集中看见需合并图标 需合并图标,所有的冲突文件边均有此图标。右键点击该文件,在弹出的菜单中选择在比较编辑器中打开,如图 7 所示。


图 7. 在比较编辑器中打开
图 7. 在比较编辑器中打开

此动作将会把比较编辑器打开,如图 8 所示。比较编辑器的上部分是 Java 结构比较,显示了 Java 结构上变量和函数等成员的冲突,下部分则是 Java 源代码比较,显示了具体的 Java 代码冲突。左下部分是用户本地工作区上该文件的版本,右下部分则是该文件在代码服务器上的版本。双击结构上的冲突,编辑器的下部分会自动跳转到对应的 Java 代码冲突。用户可以在左边的区域编辑该文件,作为最终合并的结果。如果需要将服务器上的某些代码覆盖本地的代码,则选中该段冲突代码,点击 Java 源代码比较窗口右上角的 将右边的代码复制到左边 按钮,将右边的代码复制到左边。


图 8. 在比较编辑器中合并代码
图 8. 在比较编辑器中合并代码
查看大图

  1. 确认合并结果,解决冲突

在比较编辑器中根据实际情况合并完代码之后,点击保存按钮,保存合并结果。然后点击比较编辑器右上角的按已合并进行解决按钮,让冲突按照用户手动合并的结果解决代码冲突。此时,RTC 会弹出一个对话框,跟用户确认是否要按合并的结果解决冲突,如图 9 所示,点击确定按钮。RTC 会将手动合并的结果自动加到未解决子集中,以便用户将此变更交付到代码服务器上。


图 9. 确认按已合并的结果解决冲突
图 9. 确认按已合并的结果解决冲突

使用打“补丁”方法进行代码融合

相较于其他传统源码控制工具,补丁是 RTC 特有的东西,它是一种可存储的变更集。补丁反映了当前用户本地工作区中的某个工程代码与服务器上工程代码的差异,它可以以“*.patch”为名的文件形式保存在存储介质上,以便以后可以被重新应用到代码工程上,实现代码融合。这种便于存储变更集的补丁使得团队内部的代码共享和同步更新更加便捷、灵活,突出体现了 RTC 在团队协作管理方面的作用。下面就介绍一下如何使用补丁进行代码融合。

  1. 将本地变更生成“补丁”

当代码不同步时,用户可以创建一个补丁,将本地工作区上所有不同步代码保存起来。具体操作为:选择一个或多个代码文件(这些文件既可以在未解决集合中,也可以在传出集合中),右键点击代码文件,在弹出的菜单中选择新建 -> 补丁…,如图 10 所示:


图 10. 选择文件生成补丁
图 10. 选择文件生成补丁

用户在生成补丁时可以选择将补丁保存在本地存储器上,也可以选择将补丁暂时粘贴在剪贴板上,如图 11、12 所示。将补丁保存在本地存储空间上时,用户需要提供存储路径和补丁的文件名。而将补丁暂时粘贴在剪贴板上是一个比较方便,快速的动作,用户只需要按下“确定”按钮,补丁就会被自动缓存在系统剪贴板上。值得注意的是,放置在剪贴板上补丁需要尽快被应用到用户本地工作区上,以防补丁被覆盖或者丢失。


图 11. 永久性保存补丁
图 11. 永久性保存补丁

图 12. 暂时性保存补丁
图 12. 暂时性保存补丁

  1. 撤销本地变更,接受其他的用户变更集

由于本地变更已经以补丁的方式被保存下来了,所以在接受其他用户的变更集之前,用户可以放心地撤销自己本地工作区上的变更,在无冲突的状态下接受其他用户的变更集

如果变更并未被检入,即存在于未解决集合中,则右键点击该冲突文件,在弹出的菜单中选择撤销,撤销文件变更,如图 13 所示。此撤销动作将撤销掉所有的变更,并且不可恢复,所以在未解决集合上执行“撤销”动作之前,请确认已将变更生成补丁并保存。


图 13. 撤销文件变更
图 13. 撤销文件变更

如果变更已经被检入,即存在于传出集合中,则右键点击变更集,在弹出的菜单中选择废弃项,如图 14 所示。此废弃动作亦为不可恢复的,所以请先确认是否已将变更集生成补丁,并保存下来。


图 14. 废弃文件变更
图 14. 废弃文件变更

在放弃掉自己本地的变更之后,用户便可在无冲突情况下接受其他用户已经交付的变更集,具体方法,前面已有详述,这里不再重复。

  1. 给代码打“补丁”

接下去,我们需要将刚才生成的补丁,重新打回代码工程上,实现代码融合。在 RTC 菜单栏上选择项目 -> 应用补丁…,在弹出的窗口中选定先前创建的补丁,单击完成按钮,导入补丁。导入成功后,会有如图 15 所示的提示,RTC 已经将补丁添加到暂挂的变更视图中的“暂挂的补丁”节点下,如图 16 所示。


图 15. 已将补丁添加到暂挂的变更
图 15. 已将补丁添加到暂挂的变更

图 16. 暂挂的补丁
图 16. 暂挂的补丁

右键点击该补丁,在弹出的菜单中选择合并到工作空间…项。RTC 将自动把这个补丁打到项目上,即实现自动合并功能。如果有些不能自动解决的,则参照前面所述方法手动合并这些变更。

记住,请及时的将修改的代码检入到服务器上,避免产生过多的冲突,给代码融合带来很大的困难。

传统的“合并”方法与新颖的打“补丁”方法比较

这两种方法都提供一定的自动融合不同步代码功能,同时也提供了手动融合以解决代码冲突。但是最主要的区别是,打补丁方法,会生成变更补丁,该补丁可以作为一种代码备份。当融合代码时,有大量的代码冲突存在、融合难度比较大时,建议使用打补丁的方法。因为使用该方法,你会对你的变更做备份,它允许你在发现融合错误后,撤销一切,重新应用补丁。此外,补丁还可以共享给其他用户,其他用户可以将补丁打到自己本地的工程上,从而实现变更的传递。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17117101/viewspace-621818/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/17117101/viewspace-621818/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值