一旦创建 RepositoryProvider,就应理解其它资源管理机制:
在某些情况下,可能不必让存储库控制某些文件。例如,从现有资源派生的资源通常会在存储库中被省略。例如,已编译源文件(例如,Java“.class”文件)可能会被省略,因为它们的对应源(“.java”)文件在存储库中。对存储库提供程序生成的元数据文件进行版本控制也是不适当的。org.eclipse.team.core.ignore 扩展点允许提供程序声明应对存储库提供程序操作忽略的文件类型。例如,CVS 客户机声明以下内容:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
标记简单地声明应被忽略的文件名模式和在首选项对话框中声明文件类型的缺省选择值的已选择属性。最终由用户决定应忽略哪些文件。用户可以从缺省忽略文件列表选择、取消选择、添加或删除文件类型。
某些存储库对文本文件和二进制文件实现不同处理。org.eclipse.team.core.fileTypes 扩展点允许插件声明文件类型为文本文件或二进制文件。例如,Java 工具声明以下:
<extension point="org.eclipse.team.core.fileTypes">
<fileTypes extension="java" type="text"/>
<fileTypes extension="classpath" type="text"/>
<fileTypes extension="properties" type="text"/>
<fileTypes extension="class" type="binary"/>
<fileTypes extension="jar" type="binary"/>
<fileTypes extension="zip" type="binary"/>
</extension>
标记让插件通过扩展名来定义文件类型,并指定文本或二进制类型。与忽略文件相同,最终由用户管理文本和二进制文件类型列表。
项目可以包含不是位于本地文件系统中的项目目录中的资源。这些资源称为链接的资源。
链接的资源可以对直接对文件系统执行操作的存储库提供程序提出特定问题。这是因为在文件系统中,链接的资源在设计上不存在于直接的项目目录树中。
具有下列特征的提供程序可能会受到链接的资源的影响:
在第一种情况下,假定用户选择链接的资源,并尝试对它执行提供程序操作。由于提供程序调用命令行客户机,所以可以假定提供程序执行等价于先前调用 IResource.getLocation().toOSString(),并将获得的文件系统位置作为自变量提供给命令行程序的某些操作。如果所讨论的资源是链接的资源,则这将在项目目录树外部产生文件/文件夹。并不是所有命令行客户机都能预料和能够处理这种情况。总之,如果提供程序曾经获得了资源的文件系统位置,则可能需要执行额外的工作来处理链接的资源。
第二种情况相当类似,因为隐式假定项目资源的结构与文件系统文件/文件夹的结构是一一对应的关系。通常,如果提供程序将 IResource 操作与 java.io.File 操作混合在一起,则它们可能会遇到麻烦。例如,对于链接,IFile 的父代与 java.io.File 的父代不同,而假定它们相同的那些代码将失败。
链接的资源的引入不会无意识地损坏现有提供程序是非常重要的。更准确地说,提供程序应注意合理地假定本地文件系统结构反映了项目结构。因此,缺省情况下,不能将链接的资源添加至映射至此类提供程序的项目。另外,缺省情况下,不能与该提供程序共享包含链接的资源的项目。
为了能够“顺利链接”,提供程序应当允许对具有链接的资源的项目进行版本控制,但是可以不允许对链接的资源本身进行版本控制。
一个相当复杂的解决方案是允许对实际的链接的资源进行版本化,但是不提倡这种方法,原因是它会产生复杂的方案(例如,可能已在另一个项目树中由另一个提供程序对文件进行了版本控制)。因此,我们建议支持包含未进行版本控制的链接的资源的进行了版本控制的项目。
可以通过覆盖 RepositoryProvider.canHandleLinkedResources() 方法以返回 true 来升级存储库提供程序实现以支持链接的资源。一旦执行了此操作,就会允许链接的资源存在于与该存储库提供程序共享的项目中。但是,存储库提供程序必须执行一些步骤来确保正确处理了链接的资源。如上所述,强烈建议存储库提供程序忽略所有链接的资源。这意味着应当从存储库提供程序支持的操作中排除链接的资源(及其子代)。而且,如果存储库提供程序实现覆盖了缺省 IMoveDeleteHook,则存储库提供程序应当将缺省的移动和删除行为用于链接的资源。
小组提供程序可以使用 IResource.isLinked() 来确定是否是链接的资源。但是,此方法仅对链接的根才返回 true。以下代码段可以用来确定资源是否是链接的子代。
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
存储库提供程序应当忽略将以上代码对其求值为 true 的任何资源。
存储库实现常常使用额外文件和文件夹来存储关于存储库实现的特定信息。虽然在工作空间中可能需要这些文件,但其它插件或最终用户对它们不感兴趣。
小组提供程序可以使用 IResource.setTeamPrivateMember(boolean) 来表示一个资源是小组提供程序实现私有的。新创建的资源在缺省情况下不是私有成员,因此必须使用此方法显式地标记资源为小组私有。一个通常的用法是当配置小组项目和创建子文件夹时,将项目的子文件夹标记为小组私有。
枚举资源的其它资源 API(例如,资源变化树)将不包括小组私有成员,除非显式地请求包括它们。这意味着大多数客户机将“看不到”小组私有资源,它们不会显示给用户。资源导航器在缺省情况下不显示小组私有成员,但用户可以通过“首选项”指示他们想要查看小组私有资源。
将项目或工作空间根目录标记为小组私有的尝试将被忽略。
因为项目中处在版本控制下的资源被保留在存储库中,可以通过共享在工作空间中重新构建项目所需的存储库特定信息引用来与小组成员共享项目。这是通过使用小组项目集的特殊类型的文件导出来完成的。
在 3.0 中,API 已被添加至 ProjectSetCapability 以允许存储库提供程序声明实现其控制下项目的项目保存的类。当用户选择导出项目集时,只有那些使用定义项目集的存储库配置的项目将显示为导出候选对象。此 API 替换旧的项目集合串行化 API(如下所示)。
存储库提供程序的项目集合功能类是从 RepositoryProviderType 类获取的,该类与存储库提供程序是在同一扩展中注册的。例如:
<extension point="org.eclipse.team.core.repository">
<repository
typeClass="org.eclipse.team.internal.ccvs.core.CVSTeamProviderType"
class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"
id="org.eclipse.team.cvs.core.cvsnature">
</repository>
</extension>
在 3.0 之前,org.eclipse.team.core.projectSets 扩展点允许存储库提供程序声明实现其控制下项目的项目保存的类。当用户选择导出项目集时,只有那些使用定义项目集的存储库配置的项目将显示为导出候选对象。
例如,CVS 客户机声明如下:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
指定的类必须实现 IProjectSetSerializer。在 3.0 中仍支持使用此界面,但不推荐这样做。