Repository-Ressourcenverwaltung

Nachdem Sie einen RepositoryProvider erstellt haben, gibt es noch andere Ressourcenverwaltungsmechanismen, die Sie verstehen sollten:

Ignorierte Dateien

In manchen Fällen mag es nicht notwendig sein, bestimmte Dateien durch das Repository kontrollieren zu lassen.  Ressourcen, die aus bestehenden Ressource abgeleitet sind, können beispielsweise oft aus dem Repository herausgelassen werden.  Ein anderes Beispiel sind kompilierte Quellendateien, (z.B. Java-Dateien des Typs".class"), die ebenfalls nicht aufgenommen werden müssen, da sich die entsprechende Quelldatei (".java") bereits im Repository befindet. Darüber hinaus kann eine Versionssteuerung von Metadatendateien, die durch Repository-Provider erstellt werden, ebenfallsnicht wünschenswert sein. Über den Erweiterungspunkt org.eclipse.team.core.ignore können Provider Dateitypen deklarieren, die für Operationen von Repository-Providern nicht berücksichtigt werden sollen.  Der CVS-Client deklariert beispielsweise Folgendes:

<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>

Das Befehlsformat deklariert ein Muster (pattern) für Dateinamen, die ignoriert werden sollen, sowie ein Attribut selected, das den Standardauswahlwert des Dateityps im Benutzervorgabendialog deklariert. Letztendlich entscheidet der Benutzer, welche Dateien ignoriert werden können. Er kann hierzu Dateitypen in der Standardliste ignorierter Dateien auswählen, deren Auswahl zurücknehmen, sowie Dateien hinzufügen oder löschen.

Dateitypen

Bestimmte Repositories implementieren unterschiedliche Verarbeitungsrichtlinien für Text- und Binärdateien.  Die Erweiterung org.eclipse.team.core.fileTypes ermöglicht Plug-ins die Deklaration von Dateitypen als Text- oder Binärdateien.  Das Java-Tooling deklariert z. B. Folgendes:

<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>

Das Befehlsformat ermöglicht Plug-ins, mit dem Parameter extension einen Dateityp zu definieren und einen Typ (type) zur Festlegung einer Text- oder Binärdatei anzugeben. Wie bei ignorierten Dateien entscheidet auch hier der Benutzer, welche Text- und Binärdateitypen bei der Verwaltung berücksichtigt werden sollen.

Teams und verlinkte Ressourcen

Ein Projekt kann Ressourcen enthalten, die sich nicht im Verzeichnis des Projekts im lokalen Dateisystem befinden. Solche Ressourcen werden als verlinkte Ressourcen bezeichnet.

Konsequenzen für Repository-Provider

Verlinkte Ressourcen können für Repository-Provider, die direkt mit dem Dateisystem arbeiten, besondere Probleme darstellen. Dies liegt daran, dass verlinkte Ressourcen naturgemäß nicht in der unmittelbaren Projektverzeichnisstruktur im Dateisystem vorhanden sind.

Bei Providern, die die folgenden Kenndaten aufweisen, sind verlinkte Ressourcen möglicherweise problematisch:

  1. Provider, die ein externes Programm aufrufen, das anschließend direkt mit dem Dateisystem arbeitet.
  2. Provider, die durch "IResource" implementiert sind, jedoch davon ausgehen, dass sich alle Dateien/Ordner eines Projekts als direkt untergeordnete Elemente des Stammverzeichnisses in der jeweiligen Verzeichnisstruktur befinden.

Nehmen wir nun im ersten Fall an, dass der Benutzer eine verlinkte Ressource auswählt und versucht, für die Ressource eine Provideroperation auszuführen. Da der Provider einen Befehlszeilenclient aufruft, kann man davon ausgehen, dass er eine äquivalente Aktion ausführt, um zunächst IResource.getLocation().toOSString() aufzurufen und so die resultierende Dateisystemposition als Argument für das Befehlszeilenprogramm anzugeben. Falls es sich bei der fraglichen Ressource um eine verlinkte Ressource handelt, ergibt sich hierbei eine Datei oder ein Ordner außerhalb der Verzeichnisstruktur für das Projekt. Nicht alle Befehlszeilenclients können einen solchen Fall vorhersehen und verarbeiten. Selbst wenn Ihr Provider die Dateisystemposition einer Ressource abruft, sind für die Verarbeitung von verlinkten Ressourcen wahrscheinlich zusätzliche Schritte erforderlich.

Der zweite Fall ist insofern relativ ähnlich, weil hier die implizite Annahme besteht, dass die Struktur der Projektressourcen mit der Struktur der Dateien/Ordner im Dateisystem genau übereinstimmt. Im Allgemeinen könnten für einen Provider Probleme entstehen, wenn eine Mischung von Operationen für "IResource" und "java.io.File" vorliegt. Beispielsweise ist das übergeordnete Element von IFile bei Links nicht mit dem übergeordneten Element von "java.io.File" identisch. Code, der jedoch davon ausgeht, schlägt fehl.

Abwärtskompatibilität

Eine wichtige Vorgabe war, dass die Einführung von verlinkten Ressourcen nicht zu einer versehentlichen Unterbrechung vorhandener Provider führt. Insbesondere galt dies für Provider, die begründetermaßen davon ausgehen, dass die Struktur des lokalen Dateisystem die Projektstruktur widerspiegelt. Infolgedessen können verlinkte Ressourcen standardmäßig nicht zu Projekten hinzugefügt werden, denen ein solcher Provider zugeordnet ist. Außerdem können Projekte, die verlinkte Ressourcen enthalten, standardmäßig nicht über einen solchen Provider gemeinsam benutzt werden.

Strategien für die Verarbeitung von verlinkten Ressourcen

Damit ein Provider Links "toleriert", sollte er die Versionssteuerung von Projekten mit verlinkten Ressourcen zulassen, jedoch die Versionssteuerung der verlinkten Ressourcen selbst deaktivieren können.

Eine erheblich komplexere Lösung würde darin bestehen, die Versionierung der eigentlichen verlinkten Ressourcen zuzulassen. Hiervon wird jedoch abgeraten, da dies zu komplexen Szenarien führt (so könnte beispielsweise eine Datei bereits in einem anderen Projekt der Versionssteueurng durch einen anderen Provider unterliegen). Es empfiehlt sich daher, versionsgesteuerte Projekte zu unterstützen, deren verlinkte Ressourcen nicht versionsgesteuert sind.

Technische Details für Linktolerierung

Implementierungen von Repository-Providern können mit der Unterstützung von verlinkten Ressourcen erweitert werden, indem die Methode RepositoryProvider.canHandleLinkedResources() so überschrieben wird, dass Sie den Wert true zurückgibt. Sobald dies ausgeführt wurde, ist das Vorhandensein von verlinkten Ressourcen in Projekten, die über diesen Repository-Provider gemeinsam benutzt werden, zulässig. Der Repository-Provider muss jedoch Schritte unternehmen, damit sichergestellt ist, dass die verlinkten Ressourcen korrekt verarbeitet werden. Wie bereits erläutert ist es sehr empfehlenswert, dass Repository-Provider alle verlinkten Ressourcen ignorieren. Dies bedeutet, dass verlinkte Ressourcen (und ihre untergeordneten Elemente) von den Aktionen ausgeschlossen werden sollten, die durch den Repository-Provider unterstützt werden. Des Weiteren sollte der Repository-Provider das Standardverhalten zum Versetzen und Löschen bei verlinkten Ressourcen verwenden, falls die Implementierung des Repository-Providers den Standardwert von IMoveDeleteHook überschreibt.

Team-Provider können unter Verwendung von IResource.isLinked() ermitteln, ob eine Ressource ein Link ist. Diese Methode gibt jedoch nur für das Stammverzeichnis eines Links den Wert "true" zurück. Mit dem folgenden Codesegment kann ermittelt werden, ob eine Ressource ein untergeordnetes Element eines Links ist:

String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();

Repository-Provider sollten alle Ressourcen ignorieren, für die der vorstehende Code mit dem Ergebnis true ausgewertet wird.

Private Teamressourcen

Bei Repository-Implementierungen werden häufig Zusatzdateien und -ordner eingesetzt, um spezifische Informationen zur Repository-Implementierung zu speichern.  Obwohl diese Dateien möglicherweise im Arbeitsbereich benötigt werden, sind sie für andere Plug-ins oder den Endbenutzer ohne Belang.

Team-Provider können IResource.setTeamPrivateMember(boolean) verwenden, um anzugeben, dass eine Ressource innerhalb der Implementierung eines Team-Providers als privat markiert ist. Neu erstellte Ressourcen werden nicht standardmäßig als private Member definiert. Häufig werden Teilordner eines Projekts als privat innerhalb des Teams markiert, wenn das Projekt für das Team konfiguriert und der Teilordner erstellt wird.

Andere Ressourcen-APIs, die zur Spezifizierung von Ressourcen dienen (z. B. Baumstrukturen des Ressourcendeltas), schließen innerhalb des Teams als privat markierte Member aus, es sei denn, es liegt eine explizite Anforderung zur Einbindung dieser Member vor. Dies bedeutet, dass die meisten Clients die innerhalb eines Teams als privat markierten Ressourcen nicht "sehen". Dasselbe gilt auch für Benutzer. Der Ressourcennavigator zeigt standardmäßig ebenfalls keine privaten Member an. Über die Benutzervorgaben kann der Benutzer jedoch festlegen, dass diese Komponenten angezeigt werden sollen.

Versuche, Projekte oder das Stammverzeichnis des Arbeitsbereichs innerhalb des Teams als privat zu markieren, werden ignoriert.

Projektsets

Da die Ressourcen innerhalb eines Projektes, die von der Versionssteuerung betroffen sind, im Repository abgelegt werden, können Projekte mit Teammitgliedern gemeinsam verwendet werden, indem eine gemeinsame Referenz auf dierepository-spezifischen Informationen, die zur Rekonstruktion eines Projektes im Arbeitsbereich benötigt werden, benutzt wird.  Hierzu wird eine spezielle Dateiexportoperation für Team-Projektsets verwendet.  

 

In der Version 3.0 wurde API zu ProjectSetCapability hinzugefügt, über die Repository-Provider eine Klasse deklarieren können, die Projektspeicherung bei Projekten ermöglicht, die unter ihrer Steuerung verwaltet werden. Wenn der Benutzer Projektsets exportieren möchte, werden nur die mit Repositories konfigurierten Projekte, die Projektsets definieren, als mögliche Exportkandidaten angezeigt. Diese API ersetzt die ehemalige API für die serielle Anordnung von Projektsets (siehe unten).

Die Klasse für Projektsetfähigkeit eines Repository-Providers wird aus der Klasse RepositoryProviderType abgerufen, die in derselben Erweiterung registriert ist, wie der Repository-Provider. Hier ein Beispiel:

<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>

Vor der Version 3.0 konnten Repository-Provider über den Erweiterungspunkt org.eclipse.team.core.projectSets eine Klasse deklarieren, die Projektspeicherung bei Projekten, die unter ihrer Steuerung verwaltet werden, ermöglichte. Wenn der Benutzer Projektsets exportieren möchte, werden nur die mit Repositories konfigurierten Projekte, die Projektsets definieren, als mögliche Exportkandidaten angezeigt.

Der CVS-Client deklariert z. B. Folgendes:

<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>

Die angegebene Klasse muss IProjectSetSerializer implementieren. Die Verwendung dieser Schnittstelle wird in der Version 3.0 zwar noch unterstützt, ist aber inzwischen veraltet.