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

Лекция читалась преподавателем ПиИТ ФКН ВГУ Хлебостроевым Виктором Григорьевичем (ТП)
---------------------

в сети факультета лекция доступна в виде презентации, но по-моему удобнее учить , когда перед глазами что-то больше, чем один слайд)))

отформатирую позже. если у кого есть желание сделать раньше - скопируйте текст и отформатируйте к комментарии.

vedro-compota's picture

Контроль версий

Проблема контроля версий

Проблема контроля версий является одной из фундаментальных проблем программной инженерии в силу :=

  1. невозможности практической реализации линейной стратегии разработки программных средств;
  2. коллективного характера процесса разработки

Даже при индивидуальной работе над проектом разработчик вынужден хранить две и более версий системы, чтобы иметь возможность вернуться на предыдущие стадии разработки
«Ручная» работа с несколькими версиями весьма утомительна и непродуктивна

При коллективной разработке ситуация существенно усложняется, поскольку возникают проблемы:=

  1. семантической совместимости фрагментов программного кода, созданных отдельными разработчиками;
  2. оповещения об изменениях, вносимых в ранее написанный код каждым из разработчиков

Актуальность проблемы

Особую актуальность проблема контроля версий приобрела с появлением инструментальных средств быстрой разработки проектов таких, как Delphi, С++ Builder и JBuilder, а затем Visual Studio.Net
Применение этих инструментальных средств привело к взрывообразному росту производительности труда разработчиков
Следствием этого стала перегрузка отдельных разработчиков и их групп проектами, исходным кодом и документацией
Стала очевидной необходимость пересмотра подходов к организации процесса создания ПС (программных средств)

---------------------------------

Средства управления версиями

Одним из аспектов нового подхода к организации разработки стало использование средств управления версиями проектов программного обеспечения – Project Version Control Systems (PVCS)

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


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

Проект

Под проектом понимается совокупность файлов, включающая:=

  1. исходные тексты на различных языках программирования;
  2. исполняемые, ресурсные и библиотечные файлы, необходимые для сборки программного продукта;
  3. исходные тексты файлов справки;
  4. сценарии программ инсталляции;
  5. сопроводительная документация проекта

Версия проекта

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

Основные процессы Систем контроля версий

Основными процессами в эксплуатации PVCS являются:=

  1. ввод первичной информации о проекте,
  2. создание первой копии проекта в хранилище PVCS;
  3. настройка PVCS для работы с данным проектом;
  4. запись (Check-In) модифицированных или вновь созданных составляющих проекта в центральное хранилище с присвоением номера версии;
  5. выдача (Check-Out) отдельных составляющих проекта для модификации;
  6. выдача всех составляющих проекта (Pull) заданной версии для сборки программного продукта или отдельного его компонента

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

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

---------------

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

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

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

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

-------------

Механизм контроля версий в Borland Delphi

Встроенный механизм контроля версий имеется в Borland Delphi
Впервые такая система, получившая название FreeVCS , была разработана в 1999 году Томасом Хенсле (Thomas Hensle) для Delphi 4
Для версии Delphi 5 компанией Borland была разработана система контроля версий TeamSource
TeamSource изначально является средством групповой разработки, однако может использоваться и в однопользовательском режиме, т.к. не имеет жесткой привязки к каким-либо сетевым средствам или протоколам
В 2005 году появился продукт Borland StarTeam – автоматизированная система управления конфигурацией и изменениями проекта
Кроме управления версиями, StarTeam предоставляет пользователям ряд других функций, связанных с управлением проектом

---------------------------

Механизм контроля версий в Visual Studio

В состав пакета Microsoft Visual Studio входит Visual SourceSafe (VSS) — файл-серверная система управления версиями, предназначенная для небольших команд разработчиков
VSS позволяет хранить в общем хранилище файлы, разделяемые несколькими пользователями, причем для каждого файла сохраняется история его версий

-----------------------------

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

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

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

Однако, контроль версий не является главной задачей службы «теневого» копирования, из-за чего в данном вопросе ей недостает гибкости
В частности, =

  • нельзя обслуживать отдельные разделяемые папки,
  • невозможно принудительно сохранить вариант документа в определенный момент времени (только по расписанию) и т.д.

----------------------

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

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

-----------------------------

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

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

-------------

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

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

-------------------

Система конкурирующих версий (CVS) - продолжение проекта RCS

Продолжением проекта RCS стала система конкурирующих версий (Concurrent Versions System, CVS), разработанная Диком Груном (Dick Grune) в середине 1980-х годов
CVS использует архитектуру клиент-сервер, в которой вся информация о версиях хранится на сервере

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

ВАЖНО = CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки
Таким образом, можно исправлять ошибки в очередной версии проекта и параллельно разрабатывать новую функциональность

В чистом виде CVS и ее клоны являются системами командной строки, поэтому для их комфортного использования необходима графическая оболочка
Для Windows в качестве такой оболочки может использоваться продукт WinCVS, распространяемый с открытым исходным кодом

Основные преимущества CVS и ее клонов состоят в =

  1. их высокой надежности;
  2. доступности большого количества программных дополнений;
  3. наличии документации на различных языках


Основными недостатками
системы являются:=

  1. невозможность сохранения версий каталогов в силу использования специфического способа представления файлов;
  2. отсутствие контроля за перемещением, удалением или переименованием файлов

=======================================

Система Subversion


Subversion (SVN)
был разработан в 2000 году по инициативе фирмы CollabNet и по сравнению с СVS:=

  1. обеспечивает лучшее управление изменениями структуры каталогов;
  2. более эффективно хранит двоичные файлы;
  3. имеет стандартную возможность возврата к состоянию проекта на определенный момент времени

Хранилище версий

Subversion — централизованная система (в отличие от распределённых систем, таких, как Git или Mercurial), то есть данные хранятся в едином хранилище.
Хранилище может располагаться на локальном диске или на сетевом сервере

Архитектура системы представлена на следующей схеме =
2656

Модель работы


Модель работы Subversion:

  • Клиенты копируют файлы из хранилища, создавая локальные рабочие копии,
  • затем вносят изменения в рабочие копии и публикуют эти изменения в хранилище
  • Несколько клиентов могут одновременно обращаться к хранилищу
  • При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных

==============================================

Модели версионирования (создания очередной версии)

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

Для этого могут использоваться те или иные модели версионирования

-----------------

Модель Блокирование-Изменение-Разблокирование

Свойства=

  • Эта модель запрещает одновременное редактирование файла несколькими клиентами
  • Перед началом редактирования клиент должен заблокировать файл
  • Тогда доступ к этому файлу других клиентов станет возможен только после снятия блокировки


Схема работы модели Блокирование-Изменение-Разблокирование (пример)=

цкпкв

Действия на схеме =

  1. Гарри считывает файл из общедоступного для всех разработчиков(на схеме их двое) репозитория файл для редактирования и система автоматически блокирует доступ к данному файлу для других разработчиков
  2. Второй разработчик Салли пытается считать тот же самый файл , но система контроля версий выполненная в соответствии с моделью блокирование-изменение-разблокирование сообщает пользвателью Салли, что файл уже редактируется и не доступен.
  3. Гарри завершает изменение файла и сохраняет его - система снимает блокировку.
  4. Салли получает файл для редактирования.

Недостатки модели =

  1. Требует повышенного внимания службы администрирования ввиду возможности сохранения блокировки при некорректном завершении клиентом редактирования файла
  2. Приводит к замедлению процесса разработки из-за частых блокировок, выполняемых и в случаях, когда в этом нет необходимости
  3. Блокирование может вызвать ложное чувство безопасности в ситуации, когда два клиента редактируют разные, но зависящие друг от друга файлы

---------------------------------

Модель Копирование-Изменение-Слияние

Принцип действия=

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

Пример работы модели Копирование-Изменение-Слияние
=
цкуе
Изображено следующее:

  1. Пользователь Гарри попытался записать в хранилище исправленный им файл А после того, как пользователь Салли уже зафиксировала там свои итоги редактирования этого файла
  2. Система сообщила Гарри, что его файл устарел
  3. Гарри попросил систему обновить его копию файла А
  4. SVN копирует измененный Салли файл А в рабочее пространство Гарри
  5. Создается обновленный файл А с включением изменений, сделанных каждым из пользователей

Объединение изменений

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

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

Рабочие копии Рабочая Копия Subversion

Рабочая копия – это моментальный «снимок» состояния хранилища или некоторой его части, сохраненный на компьютере клиента

Рабочая копия представляет собой обычное дерево каталогов, содержащее набор различных файлов
Файлы рабочей копии могут произвольным образом редактироваться разработчиком, оставаясь недоступными другим участникам группы

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

Служебный каталог


Служебный каталог
- это специальный каталог внутри каталога рабочей копии (обычно названный .svn) , который позволяет системе контроля версий хранить различную информацию о состоянии рабочей копии, в частности - об изменениях внесённых в файлы рабочей копии и местоположении хранилища - то есть всевозможную "внутреннюю системную" информацию, которую использует система контроля версий, при своей работе с файлами

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

-----------------

Хранилище (репозиторий)

Хранилище - это некий каталог , расположенный на удалённом сервере или локальном компьютере (в зависимости от варианта установки системы хранения версий) - в котором, хранятся все "зафиксированные" версии проекта - именно из хранилища разработчики получают "рабочую копию" проекта , после отправки соответствующего запроса.

Представляет собой последовательность фиксированных состояний размещенной в ней файловой системы
Хранилище создается с помощью входящей в состав поставки Subversion утилиты SvnAdmin путем выполнения команды:

	svnadmin create <путь к репозиторию>  

-----------------------

Импорт в хранилище

В качестве первого аргумента этой команды задается путь к поддереву, которое будет загружено в репозиторий
В частности, это может быть папка, содержащая некоторый проект
Вторым аргументом команды импорта является URL-адрес, который используется для доступа к хранилищу

Доступ к хранилищу

Получить доступ к хранилищу Subversion можно различными способами – на локальном диске или через ряд сетевых протоколов

----------------------------------

URL для доступа к хранилищу

  • file:/// - прямой доступ к хранилищу (на локальном диске)
  • http:// - доступ через протокол WebDAV (если Subversion-сервер работает через Apache - впрочем, как и через любой сервер, поддерживающий этот протокол)
  • https:// - то же, что и http://, но с SSL-шифрованием
  • svn:// - доступ через собственный протокол к серверу svnserve
  • svn+ssh:// - то же, что и svn://, но через SSH-соединение

-----------

Файловая система хранилища

Как правило, хранилище Subversion содержит файлы нескольких проектов

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

Правки (в смысле версии)

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

изменение отдельной ветки разработки - означает появление новой версии проекта, в то время как факт правки хранилища в целом не означает этого.
--------------------
Глобальность правок

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

-----------------------
Просмотр списка файлов

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

 svn list <URL каталога хранилища> -v

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

-------------------

Смешивание правок

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

 4   calc/Makefile
 4   calc/integer.c 
4   calc/button.c 

На данный момент рабочий каталог полностью соответствует правке 4 в хранилище
Допустим, что разработчик внес изменения в файл button.c и зафиксировал эти изменения
При отсутствии других фиксаций будет создана правка под номером 5, и теперь его рабочая копия выглядит следующим образом

  4   calc/Makefile
   4   calc/integer.c 
5 calc/button.c 

Предположим, что после этого второй разработчик фиксирует изменения integer.c, создавая правку 6
Если первый разработчик актуализирует свою рабочую копию, то она станет выглядеть так

 6   calc/Makefile
 6   calc/integer.c 
6  calc/button.c

Изменения, внесенные в integer.c вторым разработчиком будут отражены в рабочей копии первого разработчика, как и его собственные, сделанные в файле button.c

Текст Makefile в правках 4, 5 и 6 идентичен, однако Subversion проставляет номер правки 6 для рабочей копии Makefile, чтобы показать что файл не устарел
Таким образом, после выполнения обновления первым разработчиком его рабочей копии, она будет полностью соответствовать текущему состоянию хранилища

----------------

Фиксация локальных изменений

После внесения изменений в файл рабочей копии разработчик может зафиксировать внесенные изменения, выполнив команду

svn commit  <параметры> <путь к файлу>

Например

	svn commit -F msg foo.c 

В результате в хранилище создается новая правка

----------------------------

Обновление рабочей копии

Для актуализации рабочей копии используется команда

	 svn update <путь к рабочей копии>

При этом обновляются только те файлы, в которые вносились изменения между обновлениями

-----------------------------

Служебный каталог

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

  1. на какой правке основан рабочий файл (это называется рабочая правка файла);
  2. временная (ударение на последний слог) метка, определяющая, когда рабочая копия последний раз обновлялась из хранилища

Состояния файла

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

  1. не изменялся и не устарел,
  2. изменялся локально и не устарел,
  3. не изменялся и устарел,
  4. изменялся локально и устарел

теперь подробнее =

-------------
1) Не изменялся и не устарел -
то есть никто этот файл не трогал

  • Файл не изменялся в рабочем каталоге, а в хранилище также не фиксировались изменения этого файла со времени создания его рабочей правки
  • Команды svn commit и svn update никаких операций делать не будут

2) Изменялся локально и не устарел =

то есть мы изменили файл - при этом никто не успел до нашей публикации опубликовать какие-то собственные изменения.

Файл был изменен в рабочей копии, но в хранилище не фиксировались изменения этого файла последнего обновления рабочей копии
Есть локальные изменения, которые не были зафиксированы в хранилище, поэтому svn commit выполнит фиксацию этих изменений, а svn update не сделает ничего - специально чтобы не испортить ваши данные .

3) Не изменялся и устарел =
то есть кто-то другой из вашей комынды провёл изменения и опубликовал их

  1. В рабочем каталоге файл не изменялся, но был изменен в хранилище
  2. Необходимо выполнить обновление файла для того, чтобы он соответствовал текущей опубликованной правке
  3. Команда svn commit не сделает ничего, а svn update обновит рабочую копию файла в соответствии с последними изменениями

4) Изменялся и устарел

то есть вы параллельно с кем-то правили файл, но этот кто-то опубликовал изменения раньше

=

  1. Файл был изменен как в рабочем каталоге, так и в хранилище
  2. Команда svn commit потерпит неудачу, выдав ошибку «out-of-date»
  3. Файл необходимо сначала обновить
  4. Команда svn update попытается объединить локальные изменения с опубликованными
  5. Если Subversion не сможет выполнить объединение самостоятельно, она предложит пользователю разрешить конфликт вручную

_____________
матфак вгу и остальная классика =)