какие есть системы контроля версий
Что такое система контроля версий? 5 систем управления версиями с открытым исходным кодом
Система контроля версий относится к процессу, касающемуся систематизации версий, объединяемых при редактировании и совместной работе. Хотя контроль версий как термин рассматривается в контексте разработки программного обеспечения, на самом деле, он необходим для профессионалов разных отраслей.
Для крупных проектов по разработке программного обеспечения системы контроля версий отслеживают множество изменений в исходном коде.
Почему так важны системы контроля версий?
Все системы контроля версий обладают следующими возможностями:
Существуют разные системы управления версиями, но какие отличительные черты делают их уникальными? Перечислим три их главные группы:
5 систем контроля версий с открытым исходным кодом
CVS является самой популярной и широко применяемой системой контроля версий на сегодняшний день. После выпуска в 1986 году она быстро стала общепринятым стандартом. CVS приобрела популярность благодаря простой системе поддержки файлов и ревизий в актуальном состоянии.
Достоинства системы контроля версий SVN
Mercurial
Считается эффективной для крупных проектов, в которых участвует много разработчиков и проектировщиков. Mercurial – это высокопроизводительная система, предлагающая оптимальную скорость. Она также известна своей простотой и подробной документацией.
Достоинства Mercurial системы контроля версий
Bazaar
Уникальна тем, что может использоваться с распределенной и централизованной базой кода. Это делает ее универсальной системой контроля версий. Кроме этого Bazaar позволяет использовать детальный уровень управления. Ее можно легко развернуть в самых разных сценариях, что делает ее адаптивной и гибкой для всевозможных проектов.
Что касается популярности, порога вхождения, производительности и адаптивности, рассмотренные в этой статье системы контроля версий существенно превосходят другие.
Пожалуйста, оставляйте свои отзывы по текущей теме материала. Мы очень благодарим вас за ваши комментарии, отклики, лайки, дизлайки, подписки!
Пожалуйста, оставляйте ваши отзывы по текущей теме материала. Мы очень благодарим вас за ваши комментарии, дизлайки, лайки, отклики, подписки!
О системах контроля версий
Всем привет! Уже на следующей неделе в OTUS стартует «Супер-практикум по использованию и настройке GIT». Этому я и решил посвятить сегодняшнюю публикацию.
Введение
Системы контроля версий
Система контроля версий является прежде всего инструментам, а инструмент призван решать некоторый класс задач. Итак, система контроля версий – это система, записывающая изменения
в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы хотим гибко управлять некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть кто что-то поменял. Как правило системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа.
Как хранить различные версии файлов? Люди пришли к такому инструменту как системы контроля версий не сразу, да и они сами бывают очень разные. Предложенную задачу можно решить с применением старого доброго copy-paste, локальных, централизованных или распределенных систем контроля версий.
Copy-paste
Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_
Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).
Локальная система контроля версий
Следующим шагом в развитии систем контроля версий было создание локальных систем контроля версий. Они представляли из себя простейшую базу данных, которая хранит записи обо всех изменениях в файлах.
Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux’ом.
Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство — локальность. Она совершенно не преднезначена для коллективного использования.
Централизованная система контроля версий
Централизованная система контроля версий предназначена для решения основной проблемы локальной системы контроля версий.
Для организации такой системы контроля версий используется единственный сервер, который содержит все версии файлов. Клиенты, обращаясь к этому серверу, получают из этого централизованного хранилища. Применение централизованных систем контроля версий на протяжении многих лет являлась стандартом. К ним относятся CVS, Subversion, Perforce.
Такими системами легко управлять из-за наличия единственного сервера. Но при этом наличие централизованного сервера приводит к возникновению единой точки отказа в виде этого самого сервера. В случае отключения этого сервера разработчики не смогут выкачивать файлы. Самым худшим сценарием является физическое уничтожение сервера (или вылет жесткого диска), он приводит к потерю кодовой базы.
Несмотря на то, что мода на SVN прошла, иногда наблюдается обратный ход — переход от Git’а к SVN’у. Дело в том, что SVN позволяет осуществлять селективный чекаут, который подразумевает выкачку лишь некоторых файлов с сервера. Такой подход приобретает популярность при использовании монорепозиториях, о которых можно будет поговорить позже.
Распределенная система контроля версий
Для устранения единой точки отказа используются распределенные системы контроля версий. Они подразумевают, что клиент выкачает себе весь репозиторий целиком заместо выкачки конкретных интересующих клиента файлов. Если умрет любая копия репозитория, то это не приведет к потере кодовой базы, поскольку она может быть восстановлена с компьютера любого разработчика. Каждая копия является полным бэкапом данных.
Все копии являются равноправным и могут синхронизироваться между собой. Подобный подход очень напоминает (да и является) репликацией вида master-master.
К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.
История Git
В 2005 году компания, разрабатывающая систему контроля версий BitKeeper, порвала отношения с сообществом разработчиков ядра Linux. После этого сообщество приняло решение о разработке своей собственной системы контроля версий. Основными ценностями новой системы стали: полная децентрализация, скорость, простая архитектура, хорошая поддержка нелинейной разработки.
Заключение
Мы рассмотрели способы организации систем контроля версий, обсудили варианты решения поставленных перед этими системами задач, поговорили о преимуществах и недостатках каждого из них, познакомились с историей системы контроля версий Git.
Актуальные инструменты контроля версий данных в 2020 году
Все мы знаем и любим Git. И, конечно же, были придуманы его аналоги для управления версиями данных, чтобы эксперименты с данными были воспроизводимыми, а действия команд — согласованными. Сегодня, в преддверии старта нового потока курса по Data Science, делимся с вами материалом о сравнении нескольких систем контроля версий. Подробности сравнения — как обычно, под катом.
Используете вы логистическую регрессию или нейронную сеть, в любом случае все модели требуют данных для обучения, тестирования и развертывания. Создание используемых моделями наборов данных и управление ими требуют много времени и пространства, а кроме прочего, могут быстро запутаться из-за того, что несколько пользователей изменяют и обновляют данные. Это, в свою очередь, приводит к неожиданным результатам, поскольку дата-сайентисты продолжают выпускать новые версии моделей, но тестируют их на разных наборах данных.
Но множество дата-сайентистов могли бы заниматься подготовкой и разработкой моделей на основе одних тех же наборов учебных данных. Это приведёт к большому количеству тонких изменений в наборе данных, которые, в свою очередь, после развёртывания моделей могут привести к неожиданным результатам. В этом посте обсуждаются проблемы, приходящие с управлением данными, и даётся обзор топовых инструментов для машинного обучения и управления версиями данных.
Проблемы управления данными
Управление наборами данных и таблицами для Data Science и моделей машинного обучения требует от дата-сайентистов и инженеров значительных временных затрат. Всё, начиная с управления хранилищем, версиями данных и заканчивая доступом, требует большого ручного труда.
Пространство хранилища
Обучающие данные могут занимать значительное место в репозиториях git. Это связано с тем, что git разработан для отслеживания изменений в текстовых, но в небольших бинарных файлах. Поэтому, когда наборы тренировочных данных содержат большие аудио- или видео-файлы, в дальнейшем это приносит много проблем. Каждое изменение в наборе обучающих данных приводит к дублированию набора данных в истории репозиториев. Такое дублирование не только делает репозиторий большим, но и значительно замедляет его клонирование и перебазирование (git rebase).
Управление версиями данных
В попытке управлять версиями (будь то код или пользовательский интерфейс) даже среди технарей широко распространена тенденция «управлять версиями», добавляя номер версии или слово в конец имени файла.
В контексте данных это означает, что проект может содержать файлы data.csv, data_v1.csv, data_v2.csv, data_v3_finalversion.csv и т.д. Эта плохая привычка — не просто клише: с плохих привычек версионирования на самом деле начинают большинство разработчиков, дата-сайентистов и экспертов пользовательского интерфейса.
Многопользовательская среда
При работе в производственной среде одна из самых больших проблем — работа с другими дата-сайентистами. Если вы не используете какую-то форму управления версиями в среде совместной работы, файлы удаляются, изменяются и перемещаются, а вы не знаете, кто и что сделал. Кроме того, сложно вернуть данные в исходное состояние. Когда речь заходит об управлении моделями и наборами данных, это одна из самых больших проблем.
Обзор лучших альтернатив в управлении версиями данных
Версионирование данных — один из ключей к автоматизации разработки модели машинного обучения в разрезе команды. Очень сложно разработать собственную систему для управления процессом, но, к счастью, в этом нет необходимости. Давайте посмотрим на 6 великолепных инструментов с открытым исходным кодом, которые ваша команда может применять, чтобы упростить управления данными и версионирование.
DVC, или Data Version Control, — это один из многих доступных инструментов с открытым исходным кодом, упрощающих работу с проектами Data Science и ML.
Используется подход Git’а в том смысле, что дает интерфейс командной строки, который настраивается в несколько простых шагов. DVC, как предполагает его название, фокусируется не только на версионировании данных. Инструмент помогает командам управлять конвейерами и моделями машинного обучения. В конце концов, DVC способствует согласованности вашей команды и воспроизводимости ваших моделей.
Преимущества
Недостатки
Delta Lake
Delta Lake — это слой хранилища с открытым исходным кодом, помогающий улучшить состояние озёр данных. Это делается предоставлением транзакций ACID, версионированием данных, управлением метаданными и управлением версиями данных. Инструмент находится ближе к слою абстракции озёр данных, заполняя пробелы там, где большинство озёр данных ограничены.
Преимущества
Недостатки
Git LFS
Git LFS — разработанное рядом разработчиков расширение Git’а с открытым исходным кодом. Это ПО предназначено для устранения больших файлов, которые могут быть добавлены в ваше хранилище (например фотографий и наборов данных) с помощью указателей. Указатели легче, они указывают на хранилище LFS. Таким образом, когда вы отправляете изменения из вашего репозитория в основной, обновление не занимает много времени или места. Это очень легковесный вариант для управления данными.
Преимущества
Недостатки
Pachyderm
Pachyderm — одна из немногих платформ для сбора данных в этом списке. Цель Pachyderm — создать платформу, позволяющую легко воспроизводить результаты моделей ML, управляя всем рабочим процессом обработки данных. В этом отношении Pachyderm — Docker для данных.
Pachyderm использует контейнеры Docker для упаковки вашей среды выполнения. Это позволяет легко воспроизвести результат. Сочетание версионирования данных и Docker дает специалистам Data Science и командам DevOps легко развёртывать модели и обеспечивать их согласованность. Компания Pachyderm взяла на себя обязательства по Биллю о правах в Data Science, в котором изложены основные цели продукта: воспроизводимость, знание истории данных, сотрудничество, инкрементальность и автономия, а также абстрагирование инфраструктуры. Эти принципы определяют многие из особенностей продукта и позволяют командам воспользоваться преимуществ инструмента в полной мере.
Преимущества
Недостатки
Dolt — уникальное решение для версионирования данных. В отличие от некоторых других представленных вариантов, которые просто содержат данные о версии, Dolt — это база данных SQL с версиями в стиле Git. Но в отличие от Git’а, где в центре файлы, у Dolt в центре — таблицы. Это означает, что вы можете обновлять и изменять данные, не беспокоясь о потере изменений. Приложение ещё новое, в ближайшем будущем планируется сделать его на 100 % совместимым с Git и MySQL.
Преимущества
Недостатки
LakeFS
Подобно Delta Lake, LakeFS обеспечивает соответствие ACID в ваших озёрах данных. Однако LakeFS поддерживает как AWS S3, так и Google Cloud Storage в качестве бэкендов, а это означает, что для использования всех преимуществ не требуется использовать Spark.
Преимущества
Недостатки
Вам Действительно нужно управление версиями данных?
При всех преимуществах версионирования данных не всегда нужно вкладывать огромные усилия в управление ими. Например, большая часть версий данных предназначена, чтобы помочь отслеживать наборы данных, которые сильно меняются с течением времени.
К некоторым данным, таким как веб-трафик, другие данные только добавляются. Это означает, что данные добавляются, но редко изменяются. То есть версии данных, необходимых для создания воспроизводимых результатов, — это даты начала и окончания. Важно это отметить, поскольку в таких случаях, возможно, вам удастся избежать установки упомянутых выше инструментов. Вам всё равно нужно будет управлять датами начала и окончания, чтобы убедиться, что вы тестируете систему и модели на одних и тех же данных. Однако в таких случаях не обязательно фиксировать все данные в системе версионирования.
Итоги
Управление версиями данных — необходимый шаг для команд дата-сайентистов, позволяющий избежать несоответствий выходных данных. Используете ли вы Git-LFS, DVC или другой обсуждаемый инструмент, потребуется некоторая версионность данных. Эти инструменты версионирования данных могут помочь сократить объем памяти, необходимый для управления наборами данных, а также помочь отслеживать вносимые членами команды изменения. Без инструментов для версионирования данных ваш дежурный специалист может отлаживать модель в 3 часа ночи из-за проблемы, возникшей по причине несовпадения результатов моделирования. Однако всего этого можно избежать, если ваши команды специалистов по работе с данными внедрили процесс управления версиями данных.
На тот случай если вы задумали сменить сферу или повысить свою квалификацию — промокод HABR даст вам дополнительные 10% к скидке указанной на баннере.
История систем управления версиями
В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):
В VCS второго поколения появилась поддержка сети, что привело к централизованным хранилищам с «официальными» версиями проектов. Это был значительный прогресс, поскольку несколько пользователей могли одновременно работать с кодом, делая коммиты в один и тот же центральный репозиторий. Однако для коммитов требовался доступ к сети.
Третье поколение состоит из распределённых VCS, где все копии репозитория считаются равными, нет центрального репозитория. Это открывает путь для коммитов, ветвей и слияний, которые создаются локально без доступа к сети и перемещаются в другие репозитории по мере необходимости.
Хронология выхода VCS
Для контекста, вот график c датами появления этих инструментов:
SCCS (Source Code Control System): первое поколение
SCCS считается одной из первых успешных систем управления версиями. Она была разработана в 1972 году Марком Рочкиндом из Bell Labs. Система написана на C и создана для отслеживания версий исходного файла. Кроме того, она значительно облегчила поиск источников ошибок в программе. Базовая архитектура и синтаксис SCCS позволяют понять корни современных инструментов VCS.
Архитектура
Как и большинство современных систем, в SCCS есть набор команд для работы с версиями файлов:
Поскольку содержимое исходного файла теперь хранится в файле истории, его можно извлечь в рабочий каталог для просмотра, компиляции или редактирования. В файл истории можно внести изменения, такие как добавления строк, изменения и удаления, что увеличивает его номер версии.
Важно отметить, что все файлы отслеживаются и регистрируются отдельно. Невозможно проверить изменения в нескольких файлах в виде одного атомарного блока, как коммиты в Git. У каждого отслеживаемого файла свой файл истории, в котором хранится его история изменений. В общем случае это означает, что номера версий различных файлов в проекте обычно не совпадают друг с другом. Однако эти версии можно согласовать путём одновременного редактирования всех файлов в проекте (даже не внося в них реальные изменения) и одновременного добавления всех файлов. Это одновременно увеличит номер версии для всех файлов, сохраняя их согласованность, но обратите внимание, что это не то же самое, что включение нескольких файлов в один коммит, как в Git. В SCCS происходит индивидуальное добавление в каждый файл истории, в отличие от одного большого коммита, включающего все изменения сразу.
Когда файл извлекается для редактирования в SCCS, на него ставится блокировка, так что его никто больше не может редактировать. Это предотвращает перезапись изменений другими пользователями, но также ограничивает разработку, потому что в каждый момент времени только один пользователь может работать с данным файлом.
SCCS поддерживает ветви, которые хранят последовательности изменений в определённом файле. Можно произвести слияние ветви с исходной версией или с другой веткой.
Основные команды
Ниже приведён список наиболее распространенных команд SCCS.
Пример файла истории SCCS
RCS (Revision Control System): первое поколение
RCS написана в 1982 году Уолтером Тихи на языке С в качестве альтернативы системе SCCS, которая в то время не была опенсорсной.
Архитектура
У RCS много общего со своим предшественником, в том числе:
В SCCS иначе: там извлечение любой версии занимает одинаково времени. Кроме того, в файлах истории RCS не хранится контрольная сумма, поэтому нельзя обеспечить целостность файла.
Основные команды
Ниже список наиболее распространённых команд RCS:
Пример файла истории RCS
CVS (Concurrent Versions System): второе поколение
CVS создана Диком Груном в 1986 году с целью добавить в систему управления версиями поддержку сети. Она также написана на C и знаменует собой рождение второго поколения инструментов VCS, благодаря которым географически рассредоточенные команды разработчиков получили возможность работать над проектами вместе.
Архитектура
Разработчик получает копию модуля, который копируется в рабочий каталог на его локальном компьютере. В этом процессе никакие файлы не блокируются, так что нет ограничения на количество разработчиков, которые могут одновременно работать с модулем. Разработчики могут изменять свои файлы и по мере необходимости фиксировать изменения (делать коммит). Если разработчик фиксирует изменение, другие разработчики должны обновить свои рабочие копии с помощью (обычно) автоматизированного процесса слияния перед фиксацией своих изменений. Иногда приходится вручную разрешать конфликты слияния, прежде чем выполнить коммит. CVS также предоставляет возможность создавать и объединять ветви.
Основные команды
Пример файла истории CVS
SVN (Subversion): второе поколение
Subversion создана в 2000 году компанией Collabnet Inc., а в настоящее время поддерживается Apache Software Foundation. Система написана на C и разработана как более надёжное централизованное решение, чем CVS.
Архитектура
Как и CVS, Subversion использует модель централизованного репозитория. Удалённым пользователям требуется сетевое подключение для коммитов в центральный репозиторий.
Subversion представила функциональность атомарных коммитов с гарантией, что коммит либо полностью успешен, либо полностью отменяется в случае проблемы. В CVS при неполадке посреди коммита (например, из-за сбоя сети) репозиторий мог остаться в повреждённом и несогласованном состоянии. Кроме того, коммит или версия в Subversion может включать в себя несколько файлов и директорий. Это важно, потому что позволяет отслеживать наборы связанных изменений вместе как сгруппированный блок, а не отдельно для каждого файла, как в системах прошлого.
В настоящее время Subversion использует файловую систему FSFS (File System atop the File System). Здесь создаётся база данных со структурой файлов и каталогов, которые соответствуют файловой системе хоста. Уникальная особенность FSFS заключается в том, что она предназначена для отслеживания не только файлов и каталогов, но и их версий. Это файловая система с восприятием времени. Кроме того, директории являются полноценными объектами в Subversion. В систему можно коммитить пустые директории, тогда как остальные (даже Git) не замечают их.
Такая система работает только до определёного момента. Хотя дельты экономят место, но если их очень много, то на операции уходит немало времени, так как для воссоздания текущего состояния файла нужно обработать все дельты. По этой причине по умолчанию Subversion сохраняет до 1023 дельт на файл, а потом делает новую полную копию файла. Это обеспечивает хороший баланс хранения и скорости.
SVN не использует обычную систему ветвления и тегов. Обычный шаблон репозитория Subversion содержит три папки в корне:
Основные команды
Пример файла истории SVN
Git: третье поколение
Систему Git разработал в 2005 году Линус Торвальдс (создатель Linux). Она написана в основном на C в сочетании с некоторыми сценариями командной строки. Отличается от VCS по функциям, гибкости и скорости. Торвальдс изначально написал систему для кодовой базы Linux, но со временем её сфера использования расширилась, и сегодня это самая популярная в мире система управлениями версиями.
Архитектура
Git является распределённой системой. Центрального репозитория не существует: все копии создаются равными, что резко отличается от VCS второго поколения, где работа основана на добавлении и извлечении файлов из центрального репозитория. Это означает, что разработчики могут обмениваться изменениями друг с другом непосредственно перед объединением своих изменений в официальную ветвь.
Кроме того, разработчики могут вносить свои изменения в локальную копию репозитория без ведома других репозиториев. Это допускает коммиты без подключения к сети или интернету. Разработчики могут работать локально в автономном режиме, пока не будут готовы поделиться своей работой с другими. В этот момент изменения отправляются в другие репозитории для проверки, тестирования или развёртывания.
Когда ветви перемещаются в удалённые хранилища или извлекаются из них, по сети передаются эти пакетные файлы. При вытягивании или извлечении ветвей файлы пакета распаковываются для создания свободных объектов в репозитории объектов.
Основные команды
Пример блоба, дерева и коммита Git
Блоб с хэшем 37d4e6c5c48ba0d245164c4e10d5f41140cab980 :
Объект дерева с хэшем b769f35b07fbe0076dcfc36fd80c121d747ccc04 :
Коммит с хэшем dc512627287a61f6111705151f4e53f204fbda9b :
Mercurial: третье поколение
Mercurial создан в 2005 году Мэттом Макколлом и написан на Python. Он тоже разработан для хостинга кодовой базы Linux, но для этой задачи в итоге выбрали Git. Это вторая по популярности система управления версиями, хотя она используется гораздо реже.
Архитектура
Mercurial — тоже распределённая система, которая позволяет любому числу разработчиков работать со своей копией проекта независимо от других. Mercurial использует многие из тех же технологий, что и Git, в том числе сжатие и хэширование SHA-1, но делает это иначе.
Наконец, Mercurial использует ещё один тип revlog, который называется changelog, то есть журнал изменений. Это список записей, которые связывают каждый коммит со следующей информацией:
Основные команды
Пример файлов Mercurial
Журнал изменений (changelog):
Дополнительная информация об устройстве Mercurial: