eclipse cvs特殊情况及其处理

这里将给出一些您每天或在软件开发周期中可能会碰到的常见情况，以及如何使用Eclipse来处理这些情况的建议。某些情况的解决可能需要使用CVS，但通常只使用Eclipse就可以处理它们。

1   对项目资源进行重命名、移动和删除
●        避免重命名CVS控制之下的项目。如果您这样做了，那么所做的命名修改只在该项目所处的工作空间中有效。保留在CVS中的仍是该项目的初始名。如果必须修改项目的名称，那么您最好先使用Team | Disconnect…操作来解除该项目与CVS的关联关系，然后再对该项目重命名。事实上，重命名后的项目会被看作是新项目。在将重命名后的项目重新连接到CVS时，您必须像定义任何新项目一样将该重命名后的项目定义到CVS中。

●        对文件夹的重命名操作会导致CVS中出现一个新文件夹。幸运的是，原文件夹中的内容会被移动到新文件夹中。如果您启用了CVS首选项Prune empty directories，那么在从CVS检出资源后，该旧文件夹将不会出现在您的工作空间中。

●        如果您将工作空间中的某资源删除了，那么在向CVS提交了更改后，保存在CVS中的该资源也会被删除。要记住的是文件夹决不会在CVS中删除。CVS首选项Prune empty directories使得这些文件夹隐藏在视图中。默认情况下，CVS首选项Prune empty directories是被启用的。

●        因为修改可能会涉及多个项目，所以在进行全局修改前，您需要确保工作空间中的所有项目是资源库中的最新版本。Java类的重构是一个可能导致工作空间被广泛修改的操作。项目间的资源移动也可能产生这种影响。

●        在CVS透视图中，项目之间资源移动的结果是：所要移动的资源添加到目标项目中，而源项目中的该资源会被删除。移动到目标项目中的资源必须被添加到版本控制中。而资源重命名的效果与此相同。

●        在文件被修改后，如果您要执行诸如同步等CVS操作，那么我们建议您在项目层次上进行同步(即使您的更改可能仅涉及一个单独文件)。例如，如果您对一个文件进行了重命名这一CVS的删除和添加操作，那么在文件层次上的同步将只会检测添加操作而不检测删除操作。而项目层次上的同步则会对添加和删除操作都进行检测。

●        在所进行的修改涉及整个应用程序的情况下，您应该将这次修改通知给自己所在的小组，以避免不必要的冲突。此时，一旦条件满足，您就应该提交修改。冲突的解决可能是冗长乏味而又难以解决的。

2   取消修改：使用替换和比较操作
有时，我们都希望事情能够重新开始。在人的一生中，这可能不容易。但是对于Eclipse和CVS来说，这要简单得多。根据您的需要，您有多种选择。在先前的几章中，您看到了如何使用快捷菜单操作Replace With和Compare With用工作空间中的本地历史记录来替换和比较资源。通过使用CVS，您对资源的替换和比较操作就有了额外的选择。如果您尚未最终完成某个修改，而且之后一段时间里根本就没有继续这次修改。这种情况下，Compare With操作可能会非常有用，它会使您记起上次停止修改的地方。在使用上述Replace With和Compare With操作时，您是用来自HEAD流(或者其他分支/版本、某一个具体版本)的最新资源来替换或比较当前资源的。

3   通过建立分支来进行版本维护和新版本开发
在小组已经交付了您的应用程序并准备开始下一个版本的开发工作时，您可能喜欢所有的后续开发能在下一版本所指派的特定分支处开始，同时还要允许先前版本的服务。这里所给出的就是在Eclipse中可用的一种方法。

●        在包含了最近已完成版本的分支(或HEAD)中，请选择所有的项目。然后在所选项目上使用Branch…快捷菜单，并输入该新版本的新分支名。这样，所选择的全部项目以及这些项目的内容将用下一个版本分支名来标记。在CVS Repositories视图中，这些项目会被列在那个分支名之下。在从那个分支处将这些项目检出到您的工作空间之后，接下来的操作是基于该新版本分支的。

●        您可重复上述过程以创建一个单独的维护分支。该维护分支独立于上面所创建的新版本分支。

●        为了能以维护分支为基础，在工作空间中对新版本分支进行合适的前向修改，您可以通过使用Compare With | Another Branch or Version…操作来确定这两个分支之间的差别。在Compare视图中，您可以手动合并从维护分支到新版本分支的更改。