История изменений
Исправление hummer, (текущая версия) :
Дело в том, что для поддержания согласованности сорцов нужен единый центр принятия решений. Как в распределенных СУБД.
Но в случае распределённого контроля версий такого требования просто нет. Каждый Git репозиторий - это, по сути, отдельный форк проекта. Нужно ли их синхронизировать или нет, а если да, то как - личное дело каждого владельца своего локального репозитория.
Централизированный репозиторий — это очень хорошо, не подумайте, что я его виню в чем-то. Мои претензии относятся только к Git, который используют в роли SVN с локальным кэшированием истории.
Ну а как иначе обмениваться изменениями из множества распределённых репозиториев? Теоретически можно пушить во все сразу, но для этого нужно по крайней мере знать об их наличии и иметь к ним доступ. В случае Linux все дороги (PR-ы) ведут к Линусу (ну или к Грегу) и по настоящему форкать ядро никто не хочет. Та же модель используется и в большенстве других проектов. Ты это воспринимаешь как центральный сервер, но он не центральный, а консолидирующий.
Ну то есть локальное кэширование истории в SVN было бы намного лучше, чем Git, потому Git ни разу не идеально решение, потому Microsoft в итоге и сделала ту самую клиент-серверную поделку GVFS, которая хранит на локалхосте только непосредственно используемые файлы и историю — это уже околоидеальный вариант, но к модели разработки Git он почти никакого отношения не имеет, это уже не DVCS, а чисто центарилизованный online-only вариант.
C GVFS не знаком, звучит как некое подобие файловой системы ClearCase. Если этот GVFS бежит локально (на компьютере разработчика или на сервере офиса) и общается с внешним миром через Git, то почему это online-only вариант? На сколько я знаю Git поддерживает частичное клонирование репозитория, чтобы не скачивать всю историю всех 100500 файлов. https://git-scm.com/docs/partial-clone
Исходная версия hummer, :
Дело в том, что для поддержания согласованности сорцов нужен единый центр принятия решений. Как в распределенных СУБД.
Но в случае распределённого контроля версий такого требования просто нет. Каждый Git репозиторий - это, по сути, отдельный форк проекта. Нужно ли их синхронизировать или нет, а если да, то как - личное дело каждого владельца своего локального репозитория.
Централизированный репозиторий — это очень хорошо, не подумайте, что я его виню в чем-то. Мои претензии относятся только к Git, который используют в роли SVN с локальным кэшированием истории.
Ну а как иначе обмениваться изменениями из множества распределённых репозиториев? Теоретически можно пушить во все сразу, но для этого нужно по крайней мере знать об их наличии и иметь к ним доступ. В случае Linux все дороги (PR-ы) ведут к Линусу (ну или к Грегу) и по настоящему форкать ядро никто не хочет. Та же модель используется и в большенстве других проектов. Ты это воспринимаешь как центральный сервер, но он не центральный, а консолидируещий.
Ну то есть локальное кэширование истории в SVN было бы намного лучше, чем Git, потому Git ни разу не идеально решение, потому Microsoft в итоге и сделала ту самую клиент-серверную поделку GVFS, которая хранит на локалхосте только непосредственно используемые файлы и историю — это уже околоидеальный вариант, но к модели разработки Git он почти никакого отношения не имеет, это уже не DVCS, а чисто центарилизованный online-only вариант.
C GVFS не знаком, звучит как некое подобие файловой системы ClearCase. Если этот GVFS бежит локально (на компьютере разработчика или на сервере офиса) и общается с внешним миром через Git, то почему это online-only вариант? На сколько я знаю Git поддерживает частичное клонирование репозитория, чтобы не скачивать всю историю всех 100500 файлов. https://git-scm.com/docs/partial-clone