КОНЦЕПЦИЯ ПРИМЕНЕНИЯ КОНТЕНТНО-АДРЕСУЕМЫХ СИСТЕМ ХРАНЕНИЯ ДЛЯ КОНТРОЛЯ ВЕРСИЙ

Архипов Леонид Владиславович

аспирант Пензенского государственного университета,

РФ, г. Пенза

E -mail: WhiteLight92@mail.ru

CONCEPT OF CONTENT-ADDRESSABLE STORAGE FOR VERSION CONTROL

Leonid Arkhipov

graduate student, Penza State University,

Russia, Penza

АННОТАЦИЯ

Проводится обзор концепции применения контентно-адресуемых систем для контроля версий и делается вывод о целесообразности внедрения данных систем.

  ABSTRACT

The concept survey of content-address systems use for the control of versions is carried out, and the conclusion of practicability of given systems implementation is made. 

Ключевые слова: контентно-адресуемая система хранения; система контроля версий; фиксация.

Keywords: content-addressable storage; system version control; sharpshot.

Современные методы разработки программного обеспечения уже не могут обойтись без использования специальных инструментов. Помимо языка программирования и среды разработки, существуют разнообразные программные реализации, позволяющие автоматизировать рутинный труд программиста, упростить организацию коллективного рабочего процесса, тестирование и отладку исходного кода. Обязательный инструмент организации процесса разработки – система контроля версий (СКВ). СКВ – это программное обеспечение, отслеживающее изменения в одном или нескольких файлах, с возможностью сохранения и воспроизведения разных версий файлов. Основные понятия любой СКВ – репозиторий и проект. Репозиторий это каталог, содержащий проект, версии которого необходимо контролировать, и служебный каталог СКВ. Служебный каталог включает файлы, обеспечивающие работу СКВ, и базу данных, хранящую изменения, произведённые над проектом. Проект может состоять как из простого текстового файла, так и из множества файлов разных типов (отличные от текстовых, файлы обычно распознаются как бинарные), организованных в разветвлённую структуру каталогов. Между проектом и служебным каталогом происходит обмен данными: в базу данных СКВ записываются изменения, а в проект при необходимости извлекаются данные для восстановления ранних версий. Базы данных первых СКВ хранили версии проекта в виде исходных файлов и наборов патчей. Каждый патч содержал изменения, отличающие две смежные версии. Воспроизведение последней версии проекта осуществлялось наложением на исходные файлы изменений из патчей всех предыдущих версий. Некоторые современные СКВ до сих пор используют механизм патчей для ведения баз данных с изменениями. СКВ Git хранит изменения в виде фиксаций репозитория. При сохранении версии проекта состояние репозитория полностью фиксируется в базе данных. При восстановлении ранней версии проекта, Git переключает репозиторий в соответствующее состояние, воспроизводя из базы данных необходимую информацию о структуре каталогов и содержимом файлов проекта. Механизм фиксаций реализован применением концепции контентно-адресуемых систем хранения к ведению базы данных Git [1, с. 241]. В контентно-адресуемых системах хранения данных доступ к файлам (блоку данных) организуется не по имени файла или номеру блока данных, а по уникальному идентификатору, вычисляемому на основе содержимого файла [2, с. 1]. Git использует алгоритм SHA-1, для генерации уникальных 40 символьных хэш-кодов. База данных Git состоит из объектов разных типов, каждый из которых имеет свой хэш-код. Объект блоб (англ. binary large object) хранит содержимое одного файла проекта, на основе которого подсчитывается присваиваемый объекту хэш-код. Объекты-деревья содержат информацию о соответствии объекта-блоба файлу проекта, содержимое которого хранится в блобе. При наличии в проекте каталогов, объекты-деревья формируют многоуровневую структуру, ссылаясь на другие деревья. Объекты-фиксации указывают на объект-дерево, соответствующий зафиксированному состоянию репозитория, и на предшествующую фиксацию, а также содержат информацию о дате фиксации, авторе и краткое сообщение, описывающее произведённые изменения. Объекты-ветви – указатели на объекты-фиксации. Восстановление ранней версии проекта происходит по переключению ветви на нужную фиксацию. Git очищает репозиторий, и совершает обход по соответствующему фиксации корневому объекту-дереву, воспроизводя полные пути файлов проекта из узловых объектов-деревьев, а содержимое – из объектов блобов. Создание фиксации проходит несколько этапов, условно разделяющих репозиторий на области, в которых хранятся разные типы файлов проекта. Структура репозитория Git небольшого проекта приведена на рисунке 1.

Рисунок 1. Cтруктура репозитория Git небольшого проекта

Структура репозитория состоит из рабочей области и области индексированных файлов. Область не отслеживаемых файлов в рабочей области содержит новые файлы проекта, не зарегистрированные в базе данных Git. В области изменённых файлов находятся файлы, над которыми пользователь произвёл изменения. Область индексированных файлов содержит файлы проекта, подготовленные к фиксации в новой версии. Область фиксированных файлов находится в области индексированных файлов и содержит файлы, соответствующие текущей фиксации. При обмене данными об изменениях между проектом и служебным каталогом git файлы проекта условно перемещаются по областям репозитория, физически не изменяя полного пути. Операция перечитывания (команда git status) состояния репозитория определяет необходимость совершения фиксации, сравнивая файлы проекта с информацией из дерева текущего объекта-фиксации в базе данных. Если области изменённых и не отслеживаемых файлов не пусты, то в проекте произошли изменения, не зарегистрированные Git. Операция индексации (команда git add) подсчитывает хэш-коды добавленных и изменённых файлов и создаёт в базе данных Git – каталоге objects (рис. 1) объекты-блобы с содержимым файлов и объекты-деревья с названиями каталогов и файлов. Проиндексированные файлы перемещаются в область индексированных файлов, готовые к включению в фиксацию новой версии проекта. Операция фиксации (команда git commit) фиксирует текущее состояние репозитория, создавая в каталоге objects, результирующее корневое дерево, добавляя к истории версий проекта новый объект-фиксацию, и переводя указатель объекта-ветви в новое состояние. Созданное в базе данных корневое дерево ссылается на объекты, соответствующие новым и изменённым файлам, и – на объекты, файлы которых не подверглись изменениям. При накоплении в базе данных объектов с похожим содержимым Git, проводит операцию сжатия, при котором содержимое каталога object будет добавлено в единый архивный pack-файл.

В итоге можно отметить, что ключевая особенность Git – представление данных. Изменения, отличающие версии проекта, хранятся в базе данных согласно концепции контентно-адресуемой системы хранения. Низкоуровневые команды (git add, git cat-file) организуют работу с объектами базы данных Git, осуществляя быстрый обмен данными между хранилищем и проектом. Быстродействие – базовая характеристика при оценке СКВ, и высокое быстродействие Git – одна из причин популярности данной СКВ при разработке проектов любого масштаба [4]. Вторая причина популярности – широкий функционал с возможностью настройки. Высокоуровневые команды Git (git status, git commit), построенные на низкоуровневых командах, реализуют интерфейс, присущий любой СКВ, для организации взаимодействия пользователя с базой данных. Комбинирование низкоуровневых команд в более сложные инструменты – возможность для пользователя дополнить функционал Git и настроить данную СКВ под особенности собственного проекта и рабочего процесса разработки.

Список литературы:
1. Chacon S. Pro Git. – Creative Commons Attribution-Non Commercial-Share Alike 3.0 license, 2012. – 272 c.
2. CAS решения: особенности и применение // “Storage News” № 2 (31), 2007, www.storagenews.ru. URL: http://www.storagenews.ru/31/CAS_31-2.pdf (Дата обращения: 27.12.2015).
3. Брукс Ф. Мифический человеко-месяц. – 1-е издание. – «Символ-Плюс», 2001. – 304 с.
4. Какую систему управления версиями вы используете (в реальной работе, больше всего)? – [Электронный ресурс]. – Режим доступа: http://habrahabr.ru/post/269515/ (Дата обращения 4.12.2015).