Управление ресурсами хранилища

Создав RepositoryProvider, следует разобраться с другими способами управления ресурсами:

Игнорируемые файлы

В некоторых случаях бывает необходимо, чтобы некоторые файлы не управлялись хранилищем.  Например, ресурсы, производные от существующих ресурсов, часто не нужны в хранилище.  Например, откомпилированные исходные файлы, (файлы Java ".class"), можно опустить, так как в хранилище есть соответствующие им исходные файлы (".java").  То же относится и к файлам метаданных управления версиями, которые генерируются типами хранилищ.  Точка расширения org.eclipse.team.core.ignore позволяет объявлять типы файлов, не участвующих в операциях хранилища.  Например, клиент CVS объявляет следующие типы:

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

В коде просто объявляется шаблон имени игнорируемого файла, и атрибут selected, задающий выбранное по умолчанию значение типа файла в окне настройки параметров.  Решать, какие файлы следует игнорировать, в конечном счете приходится пользователю.  Пользователь может выбирать, снимать выбор, добавлять или удалять типы файлов из стандартного списка игнорируемых файлов.

Типы файлов

В некоторых хранилищах обработка текстовых и бинарных файлов отличается.  Точка расширения 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>

Этот код позволяет определить тип файла по расширению и присвоить ему текстовый или бинарный тип.   Как и в случае с игнорируемыми файлами, списком текстовых и бинарных типов управляет пользователь.

Коллективная работа и связанные ресурсы

В проекте могут содержаться ресурсы, которые не находятся в каталоге проекта в локальной файловой системе. Такие ресурсы называются связанными ресурсами.

Влияние на типы хранилищ

Связанные ресурсы могут представлять проблему для хранилищ, работающих напрямую с файловой системой. Связанные ресурсы по определению не существуют в дереве каталога проекта в файловой системе.

Связанные ресурсы могут воздействовать на хранилища со следующими характеристиками:

  1. Вызывающие внешнюю программу, которая, в свою очередь, работает напрямую с файловой системой.
  2. Реализованные на уровне IResource, но считающие, что все файлы/папки проекта являются прямыми потомками этого корневого дерева каталогов.

В первом случае будем считать, что пользователь выбирает связанный ресурс и пытается выполнить над ним какое-либо действие. Так как класс типа хранилища вызывает клиента командной строки, то считаем, что выполняется некий эквивалент первого вызова 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 в ProjectSetCapability добавлен API, служащий для того, чтобы типы хранилищ могли объявить класс, реализующий сохранение проектов, находящихся под их управлением.  Когда пользователь выбирает экспорт наборов проекта, доступными для экспорта будут только те проекты, которые настроены с хранилищами, определяющими наборы проектов. Такой 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, но он уже устарел.