Анализ состояний методов, алгоритмов и программных средств в поддержке управления версиями

Аннотация

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

Введение

На данный момент программная инженерия является самой востребованной и перспективной инженерной специальность. А задачи программной инженерии являются актуальными.

Весь комплекс работ, объединённый терминов - программная инженерия, можно разбить на ряд потоков. Перечислим имеющиеся потоки программной инженерии [1]:

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

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

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

Место и роль задачи контролей версий в потоке работ программной инженерии

Во время разработки программного продукта производится частое изменения программного кода. Иногда изменения какого-либо участка кода влечет за собой фатальные проблемы. И нужно не мало сил потратить для выявления проблемного участка. Становится вопрос о контроле изменений.

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

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

Анализ функций и роли системы контроля версиями

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

Данные системы часто применяются при разработке ПО для хранения и управления документов с исходным кодом. Но это не исключает ситуацию, что их можно использовать и в других сферах, в которые работа проходит в часто изменяющихся документах и нужно отслеживать все изменения с ними. Так же стоит отметить, что очень часто СУВ используются в САПР, которые используются в составе системе управления данным об изделии (PDM). Еще можно встретить СУВ при использовании конфигурационного управления [2].

Традиционные системы контролей версий имеет централизованную модель. Система имеет определенное хранилище и управление этой системы происходит на сервере. Порядок основных действий с системой контролей версий:

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

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

В различных системах управления встречаются такие возможности, как:

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

Существуют еще распределенный системы управления версиями. Их главное отличие в том, что они имеют распределенную модель, а не традиционную клиент-серверную. Они не нуждаются в наличии определенного хранилища: вся история изменения и все версии хранятся на машине, в локальном хранилище, и только при необходимости нужные части документов синхронизируются с подобным хранилищем на другом компьютере. Это дает преимущество перед централизованными в том, что каждый пользователь работает над своей локальной копией, а затем уже добавляет (производит push) на централизованное хранилище. Но перед данным этапом нужно загрузить актуальную копию на своей компьютер (произвести pull). Это делается с той целью, чтобы, если есть конфликты в двух версиях документа (того, который на другом компьютере и того, который на локальном компьютере), их разрешить. У распределенных есть ряд недостатков:

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

Преимущества распределенных систем управления версиями:

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

Системы контроля версий могут использоваться, так называемые дельта-компрессии – это такой подход, при котором записывается только изменения документа, а не всего версии. Простой пример может привести на цифрах, вместо записи 2, 4, 6, 7, 9, 5, 15, мы будем записывать 2, 2, 2, 1, 2, -4, 10 [3]. Так как в большинстве случаев нужно последняя версия, то на сервере записываем, заменяя предыдущую актуальную модель.

Обзор программный реализаций

В данном пункте будет рассмотрены и проанализированы следующий программные реализации: Система одновременных версий (CVS), Apache Subversion (SVN), Git, Mercurial.

CVS [4] впервые появилась в 1980-х, но несмотря на это является популярной и по сей день. CVS использует открытой лицензионное соглашение GNU. Основной функцией CVS является получать и отправлять на сервер определенную версию документа. Целью создания CVS являлось уметь разрешать конфликта между версиями при разработке. Также стоит отметить, что у каждого пользователя была возможность иметь только самую последнюю версию проекта. Это являлось первой системой контроля версиями. Недостатком было то, что пользователь обязан был успеть отправить новую версию своего документа на сервер, пока другие его не опередили. На данный момент этот недостаток разрешили возможностью работать с ветками проекта.

SVN [5] была создавалась альтернативой CVS. Целью создания базировалось на исправлении недостатков CVS, а также не забывать про обратную совместимость. SVN так же является бесплатной системой контроля версиями с открытым исходным кодом. SVN распространятся под лицензией Apache. Данная СУВ начала использовать атомарные операции, чтобы сохранить целостность БД. Что имеется ввиду, при создании новой версии к последней измененной версии проекта применяются либо все исправления, либо ни одно из них. Это создавала защиту кода от случайных и частичных правок, которые в некоторых случаях вызывают даже ошибки. Причиной того, что разработчики отдали предпочтение SVN и отказались от CVS в том, что SVN взял все лучшие от CVS и еще дали разработчикам больше возможностей. SVN создавалась в первую очередь для более крупных проектов, в которых использовалось ветвление кода и было не одно направление разработки.

Git [6] была создана для управления разработкой ядра Linux [7]. Данная система начала использовать категоричной другой подход от CVS и SVN. При создании Git было целью создать более быструю распределенную СУВ. Если взять во внимание, что Git создавался под Linux, то в этой ОС она работает лучше всего. Но также есть возможность пользоваться на MacOS и Windows. Также стоит заметить, что каждая версия содержит всю историю, что является весомым плюсом, если ведется разработка без интернет-соединения. Присутствует навигация по всей истории.

Mercurial [8] дебютировал в одно время с Git. Mercurial, как и Git, является распределенной системой контроля версиями. Mercurial являлся альтернативой при разработке модулей для ядра Linux. Mercurial используется меньше, но многие ведущие разработчики предпочли работать с этой СУВ, к ним можно отнести и OpenOffice.org [9]. Главное отличие данной системы от остальных является то, что она полностью написана на Python, а не на C. Но некоторые модули-расширения все равно были разработаны на C [10].

Была разработана таблица 1, в которой приведены все преимущества и недостатки каждого варианта.

Анализ главных проблем и формирования основных требований

Проанализировав основные методы и программные средства системы управления версиями. Было выявлено, что в потоки программной инженерии идет уклон на распараллеливание рабочих процессов, где очень важно, чтобы работа одного программиста не влияла на работу другого. Также к важным моментам нужно отнести недостаточную информативность при работе с разными версиями и ветками в СУВ. При получении новой более актуальной версии, иногда уходить много времени на анализ и понимание того, что было изменено именно в данной версии. Комментарий при загрузке на сервер (так называемый «комит») в большинстве случаев имеет ограниченный размер, и не все способны корректно отметить выполненное. В связи с этим способность выявлять исправления и предоставлять вместо измененных строк сформулированный анализ изменений является уместной в потоке программной инженерии.

Составлены основные требования для решения проблем и реализации программного обеспечение:

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

Вывод

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

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

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

Список использованной литературы

1. Анализ требований и другие рабочие потоки программной инженерии [Электронный ресурс] – Режим доступа: https://studfiles.net/preview/1644196/page:17/ – Загл. с экрана.
2. Система управления версиями [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%B F%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F%D0%BC%D0%B8 – Загл. с экрана
3. Дельта-кодирование [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D1%8C%D1%82%D0%B0-%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 – Загл.с экрана
4. CVS [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/CVS – Загл. с экрана.
5. Subversion [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Subversion – Загл. с экрана.
6. Git [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Git – Загл. с экрана.
7. Linux [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Linux – Загл. с экрана.
8. Mercurial [Электронный ресурс] // Википедия – Режим доступа: https://ru.wikipedia.org/wiki/Mercurial – Загл. с экрана
9. Apache OpenOffice - свободный и открытый офисный пакет [Электронный ресурс] – Режим доступа: https://www.openoffice.org/ru/ – Загл. с экрана.
10. Система контроля версий (cvs) 2018 - Сравниваем: Git, SVN, Mercurial [Электронный ресурс] // Википедия – Режим доступа: https://biz30.timedoctor.com/ru/c%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9/ – Загл. с экрана.