RepositoryProvider를 작성했으면
기타 자원 관리 메커니즘을 이해해야 합니다.
여러 경우에 특정 파일을 저장소 제어 하에 두는 것이 불필요할 수 있습니다. 예를 들어 기존 자원으로부터 파생되는 자원은 종종 저장소에서 생략될 수 있습니다. 예를 들어 컴파일된 소스 파일(예: Java ".class" 파일)은 해당 소스(".java") 파일이 저장소에 있기 때문에 생략될 수 있습니다. 이것은 저장소 제공자가 생성하는 버전 제어 메타데이터 파일에는 부적절할 수도 있습니다. org.eclipse.team.core.ignore 확장점을 사용하면 제공자가 저장소 제공자 조작에 대해 무시해야 하는 파일 유형을 선언할 수 있습니다. 예를 들어 CVS 클라이언트는 다음을 선언합니다.
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
마크업은 무시되어야 하는 파일 이름 패턴 및 환경 설정 대화 상자에서 파일 유형의 기본 선택 값을 선언하는 selected 속성을 선업합니다. 결국 어떤 파일을 무시할지 결정하는 것은 사용자입니다. 사용자는 무시된 파일의 기본 목록에서 파일 유형을 선택, 선택 취소, 추가 또는 삭제할 수 있습니다.
일부 저장소는 텍스트 파일과 2진 파일을 구분해서 다른 처리를 구현합니다. org.eclipse.team.core.fileTypes 확장을 사용하여 플러그인에서 파일 유형을 텍스트 파일 또는 2진 파일로 선언할 수 있습니다. 예를 들어 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>
마크업을 사용하여 플러그인은 확장자로 파일 유형을 정의하며 텍스트 또는 2진 유형을 지정합니다. 무시된 파일의 경우 텍스트 파일 및 2진 파일 유형 목록을 관리하는 것은 사용자입니다.
프로젝트는 로컬 파일 시스템의 프로젝트 디렉토리에 위치하지 않는 자원을 포함할 수 있습니다. 이러한 자원을 링크된 자원이라 합니다.
링크된 자원은 파일 시스템에서 직접 조작하는 저장소 제공자에 대해 특별 인증 확인을 할 수 있습니다. 이것은 디자인으로 링크된 자원이 파일 시스템의 직접 프로젝트 디렉토리 트리에 없다는 사실의 결과입니다.
다음 특성을 나타내는 제공자는 링크된 자원에 의해 영향을 받을 수 있습니다.
첫 번째의 경우 사용자가 링크된 자원을 선택하여 이에 대해 제공자 조작을 수행하려는 것으로 간주합니다. 제공자가 명령행 클라이언트를 호출하므로, 제공자가 결과 파일 시스템 위치를 명령행 프로그램에 인수로서 제공하며 첫 번째 호출 IResource.getLocation().toOSString()에 상응하는 작업을 수행하는 것으로 간주할 수 있습니다. 해당 자원이 링크된 자원인 경우, 이를 통해 프로젝트 디렉토리 트리 외부에 파일/폴더를 가져옵니다. 모든 명령행 클라이언트가 이 문제를 처리할 수 있을 것으로 기대할 수는 없습니다. 요컨대 제공자가 자원의 파일 시스템 위치를 확보하려면 링크된 자원을 처리하는 데 추가 작업이 필요할 수 있습니다.
두 번째의 경우 프로젝트 자원의 구조가 파일 시스템 파일/폴더의 구조와 1:1이라는 암시적 가정을 한다는 점에서 매우 비슷합니다. 일반적으로 제공자가 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에서 계속 지원되지만 권장되지는 않습니다.