Комментарии 25
А как же Perforce, TFS?
Что же может быть в четвертом поколении?
Насчёт четвёртого не знаю, а вот про менеджмент версий бинарных файлов и специализированных средств визуализации для этого хотелось бы увидеть.
Имхо, pijul.org
Если коротко — другой подход к патчам, разрабатывается под влиянием теории категорий, системы darcs и довольно сильно отличается от последнего в плане алгоритмов.
Пару примеров для иллюстрации.
Первый: cherry-pick в git теряет информацию об авторстве. Черипикнув в свою ветку чей-то коммит, вы будете обречены на поддержку изменений и разрешение конфликтов. В pijul эта операция происходит гладко: система контроля версий не забывает о том, что этот коммит был притащен извне; при последующем слиянии веток случайных конфликтов не будет.
Второй: в pijul патчи можно таскать между репозиториями любым способом, хоть путем штатной синхронизации по сети, хоть голубями. Результат применения патча не будет зависеть от того, каким образом он был получен.
Если коротко — другой подход к патчам, разрабатывается под влиянием теории категорий, системы darcs и довольно сильно отличается от последнего в плане алгоритмов.
Пару примеров для иллюстрации.
Первый: cherry-pick в git теряет информацию об авторстве. Черипикнув в свою ветку чей-то коммит, вы будете обречены на поддержку изменений и разрешение конфликтов. В pijul эта операция происходит гладко: система контроля версий не забывает о том, что этот коммит был притащен извне; при последующем слиянии веток случайных конфликтов не будет.
Второй: в pijul патчи можно таскать между репозиториями любым способом, хоть путем штатной синхронизации по сети, хоть голубями. Результат применения патча не будет зависеть от того, каким образом он был получен.
- Поправка: автора как раз cherry-pick сохраняет, только всё равно создаёт новый коммит, не связанный с оригинальным (наверное Вы это и имели в виду).
- В гите тоже все по-своему патчами обмениваются. Тот же Linux разрабатывается по электронной почте.
Спасибо за исправления. Да, я имел в виду, что теряется информация об источнике изменений, а не об авторстве. В pijul один и тот же патч может одновременно присутствовать в нескольких ветках. Несколько не зависящих друг от друга патчей (меняющих разные файлы) могут присутствовать в разном порядке — на результат это не влияет. Самая жесть — конфликты слияний можно отложить «на потом», тогда как в git их контроль целиком лежит на пользователе.
Возможно в четвертом поколении будут встраиваемые VCS (т.е VCS как библиотека)
Сейчас куча инструментов построена вокруг гита (который хорошее ядро для того, чтобы сделать какой угодно завязанный на контроле версий инструмент) но в большинстве своем гит идет как отдельное приложение, а если будет библиотека предоставляющая базовые расширяемые возможности стандартных VCS команд я думаю мы увидим более интересные тулзы.
А еще было б прикольно иметь какой-нить стандартизированный язык запросов к VCS чтоб творить такие вещи — «Покажи все дифы в проекте „Мега монолит“ где ветка „супер важная фитча“ и автор „Вася“, смержил в мастер „Петя“ и коммент < 100 символов»
Сейчас куча инструментов построена вокруг гита (который хорошее ядро для того, чтобы сделать какой угодно завязанный на контроле версий инструмент) но в большинстве своем гит идет как отдельное приложение, а если будет библиотека предоставляющая базовые расширяемые возможности стандартных VCS команд я думаю мы увидим более интересные тулзы.
А еще было б прикольно иметь какой-нить стандартизированный язык запросов к VCS чтоб творить такие вещи — «Покажи все дифы в проекте „Мега монолит“ где ветка „супер важная фитча“ и автор „Вася“, смержил в мастер „Петя“ и коммент < 100 символов»
Автор забыл упомянуть о таких промышленных монстрах как ClearCase и Perforce. Довелось с ними работать несколько лет — очень мощные инструменты для работы больших команд, со своими плюсами и минусами.
Советую также посмотреть мои статьи на Хабре про управление версиями и конфигурацией
habr.com/ru/post/67751
habr.com/ru/post/67839
habr.com/ru/post/68932
habr.com/ru/post/72370
Советую также посмотреть мои статьи на Хабре про управление версиями и конфигурацией
habr.com/ru/post/67751
habr.com/ru/post/67839
habr.com/ru/post/68932
habr.com/ru/post/72370
Могли бы опрос прикрутить, кто какие использует. Интересно же…
Так есть такие, причем на разные года.
Хотелось бы какого-то анализа на тему «Почему при достаточной схожести Git взлетел, а Mercurial нет»
В статье, как мне кажется, очень не хватает пристального взгляда на проблемы бранчей, ибо эволюция систем контроля версий во многом определяется развитием философии бранчей.
На каждом шаге менялось понимание того, что именно хранит репозиторий. От независимых версий отдельных файлов перешли к понятию снапшота всего репозитория, а потом и множеству независимых снапшотов, с возможностью их слияния и, в итоге, к понятию бранча, как индивидуального инструмента работы. Последние разработки идут дальше и ориентируются уже на патчи, а не снапшоты.
Мое мнение, что именно эргономика бранчевания в конечном итоге определила успех git.
На каждом шаге менялось понимание того, что именно хранит репозиторий. От независимых версий отдельных файлов перешли к понятию снапшота всего репозитория, а потом и множеству независимых снапшотов, с возможностью их слияния и, в итоге, к понятию бранча, как индивидуального инструмента работы. Последние разработки идут дальше и ориентируются уже на патчи, а не снапшоты.
Мое мнение, что именно эргономика бранчевания в конечном итоге определила успех git.
Еще Fossil есть, в ней SQLite пилят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История систем управления версиями