Понятие версии программного продукта и системы контроля версий

Проблема контроля версий является одной из фундаментальных проблем программной инженерии в силуневозможности практической реализации линейной стратегии разработки программных средств и коллективного характера процесса разработки. При индивидуальной работе над проектом разработчик вынужден хранить 2 и более версий системы, чтобы иметь возможность вернуться на предыдущие стадии разработки. При коллективной разработке ситуация усложняется, поскольку возникают проблемы семантической совместимости фрагментов программного кода, созданных отдельными разработчиками, и оповещения об изменениях, вносимых в ранее написанный код каждым из разработчиков.Одним из аспектов нового подхода к организации разработки стало использование систем управления версиями – VersionControlSystems (VCS). Система управления версиями - комплексПО, назначением которого является централизованное хранение и обработка всех или большей части файлов, из которых состоит проект некоего программного продукта.

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

Понятие «версия» в разных системах трактуется 2 способами.

Одни системы (например, CVS) поддерживают версионность файлов; это означает, что любой файл, появляющийся в проекте, получает собственный номер версии (обычно — номер 1, условной «нулевой» версией файла считается пустой файл с тем же именем). При каждой фиксации разработчиком изменений, затрагивающих файл, файл получает новый, обычно следующий по порядку, номер версии. Поскольку фиксации обычно затрагивают только часть файлов в репозитории, номера версий файлов, со временем расходятся, и проект в целом никакого «номера версии» не имеет, т.к. состоит из множества файлов с различными номерами версий.

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений (даже 1 файла) приводит к увеличению этого номера. Номера версии отдельного файла здесь, не существует, но говоря о «версии файла» в таких системах, имеют в виду ту версию репозитория, в которой файл был последний раз изменён.

Две модели версионирования, их сравнение.

Модель «блокирование-изменение-разблокирование» запрещает одновременное редактирование файла несколькими клиентами. Перед началом редактирования клиент должен заблокировать файл. Тогда доступ к этому файлу других клиентов станет возможен только после снятия блокировки. Недостатки: •требует повышенного внимания службы администрирования ввиду возможности сохранения блокировки при некорректном завершении клиентом редактирования файла; •приводит к замедлению процесса разработки из-за частых блокировок, выполняемых и в случаях, когда в этом нет необходимости; •блокирование может вызвать ложное чувство безопасности в ситуации, когда два клиента редактируют разные, но зависящие друг от друга файлы.

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

При создании обновленного файла могут возникнуть две ситуации:

•нормальная: изменения, внесенные различными разработчиками, не перекрываются; их объединение происходит в автоматическом режиме; •конфликтная – некоторые из внесенных изменений перекрываются; объединение таких изменений производится «вручную» после взаимных консультаций разработчиков.

Сохранение внесенных изменений может производиться двумя способами:•созданием новой, измененной копии файла;•сохранением только отличий новой версии от предыдущей (дельта-компрессия)