Системы контроля версий и Пакетные менеджеры
Запись от Mysterious Light размещена 27.01.2018 в 19:45
Показов 2820
Комментарии 0
Метки системы контроля версий
Начну с чужого высказывания:
Есть ли разница между СКВ и ПМ? Под СКВ понимаются распределённые системы, вроде git, hg, veracity, darcs, pijul. Под ПМ языко-специфичные, вроде npm, cabal, pip. На первый взгляд кажется, что они решают похожие задачи: управление версиями всей системы и зависимостями подсистем (пакетов, файлов) между собой. Кроме этого, они обеспечивают скачивание из удалённого репозитория (для ПМ, как правило, единственного официального). Впрочем, область применения СКВ и ПМ разнится: СКВ используются для совместной разработки, изменения кода, ветвления, слияния и ведения истории. Не все СКВ позволяют скачивать только интересующую подсистему в интересующей версии со всеми зависимыми подсистемами в требуемых версиях: некоторые требуют полную загрузку всего репозитория и/или восстанавливаемой ревизии. Для справки: до 2014 года приём shallow cloning в git, который позволял загружать не всю историю, а только фрагмент, работал с ограничениями; sparse checkout, которая позволяет взять из ревизии только отдельную директорию, появился в git в 2012г, то есть по прошествию 7 лет от первого релиза. ПМ используются для автоматического скачивания и установки необходимых подсистем со всеми зависимыми в нужных версиях. Дополнительные возможности: своевременные обновления, не ломающие зависимости. Замечу, что ПМ заведомо не выкачивает весь репозиторий (тем более, со всеми существующими версиями всех пакетов) для того, чтобы пользователь мог использовать некоторые пакеты из него. Кроме этого, ПМ не ставит перед собой задачу слияния, т.е. (полу)автоматического согласования разных обновлений одной версии пакета (т.е. как в централизованных СКВ). По моему мнению, СКВ и ПМ исторически решают немножко разные задачи: СКВ предназначены для именования патчей/ревизий, организации потока кода между ветками/репозиториями, ветвления и слияния, тогда как ПМ нужны для сборки корректной (т.е. обновленной, со всеми багфиксами) версии всего проекта за счёт разрешения логических зависимостей между подсистемами. Рассмотрим в качестве примера патч B, который исправляет баг, внесённый в пакет/модуль патчем A. Для простоты можно считать, что A есть первый и единственный коммит, который определяет первую версию пакета/модуля. С точки зрения СКВ B зависит от A: патч B применим только поверх A, потому что невозможно исправить (B) баг в пакете, который ещё не написан (A). Невозможно применение B без A, невозможно применение A поверх B. С точки зрения ПМ B зависит от A. В случае семантических версий это отражено в том, что версия пропатченного пакета (AB) строго больше версии исходного (A). При этом с точки зрения ПМ имеет место зависимость в некотором смысле A от B, потому что в случае, когда пользователь хочет закачать пакет версии A, ПМ обязан закачать также патч B. Возможно ли полноценно симулировать ПМ средствами СКВ? По-моему, да, только лишь если появится возможность задавать зависимости из прошлого в будущее. А что вы думаете насчёт возможности создания инструмента, эффективно совмещающего в себе функции и задачи ПМ и СКВ? |
Сообщение от pointfree
Метки системы контроля версий
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 0
Комментарии
