Subclipse 入门指南和参考(三)

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"，在指定分支修订和主干两者之间应用更改也算是使用合并，仅仅是把固有的角色颠倒过来而已。