В этой статье:
Выбор места для хранения исходных текстов
Работа нескольких пользователей с одним объектом, разрешение конфликтов
Обновление схемы и передача на тестирование
Рекомендуемый сценарий для передачи репозитория на тестирование
Рекомендуемый сценарий обновления *.pef-файлами
Расхождение состояний объекта в репозитории и на сервере VCS
Перемещение объектов, отданных под управление VCS
Добавление клонированного репозитория в VCS
Возможные трудности при подключении клонированной схемы к VCS
Номер статьи: KB000022
В данной статье обсуждаются важные моменты по использованию VCS в «Форсайт. Аналитическая платформа». Статья рассчитана на пользователей, имеющих опыт работы с VCS в среде Visual Studio 2010. Также рекомендуется ознакомиться с VCS, описанной в документации продукта «Форсайт. Аналитическая платформа»:
В статье говорится не о том, как пользоваться VCS в «Форсайт. Аналитическая платформа», а о том, что нужно знать при её использовании.
Team Foundation Server (TFS) - продукт корпорации Microsoft, представляющий собой комплексное решение, объединяющее в себе систему управления версиями (VCS), сбор данных, построение отчетов, отслеживание статусов и изменений по проекту, и предназначенное для совместной работы над проектами по разработке программного обеспечения. Данный продукт доступен как в виде отдельного приложения, так и в виде серверной платформы для Visual Studio Team System (VSTS).
Перед началом работы с VCS необходимо установить следующие программные продукты:
Team Explorer
Microsoft Team Foundation Server MSSCCI Provider
В диалоге провайдера («Choose Folder in Team Foundation Server») необходимо указать место хранения исходных текстов на сервере и на локальном компьютере. Как правило, в TFS создаётся проект (за это ответственны администраторы используемого сервера) и все исходные тексты хранятся внутри этого проекта.
Примечание. MSSCCI Provider накладывает ограничение на максимальную длину пути к локальным файлам. Конечная длина пути к файлу: <локальная папка, установленная в настройках подключения VCS>\<сформированное имя файла>, не должна превышать 260 символов.
В рамках одного проекта рекомендуется создавать отдельную папку на сервере для каждого репозитория, в котором ведётся разработка.
Перед созданием папки в VCS необходимо сначала настроить Workspace, чтобы связать местоположение файлов на сервере и локальном диске, а затем создать нужную папку.
Категорически нельзя располагать несколько репозиториев в одной и той же или дочерних папках. Если при попытке утвердить размещение исходных текстов возникает ошибка «Invalid Project Mapped», это означает, что указанная вами локальная папка уже используется для хранения других исходных текстов.
Если после указания путей (Server Path, Local Path) кнопка «OK» будет недоступна, то это ошибка TFS, которая устраняется при использовании MSSCCI Provider и Team Explorer.
При подключении к настроенному репозиторию происходит инициализация провайдера и соединение с сервером TFS, что занимает некоторое время (2-8 секунд). Провайдер инициализируется, только если «Форсайт. Аналитическая платформа» запущен путем запуска файла Studio.exe.
Когда репозиторий поместили под управление VCS, необходимо подключить других разработчиков к системе. Для этого каждому разработчику нужно (даже если они работают на одном компьютере) настроить у себя локальный и серверный пути для хранения исходных текстов. У каждого члена команды, должны быть достаточные права на работу с папкой на сервере, в которой хранятся исходные тексты. Если права отсутствуют, то разработчик не добавлен в основную группу проекта, в этом случае обратитесь к администратору проекта.
Если при добавлении объекта в VCS вы отменили Сheck In (подтверждение изменений) для операции добавления файлов на сервер TFS, то объект всё равно будет помечен добавленным в TFS. Сами же файлы будут отправлены на сервер при следующей операции Сheck In.
Конфликты возникают, когда один пользователь отправил исходные тексты на сервер, а другой пользователь пытается отправить свои изменения без учёта изменений первого.
После разрешения конфликта результат сохраняется локально, перепроверяется пользователем и снова отправляется на сервер.
При возникновении конфликта в прикладном коде, как правило, проблем нет. Сложности возникают при конфликте в дизайнере формы, т.е. в файле *.form.xml. В этом случае рекомендуется либо откатить изменения на сервере, либо откатить локальные изменения. Разрешать конфликт автоматически или вручную (используя Merge Tool) не рекомендуется. Иначе, если допустить в файле *.form.xml ошибку, то дизайнер форм будет некорректно реагировать на исправления. Для решения возникшей проблемы, необходимо открыть локальный файл *.form.xml и исправить его вручную, исходя из модификаций, сделанных в Merge Tool. Исправить ошибку можно и в окне Source Control в Visual Studio (устанавливается вместе с Team Explorer), например, заменить текущий файл последней версией с сервера. При этом необходимо следить, чтобы состояние Сheck In/Сheck Out для файлов на сервере и в репозитории были одинаковы.
Перед сворачиванием помните, что все локальные изменения от всех пользователей, неотправленные на сервер, не будут свёрнуты в дамп. После создания схемы-клона, отданной под управление VCS, её необходимо отключить от VCS.
При создании обновления с формами/сборками/модулями репозитория учитывается флажок «Использовать локальные версии объектов VCS», устанавливаемый в параметрах обновления. По умолчанию флажок установлен, при этом в обновление попадут те версии объектов, которые на текущий момент сохранены на локальном диске в папке, которая была указана при подключении репозитория к VCS. Если флажок снять, то в обновлении будут сохраняться версии объектов, имеющиеся в системе управления версиями.
Если из схемы, не подключенной к VCS, устанавливается обновление для схемы, содержащейся в VCS, то для объектов присутствующих в VCS будет сгенерирован конфликт «Соответствующий объект находится под управлением VCS». Конфликт можно разрешить на стадии подготовки к применению обновления путем подтверждения обновления либо на стадии обновления будет выдан дополнительный диалог, в котором можно подтвердить обновление, либо пропустить обновление объектов.
Необходимо выполнить следующие действия:
проверить, все ли исходные тексты были отправлены на сервер;
определить, актуальная ли версия содержится на сервере. Если необходимо, то отправить актуальную версию в TFS;
свернуть БД в дамп;
развернуть дамп в другую БД;
подключиться к развёрнутой схеме и отключить её от управления VCS;
передать схему на тестирование.
Необходимо выполнить следующие действия:
проверить, все ли изменения, относящиеся к обновляемым объектам, были опубликованы на сервере. Если необходимо, то отправить актуальную версию в TFS;
создать обновление;
установить созданное обновление на клонированную схему;
проверить обновлённые объекты из разрабатываемой схемы и из тестируемой: они должны быть одинаковыми.
Иногда при выполнении операций с объектом под VCS возникают ошибки: «отказано в доступе», «SCC_FILENOTCHECKOUT» и т.д. Как правило, причина в том, что состояние объекта в репозитории и его файлов (или части файлов) расходятся. Это можно проверить, посмотрев состояния файлов через окно Source Control. Если причина ошибки в различном состоянии объекта и его файлов, то необходимо выполнить следующие действия:
вспомнить последние действия, которые были произведены вами над объектом, и добавить Defect;
в окне Source Control привести файлы, соответствующие данному объекту, в состояние, в котором они находятся в репозитории. Если файл заблокирован в репозитории - произвести Сheck Out в TFS, не заблокирован - Сheck In (в созданный ранее Defect);
заново подключиться к репозиторию и попытаться совершить операцию над объектом повторно.
Порядок перемещения/переименования объекта, помещенного в VCS:
используя Team Explorer вручную проверить, что объект не заблокирован (для него не выполнен Сheck Out) другими разработчиками. Если объект заблокирован, то другие разработчики должны внести изменения (выполнить Сheck In);
выполнить перемещение/переименование;
известить остальных прикладных разработчиков;
остальные разработчики должны обновить навигатор, получить последнюю версию для папок, откуда и куда выполнялось перемещение. Если репозиторий маленький, то лучше получить последнюю версию для корневой папки репозитория.
Если не следовать данным рекомендациям, то возникнет конфликт. Разработчик, получивший сообщение «TF10141: No files checked in: resolve the conflicts and try again», разрешает конфликт у себя. Порядок разрешения конфликта:
обновить репозиторий в навигаторе;
в навигаторе найти перемещенный объект и получить последнюю версию папки, содержащей его;
выполнить Сheck In для объекта;
в открывшемся окне выбрать способ разрешения конфликта. Если выбрано автоматическое разрешение, то в окне будет запрошено новое имя файла. Необходимо указать имя файла с сервера.
При перемещении объекта, группы объектов или папки с объектами, помещенных в VCS, эти объекты должны быть перемещены в репозитории, на сервере TFS и локально. Поэтому последовательно открываются несколько окон провайдера для подтверждения операции переименования файлов (выполнения Сheck In). Например, при перемещении одной формы окно выполнения Сheck In будет открыто три раза, т.к. для формы хранятся три файла. Аналогично будет и при смене имени или идентификатора объекта.
Не рекомендуется делать отмену операции перемещения объекта в окне выполнения Сheck In.
Решение проблемы открытия нескольких окон выполнения Сheck In при перемещении/переименовании осуществляется в рамках требования 56060.
В ходе работы с VCS может возникнуть ситуация, когда необходимо сделать клон схемы, подключенной к VCS. Этот клон также необходимо добавить в VCS. Например, это может понадобиться в случае разбиения работы со схемой на две независимые ветви.
Рассмотрим пример. В структуре компании есть некое Направление. Схемы этого Направления хранятся на сервере TFS в папке «NAPR», а Local Path для этой папки настроен на «C:\MODULES».
Среди схем Направления есть схема «SCHEME», хранящаяся на сервере по адресу «NAPR\SCHEME». Локально файлы хранятся по адресу «C:\MODULES\SCHEME».
Для корректного клонирования «SCHEME» в «SCHEME_CLONE» и подключения клона к VCS, необходимо последовательно выполнить следующие шаги (понадобятся права на редактирование объектов через Source Control Explorer):
свернуть «SCHEME» в дамп и из него развернуть в «SCHEME_CLONE»;
в «Форсайт. Аналитическая платформа» подключиться к схеме «SCHEME_CLONE» и выполнить команду меню «Параметры - Разработка приложений».
После этого доступны два варианта действий:
в появившемся окне нажать кнопку «Отключить от системы контроля версий». Для репозитория и всех его объектов будут удалены настройки по подключению к системе управления версиями;
в окне «Разработка приложений» нажать кнопку «Подключить к системе контроля версий». В открывшемся диалоге выбрать сервер, указать настройки сервера VCS. При необходимости создать новые папки на сервере и локальном диске;
из репозитория заново добавить необходимые объекты в систему управления версиями.
в появившемся окне нажать кнопку «Настроить». В открывшемся диалоге выбрать сервер и изменить настройки сервера VCS, в качестве папки на сервере и локальном диске указать папки, подготовленные следующим образом:
через Source Control Explorer на сервере TFS в папке «NAPR» создать новую папку «SCHEME_CLONE» (через команду «New Folder»). Автоматически на локальном диске будет создана папка «C:\MODULES\SCHEME_CLONE»;
локально скопировать все содержимое из папки «C:\MODULES\SCHEME» в папку «C:\MODULES\SCHEME_CLONE». Внутренняя иерархия этих папок в итоге должна быть идентичной;
через Source Control Explorer для папки «NAPR\SCHEME_CLONE» выполнить команду «Compare»;
в появившемся окне указать в Target Path адрес «C:\MODULES\SCHEME_CLONE», Source Path оставить прежним. Установить флажок «Show Items That Exist Only In Target Path», остальные флажки снять. Нажать «ОК»;
результатом выполнения команды «Compare» будет список файлов, которые существуют локально в папке «C:\MODULES\SCHEME_CLONE», но которых нет на сервере TFS в «NAPR\SCHEME_CLONE». В рассматриваемом примере это все файлы и папки из «C:\MODULES\SCHEME_CLONE»;
выделить все найденные объекты и выполнить для них команду контекстного меню «Reconcile»;
в Source Control Explorer для папки «NAPR» выполнить команду «Refresh»;
в Source Control Explorer для папки «NAPR\SCHEME_CLONE» выполнить «Check In Pending Changes», в появившемся окне подтвердить отправку файлов на сервер. Теперь содержимое по адресу «C:\MODULES\SCHEME_CLONE» и на сервере по адресу «NAPR\SCHEME_CLONE» идентично.
Иногда необходимо подключить схему-клон к VCS по истечении некоторого времени после клонирования. При этом вероятно, что какие-либо файлы в схеме-оригинале, добавленные ранее в VCS, уже были изменены, перемещены или удалены. В этом случае недостаточно только локального копирования файлов из «C:\MODULES\SCHEME» в «C:\MODULES\SCHEME_CLONE».
Выходом является приведение в соответствие файлов в «C:\MODULES\SCHEME_CLONE» файлам в репозитории «SCHEME_CLONE», выполненное после локального копирования файлов:
В схеме-оригинале модуль «MODULE» был перемещен из папки
«FOLDER1» в папку «FOLDER2».
В папке «C:\MODULES\SCHEME_CLONE» переместите файлы, относящиеся
к данному модулю («MODULE_MODULE.text» и «MODULE_MODULE.ref.xml»),
из папки «FOLDER1» в папку «FOLDER2».
Модуль «MODULE» в схеме-оригинале был изменен.
Вручную скорректируйте содержимое файлов «MODULE_MODULE.text» и
«MODULE_MODULE.ref.xml» в «C:\MODULES\SCHEME_CLONE» в соответствии
с состоянием модуля в схеме-клоне.
Модуль «MODULE» был удален из схемы-оригинала.
В папке «C:\MODULE\SCHEME_CLONE» создайте, где это необходимо,
файлы «MODULE_MODULE.text» и «MODULE_MODULE.ref.xml» и корректно
заполните их содержимое.
Во избежание указанных проблем рекомендуется сразу после клонирования схемы, даже если не планируется подключать её к VCS, сделать локальную копию файлов из «C:\MODULES\SCHEME» в «C:\MODULES\SCHEME_CLONE».
См. также: