原创作者: lovefly_zero   阅读:15704次   评论:0条   更新时间:2011-05-26    

Subclipse任务

典型作业周期:编辑、更新、提交

 

    SVN和大多数其他SCMs系统一样,一旦您签出您的项目,或与他人共享,大多数情况下您所要做的只是如下一个简单周期:

  1.  编辑
  2.  更新
  3.  提交

   在Eclipse中,SVN插件利用Eclipse的Team专题结合了SVN的特殊功能,使得维护这一周期变得非常容易。

 

   题外话:这里的SCM不是指传统理解的供应链关系管理,而是指源码控制管理

  编辑工作副本

    当您编辑工作副本时,您观察一下资源中的记录(如文件,文件夹等等),就会发现Navigator视图和其他视图一样,都是基于同样的信息,比如Java开发工具条(Java Development Tools)的Package Explorer

    只要你使用Eclipse操作您的工作副本,Eclipse将捕获您的改动和重构。您可以对比一下SVN的命令行工具,在您的工作副本上执行有关重命名、删除和移动操作。Eclipse的SVN插件同样能实现这些需求。

    在增加资源时有一个特殊情况:您创建的新文件或文件夹必须添加到您的工作副本,在你新增资源上,右击上下文菜单选择"Team"菜单的"Add to Source Control"命令。如果您不这么做, SVN插件会在资源旁边显示一个问号(?),也就是说,一个未知的文件出现在您的工作副本里。然而一旦增加它(们),资源就会变成用星号(*)标注。最后,当您提交了你的更改,该标记就会消失。如果您想忽视添加的一个资源,它仍然会出现在提交对话框中,但默认未被选中。

    想要确保独占式访问一个要编辑的文件,如果您的版本仓库是基于SVN 1.2或更高版本,您可以锁定(lock)它。

 其他人提交改动时更新工作副本

    当您在执行编码、编辑、调试等等的时候,其他人(如果您是在一个团队内工作)也可能改动这个项目。为了跟上进度,在每次做事之前您必须更新它们,即使当您的改动是稳定的。您也应该在提交您的工作之前立即更新它们。项目资源中您修改的每一部分更新都会被关注,SVN会尝试合并这些更改。这将在您的更改和存储库中的更改不发生重叠的情况下产生效果,但是,如果更改是相互冲突的,您的工作副本中受影响的资源将被标记为被抵触,接着一些文本标记将释放出来,并由此引出在存储库和您的更改之间的那些差异。这些冲突可以选择手动修正,或者通过"Team"菜单中的"Edit conflicts "命令修正(它们)。如果您通过编辑文本来解决更改,您需要标注冲突的解决。
    最极端的做法就是恢复(revert )您自己做的更改并重新开始。

 提交更改至存储库

     一旦您对当前的更改感到满意,现在就提交(commit)它们至存储库吧。SVN会让你提交的更改保持同步,并会强制你更新每一个冲突,但是仅仅当受影响的资源必须更新时才会去覆盖它们。不管怎样,如果依赖的资源(例如,您更新的文件对一个程序文件是必需的)进行了更新,提交后将不会校验它们原有的关系。这就是为什么您需要首先更新和检查您所做的更改的原因了。

 

使用同步视图

概述

   如果您想看到您的工作副本的总体状况,包括任何更新,并和存储库的状况进行对比,同步视图就是非常有用的。该视图主要关注入局和出局模式的改动,入局(inbound)改动是指其他已提交的和即将在您的工作副本中同步时的改动。出局(outbound)改动关注的是你提交到存储库的诸如编辑、删除或增加本地资源的一系列结果。

   总之,同步视图为更新和提交您的工作提供了另一种视角,这样做在一定程度上能让您做为Eclipse用户感觉更贴切吧。

 

创建和应用补丁

概述

    通常,当工作的项目在很多开发者间共享时,您需要在他们没有提交的时候做审查和可能的传递改动的工作。为了加速开发进程,SVN提供了创建补丁的功能,它和Eclipse的内置功能一起工作,以应用补丁。补丁是对更改到存储库状态里的某个特定版本的表述,可以很容易传递给其他开发者;例如,当一个开发者(他没有提交权限)需要提交一个改动时,有人能审查改动并提交它。

创建补丁

   选择您的项目或者文件夹/文件,右击"Team">"Create patch..."选项。保存补丁到一个文件,然后通过Email或者类似恰当的途径分发它们。


 您必须在创建补丁之前使用"Team" > "Add to Version Control"选项把新文件包含在补丁程序中。这将告诉SVN把它(们)包含在补丁里。
 

 应用补丁

    选择您的项目或者某个文件夹/文件,右击"Team">" Apply patch..."选项。它将引导您完成向导,先让您指定补丁的位置,接着把它应用到你的项目副本里。

维护SVN分支

    跟许多其他SCMs系统一样,SVN也有“同一项目不同分支一起工作”的概念。也就是说,存储库的某些部分基于不同的开发基线是而彼此独立。但是设置的改动有可能在一起工作,包括对照全部的分支和复制分支之间的改动。 

    一般来说,项目中开发的"main(主要)"基线在SVN中被称为trunk(主干),但这不是一个技术要求,而是一个约定。

    SVN库模型不同于CVS(支持标记/版本和分支在同一路径的机制),支持"产品副本"方式的分支和标记。因为复制相对简洁,并且针对具体资源的追溯更加简化。通常SVN存储库把存储小组归纳为三类:

  • trunk(主干)-项目开发的主线,也是最主要的,开发者们通常要针对它定期提交一些改动
  • tags(标记)-在自定义的时间点上主干(或分支)的一组快照,例如产品发布日。
  • branches(分支)-相比项目中的主干(甚至其它分支)而言,它是很活跃的变种。当开发当中的一个(大)改动需要团队内加以协调,或者单一工作副本的工作中进行项目变更已不可行的情况下,这就非常有用。

虽然这约定大致相当于CVS结构关于标记(版本)和分支的使用方式,但选择何种方式完全取决于您(和您的团队),在定义和设置存储库的过程中您应考虑到这一点。

     如果您按推荐的方式创建存储库,那么您在谈论标记、分支和合并时就会更加清晰和明了。

标记

   如果一个项目的大部分工作都已经在存储库的“主干”里完成,您可能需要在存储库里“保存状态”,例如当你为一个随之而来的产品或者里程碑发布一个版本。当然,你也可以仅仅记下你当前的修订号,然后你可以一直使用该信息以重建项目内容,或者与之对照等等。然而,你也可以给一个明确的标记名称,以方便查阅。

 

    比较:在SVN命令行中,完成它只需通过使用 svn cp 复制存储库地址(如http://svn-server/bigproj/trunk/ )到一个新的、不同的地址(如http://svn-server/bigproj / tags/client-release-0.99 / )。

 

   使用Eclipse插件,您右击"Team"菜单可发现"Branch/Tag..."功能。

   按照约定,您决不能在一个存储库的"标记(tag)"位置上提交任何东西,它们仅仅因一个明确的存储库修订而存在。尽管如此,也没有任何操作会阻止您的提交到"标记(tag)"位置(虽然Create Branch/Tag对话框在发现URL中包含"tags"字符时对您提出警告)。标记(Tags)仅仅是SVN的约定。如果您需要复制一份拷贝在不同的目录工作的话,使用一个分支。尽管如此,事实上您有提交到一个标记(Tags)文件夹也是有一些好处的。因为您更希望可以在标记上有这些更新,包含版本号和(或)发布日期的一些文件。

 分支

    创建一个分支和创建一个标记一样,都是一个基本存储库的副本。如果您需要紧接着在分支里工作,就使用相同的工作副本(即您的Eclipse项目),右击 'Team > Switch'命令来切换到新的位置。

    如果您面对许多的改动,而您希望仅为这次操作设置一个分支,一定要清除"create a copy on the server"复选框(正如命令字义中的说明:您本地所做的修改将被应用到您想要复制的基础版本里)。

 选择一个分支或标记工作

   创建一个分支或标记不会改变您的工作副本。相反,您需要切换到新创建的存储库地址(或者其它子地址)。

   注意:您不需要切换整个项目,你甚至可以切换到任意级别文件夹或者单独文件,但是在一次提交前,这么做会让分析所做的改动时更加难以理解。

 合并改动

     如果一个分支工作有赖于分支维护人员在主干上定期维护改动,这些改动可能会合并到分支里。要这么做可使用'Team > Merge',它可以适用于在主干上两次不同修订之间比较差异。

例如:爱丽丝和其他两个小组成员鲍勃和查理一起在“X”项目中工作。爱丽丝需要对用户界面做重大的调整,因此她在主干上创建一个叫"gui_changes"的分支。这次提交是基于修订号8。当时爱丽丝切换到这个位置,离开项目主干并按她所希望的独自操作,稍后她在分支中提交了一些改动。而与此同时,鲍勃和查理也一直在主干上工作,并使整个存储库的修订达到了12(请记住,修订号计数器是公共的,只要有任何改动就会有增长。)

为了跟上团队的开发速度,爱丽丝需要把主干上产生的改动添加到她的分支中。可通过“Team”菜单中选择'Team > Merge...'达到这个目的,输入她希望切换的项目的正确网址。如果对话框显示 http://svn-server/sw-dev/branches/gui_changes/project-x/,她将不得不修改到 http://svn-server/sw-dev/trunk/project-x/,在"from"修订处输入’9‘,然后在"to"修订处输入"12(或者HEAD)",然后合并。这将使她的工作副本获得主干上最新的改动,她就可以把它们提交至分支(一旦有任何的冲突,您就必须首先解决[冲突])。

    :最好在合并改动时使用一个“干净”的工作副本(即没有更改),这是一个好的思路,因为您有可能提交分歧(也仅仅是分歧)、记录相应的修订。一些SCM系统能够自动化监控它们(使用“变更”),但是SVN还做不到(虽然未来的版本已将此功能提上日程)。

在分支中应用更改

    从一个分支恢复到主干时应用更改,反之亦然,详见合并文档。

Backporting

   有些分支仅仅用来维持副本或发布准备,然后清除。但是,有时候分支提交的更改很有用,你可以把它放入项目主干。这一个过程为称为"backporting",在指定分支修订和主干两者之间应用更改也算是使用合并,仅仅是把固有的角色颠倒过来而已。

评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

文章信息

Global site tag (gtag.js) - Google Analytics