Сценарий объединения правок. Конфликты и способы их разрешения.

Конфликтная ситуация

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

Системы резервного копирования

Прообразом систем контроля версий являлись системы резервного копирования файлов

Подобные системы существовали и как отдельные продукты и как компоненты, интегрированные в различные программные средства.Например, возможность резервного копирования имеется в Microsoft Word и с ее помощью можно вручную «зафиксировать» текущее состояние документа

MS Word можно настроить и на автоматическое сохранение версий при каждом закрытии документа после редактирования

Служба «теневого» копирования

В Windows Server 2003 реализована служба «теневого» копирования – Shadow Copies , одинаково подходящая и для целей автоматизации резервного копирования, и для организации контроля версий

Shadow Copies обладает способностью сохранять «снимки» состояния дисковых томов в момент своего запуска.Все изменения, вносимые в содержимое тома после старта и до завершения копирования, фиксируются в журнале транзакций файловой системы.Физическая запись внесенных изменений производится после окончания процедуры копирования. Однако, контроль версий не является главной задачей службы «теневого» копирования, , из-за чего в данном вопросе ей недостает гибкости. В частности, нельзя обслуживать отдельные разделяемые папки, невозможно принудительно сохранить вариант документа в определенный момент времени (только по расписанию) и т.д.

Системы документооборота

Механизмы контроля версий – это почти обязательный атрибут систем документооборота и современных groupware-пакетов, например Windows SharePoint Services

Системы контроля версий с открытым кодом

Широкое распространение программных продуктов с открытым исходным кодом (Open source) не могло не затронуть и систем контроля версий

Система контроля изменений

Система контроля изменений (Revision Control System, RCS ) была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy) .Система позволяет хранить версии только одного файла, поэтому управлять несколькими файлами приходится вручную. Для обеспечения возможности коллективной работы используется механизм блокировок

8.Понятие сборки, манифест сборки.

Сборкой (assembly) называется логический набор модулей, которые являются частью одной версии приложения. Сборка представляет собой единый элемент развертывания приложений: она используется для упаковки, загрузки и распространения модулей

Манифест сборки

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

Имя сборки

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

· «дружественного» текстового имени,

· номера версии,

· идентификатора регионального стандарта,

· идентификатора разработчика

Первая часть имени сборки (атрибут Name) является обязательной и, обычно, содержит имя файла, в котором находится манифест сборки . Идентификатор регионального стандарта (атрибут CultureInfo) применяется только в т.н. сателлитных сборках, которые могут хранить только ресурсные данные, но не код

9.Сборка приложения, системы автоматизации сборки.

Создание сборок представляет собой сложный процесс, включающий большой перечень задач, в том числе:

· компиляцию модулей с исходным кодом,

· генерацию части исходных кодов из декларативного описания;

· генерацию документации по исходным кодам проекта;

· генерацию дескрипторов развертывания по исходным кодам проекта

· конфигурирование проекта под различные версии библиотек;

· перекодирование и архивирование файлов;

· создание инсталлятора

Следует также иметь в виду, что сборка, может иметь специальное назначение (например, демоверсия приложения), что потребуется учитывать при ее создании 

Системы сборки

Для автоматизации процесса сборки приложения разработаны различные программные средства, т. н. системы сборки. Наиболее известными из них являются make (в различных вариантах gmake, nmake), Ant (для Java-проектов), NAnt (для .NET-проектов) и др.

Утилита NAnt, файл сборки и его структура.

NAnt — это свободное (open source) инструментальное ПО для автоматизации процесса сборки приложений . От широко известного продукта Apache Ant отличается отсутствием привязки к языку Java . Первый релиз NAnt был зарегистрирован на Source Forge 18 июля 2001года

Файл сборки

Для создания сборки с помощью NAnt надо написать файл сборки (build-file),представляющий собой XML-файл, в котором с помощью специальных тегов описываются действия при сборке. Файл сборки соответствует одному проекту . Файл сборки проекта состоит из заданий или целей (targets)

Атрибуты проекта

Для проекта дополнительно могут быть определены:

цель по умолчанию (default target), которая выполняется при отсутствии других целей;

базовый каталог (base directory ), используемый в качестве рабочего при сборке приложения

Цели, зависимость целей, описание целей.

Цель

Цель идентифицируется именем – name и может иметь дополнительные атрибуты:

· depends – список имен целей, от которых зависит данная;

· if – условие, при котором должно выполняться задание;

· unless – условие, при котором данное задание должно игнорироваться;

· description – краткое описание цели 

Зависимости целей

Цели могут зависеть от других целей: в этом случае перед выполнением текущей цели выполняются все цели, от которых она зависит. Цепочка зависимостей целей может быть достаточно длинной

Зависимости

В следующем примере задачи должны выполняться в последовательности A à B à C à D:

<target name="A"/>

<target name="B" depends="A" />

<target name="C" depends="B" />

<target name="D" depends="C,B,A" />