Система управления версиями — это программное обеспечение, которое помогает отслеживать изменения, вносимые в код с течением времени.
Введение
Системы контроля версий (VCS) первого поколения были способны отслеживать коррективы в отдельных файлах, а редактирование поддерживалось лишь локально и одним пользователем за один раз. Системы формировались с предположением, что каждый пользователь станет заходить в свои учетные записи на одном и том же общем узле Unix.
В VCS второго поколения была добавлена поддержка сети, что позволило создать централизованные хранилища с «официальными» версиями проектов. Это стало значительным прогрессом, так как несколько пользователей теперь могли одновременно обрабатывать код, создавая коммиты в один и тот же центральный репозиторий. Тем не менее для коммитов было необходимо обладать доступом к сети.
Третье поколение включает в свой состав распределенные VCS, в которых все копии репозитория должны считаться равными и отсутствует центральный репозиторий. Это позволяет открыть путь для коммитов, ветвей и слияний, создаваемых локально без доступа к сети и перемещаемых в другие репозитории по мере необходимости.
Системы управления версиями
На рисунке ниже приведен график c датами появления данных инструментов.
Рисунок 1. График. Автор24 — интернет-биржа студенческих работ
SCCS может считаться первой успешной системой управления версиями. Она была спроектирована в 1972=ом году Марком Рочкиндом из Bell Labs. Система была реализована на языке Cи и предназначалась, для того чтобы отслеживать версии исходного файла. Помимо этого, она смогла существенно облегчить поиск источников ошибок в программе. Основная архитектура и синтаксис SCCS предоставляют возможность понимания корней современных инструментов VCS.
Как и практически во всех современных системах, в SCCS имеется совокупность команд, предназначенных для работы с версиями файлов, а именно:
- Возможность внесения (check-in) файлов, для того чтобы отслеживать историю в SCCS.
- Возможность извлечения (check-out) конкретных версий файлов, для того чтобы осуществить анализ или компиляцию.
- Возможность извлечения конкретных версий для осуществления их редактирования.
- Возможность внесения новых версий файлов вместе с комментариями, которые объясняют внесенные изменения.
- Возможность отмены изменений, которые были внесены в извлеченный файл.
- Возможность просмотра основных ветвлений и слияния изменений.
- Возможность просмотра журнала изменений файла.
При добавлении файла для отслеживания в SCCS формируется файл специализированного типа, который именуется как s-файл или файл истории. Он называется исходным файлом, только с префиксом s., и должен храниться в подкаталоге SCCS. Например, для файла test.txt может быть сформирован файл истории s.test.txt в директории ./SCCS/. При его создании файл истории должен содержать исходное содержимое начального файла, а также определенный набор метаданных, который помогает отслеживать версии. Там сохраняются контрольные суммы, чтобы гарантировать, что содержимое не подвергалось изменениям. Содержимое файла истории не должно сжиматься и кодироваться, как это сделано в VCS следующего поколения.
Так как содержимое исходного файла теперь должно храниться в файле истории, то это означает, что он может быть извлечен в рабочий каталог для просмотра, компиляции или модификации. В файл истории могут быть внесены изменения, а именно, это может быть добавление строк, изменения и удаления, что приводит к увеличению его номера версии. Последующие добавления файла сохраняют лишь дельты или изменения, а не все его содержимое. Это позволяет уменьшить размеры файла истории.
Все дельта сохраняются внутри файла истории в структуре, именуемой как дельта-таблица. Как было отмечено выше, фактическое содержимое файла должно по возможности копироваться дословно, с набором специальных управляющих последовательностей, для того чтобы маркировать начало и конец разделов добавленного и удаленного содержимого. Поскольку файлы истории SCCS не могут использовать сжатие, они, как правило, обладают большим размером, чем фактический файл, в котором требуется отследить изменения. SCCS применяет метод, имеющий название чередующиеся дельты (interleaved deltas), который может гарантировать постоянное время извлечения вне зависимости от давности извлеченной версии. Это означает, что более старые версии могут извлекаться с той же скоростью, что и новые.
Следует заметить, что все файлы могут отслеживаться и регистрироваться отдельно. Отсутствует возможность проверки изменений в нескольких файлах в виде одного атомарного блока, как коммиты в Git. У любого отслеживаемого файла имеется собственный файл истории, сохраняющий его историю изменений. В общем случае это значит, что номера версий разных файлов в проекте, как правило, могут не совпадать друг с другом. Тем не менее данные версии могут быть согласованы за счет одновременного редактирования всех файлов в проекте (даже без внесения в них реальных изменений) и одновременного добавления всех файлов.
Это может одновременно увеличить номер версии для всех файлов, сохраняя их согласованность. Однако следует помнить, что это не то же самое, что включение нескольких файлов в один коммит, как в Git. В SCCS осуществляется индивидуальное добавление в каждый файл истории, в отличие от одного большого коммита, который включает все изменения сразу.
При извлечении файла для редактирования в SCCS, на него устанавливается блокировка, так что его запрещено редактировать. Это должно предотвратить перезапись изменений другими пользователями, но при этом может ограничивать разработку, поскольку в каждый момент времени только одному пользователю разрешается работать с данным файлом. SCCS может поддерживать ветви, в которых хранятся последовательности изменений в определенном файле. Имеется возможность осуществления слияния ветви с исходной версией или с другой веткой.
