Файл: Система управления версиями git и российский сервис хранения исходного кода gitflic.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.12.2023
Просмотров: 203
Скачиваний: 7
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
система управления версиями.
Систему управления версиями можно сравнить с сохранением состо- яния компьютерной игры. Перед прохождением особенно сложного игро- вого эпизода игрок сохраняет текущее состояние, чтобы, в случае неудачи, была возможность вернуться, а не проходить игру заново. Или игрок хочет
11 попробовать несколько вариантов прохождения. Он сохраняет текущее со- стояние и многократно возвращается к нему, пробуя новые стратегии про- хождения.
Таким образом,
Система управления версиями – это инструмент, позволяющий доку-
ментировать ход разработки, выполняемой коллективом программи-
стов, и быстро переходить от одной версии кода к другой.
1.2. Краткая история развития систем управления версиями
История систем управления версиями (VCS) насчитывает три поколе- ния. На рисунке 1.2 представлена хронология их создания.
Рисунок 1.2 – Хронология создания систем управления версиями
VCS первого поколения предназначались для отслеживания измене- ний в одном, изолированном файле. Редактировать этот файл в каждый момент времени мог только один человек. VCS первого поколения, в основ- ном, предназначались для использования одним программистом на одном, изолированном компьютере. В очень редких случаях организовывался сете- вой доступ к одному компьютеру, и все участники проекта должны были
I поколение
1972
ScSS, разработана
Mark
Rochkind
I поколение
1982
RCS,
разработана
Walter Tichy
II поколение
1986
CVS,
разработана
Dick Grune
II поколение
2000
Bitkeeper от Bitmover
Inc,
SVN
от Colabnet
Inc
III поколение
2005
Mercurial автор Matt
Mackall,
Git автор Linus
Torvalds
12 заходить на этот компьютер и редактировать отдельные файлы. В каждый момент времени доступ к VCS имел только один участник проекта.
Коллективный доступ к файлам появился в VCS второго поколения.
Стала доступна коллективная работа. Несколько человек одновременно могли редактировать файлы и сохранять изменения в одном централизован- ном хранилище (репозитории). В репозитории в каждый момент времени хранилась «официальная» версия проекта. При работе с репозиторием к нему требовался постоянный сетевой доступ. Фактически репозиторий представлял собой сетевую папку, с которой одновременно работали не- сколько человек.
VSC третьего поколения реализованы как распределённые храни- лища. Централизованного репозитория нет. Все VCS на компьютерах всех разработчиков считаются равноправными. Каждый из разработчиков рабо- тает автономно. По согласованию между разработчиками одно из хранилищ считается местом хранения текущей «официальной» версии проекта. Разра- ботчики синхронизируют свои VSC с «официальной» версией по мере накопления готовых частей кода.
1.3. Системы управления версиями первого поколения
Первой системой управления версиями, получившей широкое распро- странение, была SCCS (Source Code Control System) (J. Schilling, 2020).
SCCS была разработана сотрудником Bell Labs Марком Рочкиндом в 1972 году и предназначалась для отслеживания версий одного, изолированного файла. Базовые идеи, заложенные в SCCS, сохраняются и в современных системах управления версиями (Oracle Corporation, 2010).
В момент добавления в SCCS нового файла, за версиями которого необходимо следить, в системе создаётся контейнер, называемый файлом истории. Имя этого контейнера состоит из имени исходного файла, к кото- рому добавлен префикс s. Например, для файла с именем file1.txt имя контейнера будет s.file1.txt. Контейнер хранится в директории с именем
SCCS, являющейся поддиректорией директории, в которой хранится исход- ный файл. В момент создания файл истории содержит копию исходного
13 файла и служебную информацию, предназначенную для отслеживания вер- сий. Одной из составляющих служебной информации является контрольная сумма, предназначенная для проверки целостности файла истории. Файл ис- тории не кодируется и не сжимается, он хранится «как есть», и существенно увеличивается в размере по мере сохранения истории изменений.
При попытке сохранить новую версию исходного файла в файл исто- рии добавляется только фрагмент, содержащий различия между версиями.
Такой фрагмент называется дельтой. Идея хранения дельт останется осно- вополагающей для всех последующих поколений систем управления верси- ями. Такой способ хранения позволяет существенно уменьшить размер файла истории, даже не прибегая к сжатию. Каждая дельта хранится в спе- циальной структуре, называемой дельта-таблицей. В дельта-таблице сохра- няется текст, который добавляется или удаляется из исходного файла. К этому тексту добавляются управляющие последовательности, маркирую- щие начало и конец очередной дельты.
Добавление каждой новой дельты (описывающей добавление или уда- ление фрагмента текста) приводит к увеличению номера версии файла ис- тории. Любую из версий можно извлечь в рабочую директорию для про- смотра, редактирования или компиляции. В SCCS используется метод хра- нения под названием «чередующиеся дельты», который гарантирует, что время извлечения более ранних версий не будет отличаться от времени из- влечения более поздних версий.
SCCS позволяет хранить историю версий для одного файла, в то время как программный проект состоит из нескольких файлов. При стандартном использовании SCCS версии файлов, входящих в один проект, будут отли- чаться. Чтобы синхронизировать номера версий в рамках одного проекта, используют следующее ухищрение. В те файлы, которые не редактирова- лись, добавляют пустое изменение, вызывающее изменение номера версии и добавление пустой дельты. Надо заметить, если проект содержит много файлов, подобная синхронизация номеров их версий является очень трудо-
ёмкой.
Когда один из программистов извлекает из файла истории версию для редактирования, сам файл истории блокируется и становится недоступным для других программистов. Это позволяет избежать перезаписи чужих пра- вок, но существенно замедляет коллективную работу над проектом, так как
14 с одним файлом в один момент времени может работать только один про- граммист.
В SCCS была реализована идея веток, ставшая в дальнейшем класси- ческой. Под ветками подразумеваются отдельные файлы истории, хранящие различные части решения одной задачи. После завершения работы над всеми частями файлы историй соединяются, образуя общий файл истории решения всей задачи.
Для понимания того, какие действия позволяет выполнить SCCS, рас- смотрим некоторые команды этой системы управления версиями.
− sccs create – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /SCCS;
− sccs get – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование за- прещено);
− sccs edit – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для редактирования. Файл исто- рии будет заблокирован и недоступен для других пользователей;
− sccs delta – изменения, сделанные в рабочем файле, будут добав- лены в файл истории, который будет разблокирован;
− sccs prt – показать цепочку изменений, хранящуюся в файле истории;
− sccs diffs – показать различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории.
Перечисленные команды демонстрируют основные этапы работы с файлом истории: создание, просмотр последней версии, редактирование, сравнение с предыдущей версией, просмотр истории изменений, сохране- ние сделанных изменений.
Система управления версиями SCCS была коммерческой (платной), и из-за этого её доступность была ограничена. Как обычно случается в таких ситуациях, появилась система управления версиями с открытым кодом. Её создал Уолтер Тихи в 1982 году и назвал Revision Control System (RCS)
(Nguyen, 2022). SCCS и RCS во многом похожи, их общие свойства:
− сохранение истории только для одного файла;
15
− версии различных файлов, составляющих один проект, могут отли- чаться;
− отсутствует многопользовательский режим;
− отсутствует поддержка сети.
Отличие RCS от SCCS является, скорее, её недостатком, чем усовер- шенствованием, вероятно, выполненным для того, чтобы избежать патент- ных споров с SCCS. Тем не менее, о нём необходимо рассказать, поскольку на RCS базируются системы управления версиями второго поколения.
Для сохранения изменений в RCS используется система обратных дельт. При создании первоначального файла истории в него помещается со- держимое исходного файла. Процесс сохранения изменений заключается в следующем. Вычисляется дельта между новой версией и версией, храня- щейся в файле истории. Версия, хранящаяся в файле истории, из него уда- ляется, и вместо неё записывается новая версия и вычисленная дельта. Для получения последней версии файла никаких действий не требуется, так как она всегда хранится в файле истории. Для получения предыдущей версии необходимо из текущей версии вычесть дельту. Чем более раннюю версию требуется получить, тем больше дельт необходимо вычесть. В отличие от
SCCS, в RCS доступ к последней версии осуществляется очень быстро, и чем старше версия, к которой необходимо получить доступ, тем больше времени требуется затратить. В SCCS время доступа ко всем версиям одинаковое.
Список и содержимое команд RCS похожи на список и содержимое команд SCCS:
− si – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /RCS. Если файл уже имеется в каталоге /RCS, то вычисляет дельту, удаляет старую версию и добавляет новую и соответству- ющую ей дельту;
− co – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование запрещено);
− co-l – извлекает последнюю версию рабочего файла из файла исто- рии и помещает её в рабочий каталог для редактирования. Файл истории будет заблокирован и недоступен для других пользователей;
− merge – производит слияние двух отредактированных копий одного исходного файла;
16
− rcsdiff – показывает различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории.
1.4. Системы управления версиями второго поколения
Эффективному использованию систем управления версиями первого поколения мешало отсутствие поддержки многопользовательской удалён- ной работы. В 1986 году Дик Грун разработал систему управления версиями под названием Concurrent Version System (CVS) (GNU, 2015). CVS откры- вает эру систем управления версиями второго поколения, главным отли- чием которых от систем управления версиями первого поколения является поддержка многопользовательского режима работы (поддержка сети). С по- явлением этой системы географически распределённые команды разработ- чиков получили эффективный инструмент коллективной работы. Програм- мисты, находящиеся в разных точках земного шара, теперь могли взаимо- действовать так же эффективно, как при нахождении в одной комнате.
CVS представляет собой сетевой интерфейс для системы управления версиями первого поколения RCS. С точки зрения правил формирования файлов истории, в CVS нет никаких отличий от RCS. Отличия заключаются в процедуре доступа к файлам истории, которая реализует модель центра- лизованного репозитория. Под централизованным репозиторием понима- ется сетевое хранилище файлов, доступ к которому осуществляется через локальную или глобальную сеть.
Первый шаг по организации работы с CVS заключается в создании на удалённом сервере централизованного репозитория. Для выполнения этой работы используются специальные команды CVS. После того, как репози- торий создан, в него импортируется заготовка проекта, содержащая мини- мальный набор файлов. Вместо заготовки может быть импортирован проект, подлежащий доработке. Работу по созданию репозитория и импорту проекта обычно выполняет руководитель или инициатор проекта. В результате им- порта в репозитории создаются файлы истории для всех файлов проекта.
После создания репозитория каждый из участников проекта имеет
17 возможность скачать на свой локальный компьютер файлы истории. В от- личие от RCS, файлы истории в репозитории не блокируются после их ска- чивания, что позволяет работать с проектом неограниченному количеству программистов. Программисты редактируют файлы на своих локальных компьютерах и, по мере необходимости, фиксируют изменения в файлах ис- тории центрального репозитория. Если один из программистов обновил файл истории в репозитории, его коллеги должны обновить соответствую- щий рабочий файл на своих локальных компьютерах. Сделать это необхо- димо перед фиксацией изменений, внесённых в тот же файл, или для того, чтобы использовать (посмотреть) результаты работы коллеги. Процедура обновления рабочих копий, как правило, автоматизирована и не требует ручной работы. Правда, иногда возникают коллизии, которые необходимо устранить в ручном режиме перед фиксацией изменений.
История не сохранила сведений о том, когда появился термин «ком- мит», но при описании приёмов работы с системами управления версиями второго поколения он широко используется. Значит, необходимо дать опре- деление этого термина.
Коммит – это синоним выражения «зафиксировать изменения в файле ис- тории».
Система команд CVS объединяет в себе команды системы RCS и спе- цифические команды, обеспечивающие коллективную работу с централь- ным репозиторием. Вот список этих команд:
− export CVSOOT – задаёт корневой каталог репозитория CVS для того, чтобы его не нужно было в дальнейшем указывать в каждой команде;
− cvs import – импортировать директории проекта в репозиторий
CVS. Перед выполнением команды происходит автоматический переход в корневой каталог проекта;
− cvs checkout – копировать файлы проекта на локальный компьютер;
− cvs commit – коммит изменённого файла;
− cvs add – добавляет новый файл в репозиторий для отслеживания изменений;
− cvs update – обновить рабочую версию из репозитория для учёта
18 коммитов, сделанных другими программистами;
− cvs ststus – показать общую информацию об извлечённой рабочей версии;
− cvs tag – добавить информационный заголовок (тег) в файл или группу файлов;
− cvs tag –b – создать новую ветвь в репозитории;
− cvs checkout –r – извлечь ветвь из репозитория;
− cvs update –j – объединить ветвь из репозитория с локальной рабо- чей копией.
Дальнейшим развитием систем управления версиями второго поколе- ния стала система Subversion (C. Michael Pilato, 2008). Как и CVS, она осно- вана на технологии центрального репозитория.
В CVS возможна ситуация, когда коммит будет сохранён не полно- стью, например, из-за проблем с сетевым подключением. Частично сохра- нённый коммит будет рассматриваться как полный и при загрузке в рабочие версии создаст массу проблем. Для исключения таких ситуаций в Subversion предусмотрено журналирование. Перед началом записи очередного ком- мита в специальном файле, называемом журналом, делается запись о по- пытке выполнить коммит с подробной информацией о нём. Если операция была выполнена успешно, к этой записи добавляется отметка о завершении сохранения коммита. В случае сбоя отметка о завершении коммита не будет размещена в журнале. После восстановления работоспособности системы проверяется журнал на предмет наличия записей без отметок о завершении.
При наличии таких записей повторяются указанные в них коммиты.
Важной особенностью Subversion является то, что коммиты могут включать в себя не один файл, а группу файлов или каталогов. Это позво- ляет рассматривать набор связанных изменений как один коммит, что уве- личивает информативность сохранённых изменений.
В настоящее время Subversion поддерживается Apache Software Foun- dation и использует файловую систему FSFS (File System atop th File System).
В FSFS директории являются полноправными объектами, которые воз- можно включать в коммит. Каждый коммит хранится в отдельном файле.
Этим файлам присваиваются имена в виде последовательных числовых
19 идентификаторов. При первом коммите в файле сохраняется полный текст файла, при последующих – только дельты. Кроме того, коммиты сжимаются с помощью алгоритмов lz4 или zlib. Поскольку Subversion является наслед- ницей RCS, в ней используется система обратных дельт. При большом ко- личестве коммитов, относящихся к одному файлу, время восстановления ранних версий значительно увеличивается. Для борьбы с этим неудобством с Subversion используется соглашение о том, что после сохранения 1023 дельт снова сохраняется полная версия исходного файла.
Subversion использует не обычную систему ветвления. Шаблон репо- зитория содержит три директории:
− trunk;
− branches;
− tags.
Директория используется в следующих целях:
− trunk для хранения окончательных версий проекта, готовых для пе- редачи пользователю;
− branches для хранения вложенных папок, соответствующих различ- ным ветвям;
− tags для хранения обособленных частей проекта.
Ниже перечислены основные команды системы Subversion:
− svn create – создаёт новый пустой шаблон репозитория;
− svn import – импортировать проект в репозиторий (создать файлы истории для всех файлов проекта);
− svn checkout – загрузить рабочие версии из репозитория на локаль- ный компьютер;
− svn commit –m – создать коммит для набора файлов и директорий;
− svn add – добавить в репозиторий новый файл для отслеживания;
− svn update – обновить рабочую версию проекта; будут скачаны и добавлены изменения, внесённые другими программистами;
− svn status – отобразить список файлов, которые изменились (по- лезна в связке с предыдущей командой);
− svn info – общие сведения об извлечённой рабочей копии проекта;
− svn copy – создать новую ветку путём копирования существующей;
Систему управления версиями можно сравнить с сохранением состо- яния компьютерной игры. Перед прохождением особенно сложного игро- вого эпизода игрок сохраняет текущее состояние, чтобы, в случае неудачи, была возможность вернуться, а не проходить игру заново. Или игрок хочет
11 попробовать несколько вариантов прохождения. Он сохраняет текущее со- стояние и многократно возвращается к нему, пробуя новые стратегии про- хождения.
Таким образом,
Система управления версиями – это инструмент, позволяющий доку-
ментировать ход разработки, выполняемой коллективом программи-
стов, и быстро переходить от одной версии кода к другой.
1.2. Краткая история развития систем управления версиями
История систем управления версиями (VCS) насчитывает три поколе- ния. На рисунке 1.2 представлена хронология их создания.
Рисунок 1.2 – Хронология создания систем управления версиями
VCS первого поколения предназначались для отслеживания измене- ний в одном, изолированном файле. Редактировать этот файл в каждый момент времени мог только один человек. VCS первого поколения, в основ- ном, предназначались для использования одним программистом на одном, изолированном компьютере. В очень редких случаях организовывался сете- вой доступ к одному компьютеру, и все участники проекта должны были
I поколение
1972
ScSS, разработана
Mark
Rochkind
I поколение
1982
RCS,
разработана
Walter Tichy
II поколение
1986
CVS,
разработана
Dick Grune
II поколение
2000
Bitkeeper от Bitmover
Inc,
SVN
от Colabnet
Inc
III поколение
2005
Mercurial автор Matt
Mackall,
Git автор Linus
Torvalds
12 заходить на этот компьютер и редактировать отдельные файлы. В каждый момент времени доступ к VCS имел только один участник проекта.
Коллективный доступ к файлам появился в VCS второго поколения.
Стала доступна коллективная работа. Несколько человек одновременно могли редактировать файлы и сохранять изменения в одном централизован- ном хранилище (репозитории). В репозитории в каждый момент времени хранилась «официальная» версия проекта. При работе с репозиторием к нему требовался постоянный сетевой доступ. Фактически репозиторий представлял собой сетевую папку, с которой одновременно работали не- сколько человек.
VSC третьего поколения реализованы как распределённые храни- лища. Централизованного репозитория нет. Все VCS на компьютерах всех разработчиков считаются равноправными. Каждый из разработчиков рабо- тает автономно. По согласованию между разработчиками одно из хранилищ считается местом хранения текущей «официальной» версии проекта. Разра- ботчики синхронизируют свои VSC с «официальной» версией по мере накопления готовых частей кода.
1.3. Системы управления версиями первого поколения
Первой системой управления версиями, получившей широкое распро- странение, была SCCS (Source Code Control System) (J. Schilling, 2020).
SCCS была разработана сотрудником Bell Labs Марком Рочкиндом в 1972 году и предназначалась для отслеживания версий одного, изолированного файла. Базовые идеи, заложенные в SCCS, сохраняются и в современных системах управления версиями (Oracle Corporation, 2010).
В момент добавления в SCCS нового файла, за версиями которого необходимо следить, в системе создаётся контейнер, называемый файлом истории. Имя этого контейнера состоит из имени исходного файла, к кото- рому добавлен префикс s. Например, для файла с именем file1.txt имя контейнера будет s.file1.txt. Контейнер хранится в директории с именем
SCCS, являющейся поддиректорией директории, в которой хранится исход- ный файл. В момент создания файл истории содержит копию исходного
13 файла и служебную информацию, предназначенную для отслеживания вер- сий. Одной из составляющих служебной информации является контрольная сумма, предназначенная для проверки целостности файла истории. Файл ис- тории не кодируется и не сжимается, он хранится «как есть», и существенно увеличивается в размере по мере сохранения истории изменений.
При попытке сохранить новую версию исходного файла в файл исто- рии добавляется только фрагмент, содержащий различия между версиями.
Такой фрагмент называется дельтой. Идея хранения дельт останется осно- вополагающей для всех последующих поколений систем управления верси- ями. Такой способ хранения позволяет существенно уменьшить размер файла истории, даже не прибегая к сжатию. Каждая дельта хранится в спе- циальной структуре, называемой дельта-таблицей. В дельта-таблице сохра- няется текст, который добавляется или удаляется из исходного файла. К этому тексту добавляются управляющие последовательности, маркирую- щие начало и конец очередной дельты.
Добавление каждой новой дельты (описывающей добавление или уда- ление фрагмента текста) приводит к увеличению номера версии файла ис- тории. Любую из версий можно извлечь в рабочую директорию для про- смотра, редактирования или компиляции. В SCCS используется метод хра- нения под названием «чередующиеся дельты», который гарантирует, что время извлечения более ранних версий не будет отличаться от времени из- влечения более поздних версий.
SCCS позволяет хранить историю версий для одного файла, в то время как программный проект состоит из нескольких файлов. При стандартном использовании SCCS версии файлов, входящих в один проект, будут отли- чаться. Чтобы синхронизировать номера версий в рамках одного проекта, используют следующее ухищрение. В те файлы, которые не редактирова- лись, добавляют пустое изменение, вызывающее изменение номера версии и добавление пустой дельты. Надо заметить, если проект содержит много файлов, подобная синхронизация номеров их версий является очень трудо-
ёмкой.
Когда один из программистов извлекает из файла истории версию для редактирования, сам файл истории блокируется и становится недоступным для других программистов. Это позволяет избежать перезаписи чужих пра- вок, но существенно замедляет коллективную работу над проектом, так как
14 с одним файлом в один момент времени может работать только один про- граммист.
В SCCS была реализована идея веток, ставшая в дальнейшем класси- ческой. Под ветками подразумеваются отдельные файлы истории, хранящие различные части решения одной задачи. После завершения работы над всеми частями файлы историй соединяются, образуя общий файл истории решения всей задачи.
Для понимания того, какие действия позволяет выполнить SCCS, рас- смотрим некоторые команды этой системы управления версиями.
− sccs create – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /SCCS;
− sccs get – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование за- прещено);
− sccs edit – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для редактирования. Файл исто- рии будет заблокирован и недоступен для других пользователей;
− sccs delta – изменения, сделанные в рабочем файле, будут добав- лены в файл истории, который будет разблокирован;
− sccs prt – показать цепочку изменений, хранящуюся в файле истории;
− sccs diffs – показать различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории.
Перечисленные команды демонстрируют основные этапы работы с файлом истории: создание, просмотр последней версии, редактирование, сравнение с предыдущей версией, просмотр истории изменений, сохране- ние сделанных изменений.
Система управления версиями SCCS была коммерческой (платной), и из-за этого её доступность была ограничена. Как обычно случается в таких ситуациях, появилась система управления версиями с открытым кодом. Её создал Уолтер Тихи в 1982 году и назвал Revision Control System (RCS)
(Nguyen, 2022). SCCS и RCS во многом похожи, их общие свойства:
− сохранение истории только для одного файла;
15
− версии различных файлов, составляющих один проект, могут отли- чаться;
− отсутствует многопользовательский режим;
− отсутствует поддержка сети.
Отличие RCS от SCCS является, скорее, её недостатком, чем усовер- шенствованием, вероятно, выполненным для того, чтобы избежать патент- ных споров с SCCS. Тем не менее, о нём необходимо рассказать, поскольку на RCS базируются системы управления версиями второго поколения.
Для сохранения изменений в RCS используется система обратных дельт. При создании первоначального файла истории в него помещается со- держимое исходного файла. Процесс сохранения изменений заключается в следующем. Вычисляется дельта между новой версией и версией, храня- щейся в файле истории. Версия, хранящаяся в файле истории, из него уда- ляется, и вместо неё записывается новая версия и вычисленная дельта. Для получения последней версии файла никаких действий не требуется, так как она всегда хранится в файле истории. Для получения предыдущей версии необходимо из текущей версии вычесть дельту. Чем более раннюю версию требуется получить, тем больше дельт необходимо вычесть. В отличие от
SCCS, в RCS доступ к последней версии осуществляется очень быстро, и чем старше версия, к которой необходимо получить доступ, тем больше времени требуется затратить. В SCCS время доступа ко всем версиям одинаковое.
Список и содержимое команд RCS похожи на список и содержимое команд SCCS:
− si – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /RCS. Если файл уже имеется в каталоге /RCS, то вычисляет дельту, удаляет старую версию и добавляет новую и соответству- ющую ей дельту;
− co – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование запрещено);
− co-l – извлекает последнюю версию рабочего файла из файла исто- рии и помещает её в рабочий каталог для редактирования. Файл истории будет заблокирован и недоступен для других пользователей;
− merge – производит слияние двух отредактированных копий одного исходного файла;
16
− rcsdiff – показывает различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории.
1.4. Системы управления версиями второго поколения
Эффективному использованию систем управления версиями первого поколения мешало отсутствие поддержки многопользовательской удалён- ной работы. В 1986 году Дик Грун разработал систему управления версиями под названием Concurrent Version System (CVS) (GNU, 2015). CVS откры- вает эру систем управления версиями второго поколения, главным отли- чием которых от систем управления версиями первого поколения является поддержка многопользовательского режима работы (поддержка сети). С по- явлением этой системы географически распределённые команды разработ- чиков получили эффективный инструмент коллективной работы. Програм- мисты, находящиеся в разных точках земного шара, теперь могли взаимо- действовать так же эффективно, как при нахождении в одной комнате.
CVS представляет собой сетевой интерфейс для системы управления версиями первого поколения RCS. С точки зрения правил формирования файлов истории, в CVS нет никаких отличий от RCS. Отличия заключаются в процедуре доступа к файлам истории, которая реализует модель центра- лизованного репозитория. Под централизованным репозиторием понима- ется сетевое хранилище файлов, доступ к которому осуществляется через локальную или глобальную сеть.
Первый шаг по организации работы с CVS заключается в создании на удалённом сервере централизованного репозитория. Для выполнения этой работы используются специальные команды CVS. После того, как репози- торий создан, в него импортируется заготовка проекта, содержащая мини- мальный набор файлов. Вместо заготовки может быть импортирован проект, подлежащий доработке. Работу по созданию репозитория и импорту проекта обычно выполняет руководитель или инициатор проекта. В результате им- порта в репозитории создаются файлы истории для всех файлов проекта.
После создания репозитория каждый из участников проекта имеет
17 возможность скачать на свой локальный компьютер файлы истории. В от- личие от RCS, файлы истории в репозитории не блокируются после их ска- чивания, что позволяет работать с проектом неограниченному количеству программистов. Программисты редактируют файлы на своих локальных компьютерах и, по мере необходимости, фиксируют изменения в файлах ис- тории центрального репозитория. Если один из программистов обновил файл истории в репозитории, его коллеги должны обновить соответствую- щий рабочий файл на своих локальных компьютерах. Сделать это необхо- димо перед фиксацией изменений, внесённых в тот же файл, или для того, чтобы использовать (посмотреть) результаты работы коллеги. Процедура обновления рабочих копий, как правило, автоматизирована и не требует ручной работы. Правда, иногда возникают коллизии, которые необходимо устранить в ручном режиме перед фиксацией изменений.
История не сохранила сведений о том, когда появился термин «ком- мит», но при описании приёмов работы с системами управления версиями второго поколения он широко используется. Значит, необходимо дать опре- деление этого термина.
Коммит – это синоним выражения «зафиксировать изменения в файле ис- тории».
Система команд CVS объединяет в себе команды системы RCS и спе- цифические команды, обеспечивающие коллективную работу с централь- ным репозиторием. Вот список этих команд:
− export CVSOOT – задаёт корневой каталог репозитория CVS для того, чтобы его не нужно было в дальнейшем указывать в каждой команде;
− cvs import – импортировать директории проекта в репозиторий
CVS. Перед выполнением команды происходит автоматический переход в корневой каталог проекта;
− cvs checkout – копировать файлы проекта на локальный компьютер;
− cvs commit – коммит изменённого файла;
− cvs add – добавляет новый файл в репозиторий для отслеживания изменений;
− cvs update – обновить рабочую версию из репозитория для учёта
18 коммитов, сделанных другими программистами;
− cvs ststus – показать общую информацию об извлечённой рабочей версии;
− cvs tag – добавить информационный заголовок (тег) в файл или группу файлов;
− cvs tag –b – создать новую ветвь в репозитории;
− cvs checkout –r – извлечь ветвь из репозитория;
− cvs update –j – объединить ветвь из репозитория с локальной рабо- чей копией.
Дальнейшим развитием систем управления версиями второго поколе- ния стала система Subversion (C. Michael Pilato, 2008). Как и CVS, она осно- вана на технологии центрального репозитория.
В CVS возможна ситуация, когда коммит будет сохранён не полно- стью, например, из-за проблем с сетевым подключением. Частично сохра- нённый коммит будет рассматриваться как полный и при загрузке в рабочие версии создаст массу проблем. Для исключения таких ситуаций в Subversion предусмотрено журналирование. Перед началом записи очередного ком- мита в специальном файле, называемом журналом, делается запись о по- пытке выполнить коммит с подробной информацией о нём. Если операция была выполнена успешно, к этой записи добавляется отметка о завершении сохранения коммита. В случае сбоя отметка о завершении коммита не будет размещена в журнале. После восстановления работоспособности системы проверяется журнал на предмет наличия записей без отметок о завершении.
При наличии таких записей повторяются указанные в них коммиты.
Важной особенностью Subversion является то, что коммиты могут включать в себя не один файл, а группу файлов или каталогов. Это позво- ляет рассматривать набор связанных изменений как один коммит, что уве- личивает информативность сохранённых изменений.
В настоящее время Subversion поддерживается Apache Software Foun- dation и использует файловую систему FSFS (File System atop th File System).
В FSFS директории являются полноправными объектами, которые воз- можно включать в коммит. Каждый коммит хранится в отдельном файле.
Этим файлам присваиваются имена в виде последовательных числовых
19 идентификаторов. При первом коммите в файле сохраняется полный текст файла, при последующих – только дельты. Кроме того, коммиты сжимаются с помощью алгоритмов lz4 или zlib. Поскольку Subversion является наслед- ницей RCS, в ней используется система обратных дельт. При большом ко- личестве коммитов, относящихся к одному файлу, время восстановления ранних версий значительно увеличивается. Для борьбы с этим неудобством с Subversion используется соглашение о том, что после сохранения 1023 дельт снова сохраняется полная версия исходного файла.
Subversion использует не обычную систему ветвления. Шаблон репо- зитория содержит три директории:
− trunk;
− branches;
− tags.
Директория используется в следующих целях:
− trunk для хранения окончательных версий проекта, готовых для пе- редачи пользователю;
− branches для хранения вложенных папок, соответствующих различ- ным ветвям;
− tags для хранения обособленных частей проекта.
Ниже перечислены основные команды системы Subversion:
− svn create – создаёт новый пустой шаблон репозитория;
− svn import – импортировать проект в репозиторий (создать файлы истории для всех файлов проекта);
− svn checkout – загрузить рабочие версии из репозитория на локаль- ный компьютер;
− svn commit –m – создать коммит для набора файлов и директорий;
− svn add – добавить в репозиторий новый файл для отслеживания;
− svn update – обновить рабочую версию проекта; будут скачаны и добавлены изменения, внесённые другими программистами;
− svn status – отобразить список файлов, которые изменились (по- лезна в связке с предыдущей командой);
− svn info – общие сведения об извлечённой рабочей копии проекта;
− svn copy – создать новую ветку путём копирования существующей;