>>> Они существенно сложнее в использовании чем централизованные.
>> не сложнее..
>Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ. "нужно"?? Вы уверены, что вы слова не перепутали?
Кому нужно?
Они синкают удаленные репозитории по мере надобности. И нужно это именно тому, кто
забирает обновления. Т.е. активность проявляет тот, кому нужно.
По-моему все на своих местах.
Мье не вкурсе что такое децентрализованные средства разработки? (раз упоминаете "несколько" хранилищь). Нет, это не имеет ничего общего с репликацией или кластеризацией.
Почитайте о git: http://git.or.cz/
>>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу, повышается вероятность что внесенные изменения никто не просмотрит и ухудшится качество кода.
>> непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.
>
>Всё довольно просто: Один из разработчиков вносит изменения в свою локальную копию
>проекта. Потом эти изменения рассылаются остальным участникам проекта. Чем больше хранилищ
>и чем протяжёнее граф синхронизации, тем больше вероятность, что одни разработчики
>работают с новой версией программы, а до других изменения ещё не
>дошли.
описанная вами ситуация не просто нормальна, она повседневна и естественна.
Я пишу свою экспериментальную фичу, которая нафик не нужна 95% разработчиков.
И незачем всем на свете пихать под нос мои соискания. Кто хочет - тот сам возьмет, посмотрит и будет держать себя вкурсе относительно моих разработок.
>>> Провоцирующая легкость создания новой ветви проекта.
>> и?
>
>И плохо!
В мире мало строго черного и строго белого (кроме маздая, он - чистое зло :D )
Итак, рассмотрим пример системы git, с помощью которой контролируется развитие ядра Линукс.
На git.kernel.org (всего-лишь там, для начала) уже существуют сотни веток Линуха.
В одной ветке ведется развитие одной подсистемы, в другой - другой и т.д. и т.п.
Все вменяемые новинки гогласно определенной политике собираются Торвальдсом и комиттятся в его ветку, которая уже собой представляет тот Линух, который выкладывают на kernel.org в виде тарболов.
Захотелось вам KGDB (ядерный дебаггер) "вне очереди", ну, пока там 2.6.26 еще не вышла.
Пошли, добавили удаленный репозитарий в множество следимых себе в репозиторий и хоть раз в 5 минут собираете оттуда изменения (если они там появляются). И у вас обычное 2.6.24.x,
но с KGDB, причем очень даже up2date. Торвальдс же ("основная" ветка к этому Kgdb лишь только подходит).
Так ли все плохо? ;)
>>> Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.
>> тоже непонятно.
>
>Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и
> не привыкли пользоваться распределённым хранением.
Согласен с каждым словом. Кроме того, это касается и некоммерческих разработчиков, которым ломы что-то радикально менять в своей системе контроля версий.
Собсно, задуматься лишь над фактом появления самой новости.
Если бы все было так шоколадно при централизованной разработке - то и новости бы не было ;)
а распределенные системы умерли не родившись (git, mercurial...).
Вариант для распечатки
Разговоры, обсуждение новостей (Public)
(ok) on 04-Май-08, 08:21 
