| 1.2, denis_ka (?), 09:06, 04/05/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
половину утверждений не совсем правильны
>Они существенно сложнее в использовании чем централизованные.
не сложнее..
>Огромное (до сотни) количество команд управления.
одна команда bzr, или hg, которые практически повторяют svn
>Поскольку можно вносить изменения не обращаясь к центральному хранилищу, повышается вероятность что внесенные изменения никто не просмотрит и ухудшится качество кода.
непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.
>Провоцирующая легкость создания новой ветви проекта.
и?
>Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.
тоже непонятно..
можно так выразится, открытые языки не соответствуют "современной модели коммерческой разработки ПО". Или открытые ОС не соответствуют "современной модели коммерческой разработки ПО".
git, bzr, hg, svn, cvs, vss - это просто инструменты. как их использовать, кто их использует, и "современной модели коммерческой разработки ПО" - это разные вещи.
короче минусы децентрализованных не раскрыты...
| | |
| |
| 2.3, Дмитрий Ю. Карпов (?), 09:17, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Они существенно сложнее в использовании чем централизованные.
> не сложнее..
Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ.
>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу, повышается вероятность что внесенные изменения никто не просмотрит и ухудшится качество кода.
> непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.
Всё довольно просто: Один из разработчиков вносит изменения в свою локальную копию проекта. Потом эти изменения рассылаются остальным участникам проекта. Чем больше хранилищ и чем протяжёнее граф синхронизации, тем больше вероятность, что одни разработчики работают с новой версией программы, а до других изменения ещё не дошли.
>> Провоцирующая легкость создания новой ветви проекта.
> и?
И плохо!
>> Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.
> тоже непонятно.
Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и не привыкли пользоваться распределённым хранением.
| | |
| |
| 3.4, denis_ka (?), 09:41, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ.
и в svn можно не обновляться и не синхронизироваться. "и как можно поддерживать синхронность нескольких рабочих каталогов, не понимаю" :-)
>Потом эти изменения рассылаются остальным участникам проекта.
зачем остальным?
выбрали один репозиторий главным (или выбрали управляющего, или иерархию владельцев кода), и туда сливаются патчи. а потом кому надо тот и обновляется. практически та же самая централизованная разработка :-)
Работать с децентрализованной системой можно по разному :-)
>Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и не привыкли пользоваться распределённым хранением.
Перевожу: коммерческие разработчики привыкли пользоваться ЧЕМ-ТО и не хотят переходить на новое ЧТО-ТО.
| | |
| |
| 4.11, Nick (??), 14:06, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >выбрали один репозиторий главным (или выбрали управляющего, или иерархию владельцев кода), и
>туда сливаются патчи. а потом кому надо тот и обновляется. практически
>та же самая централизованная разработка :-)
>
>Работать с децентрализованной системой можно по разному :-)
вот вот.
Если инструмент создан быть децентрализованным - то его можно использовать и централизованно. Эту возможность никто у него не отнимает.
Более того, конкретно git способен эмулировать работу SVN или CVS серверов ;)
Т.е. это именно более "гибкая колбаса" :)
| | |
|
| 3.8, Nick (??), 13:08, 04/05/2008 [^] [^^] [^^^] [ответить] | +/– | нужно Вы уверены, что вы слова не перепутали Кому нужно Они синкают удален... большой текст свёрнут, показать | | |
|
| 2.6, Andrew Kolchoogin (?), 10:04, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу,
>> повышается вероятность что внесенные изменения никто не просмотрит,
>> и ухудшится качество кода.
> непонятно что имеется в виду, потому что предложение бред, может не так
> перевели с en.
Имеется в виду следующее: наличие централизованного хранилища накладывает на процесс разработки свой отпечаток, выражающийся в том, что изменения надо коммитить часто и мелкими кусками (ну, если, конечно, нет желания получить по шляпе от руководителя проекта за два рабочих дня, впустую потраченных на устранение конфликтов :), и эти мелкие куски сразу видны всем. Соответственно, довольно просто делать cross-auditing кода, когда другие девелоперы видят недоработки или "тупые баги" (опечатки, etc.) друг друга.
Отсутствие централизованного хранилища, собственно, и придумано было для того, чтобы так НЕ делать: обмениваться уже довольно здоровыми патчами (иначе все преимущества распределенного хранения репозитария будут сведены на "нет"). Но такие патчи не так уж и просто просмотреть глазами на предмет аудита -- они большие, затрагивают много файлов, функционал далеко не очевиден, и так далее, и тому подобное.
А то, что отсутствие cross-auditing'а ухудшает качество кода, надеюсь, очевидно всем, кто написал что бы то ни было сложнее, чем "Hello, World!" :)
| | |
| |
| 3.9, Nick (??), 13:36, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
все хорошо в вашей точке зрения окромя одной маленькой вещи.
Вы приравняли децентрализованный метод разработки и большие коммиты, а следом и более никзое качество кода.
А это и нелогично и неправильно.
Нелогично.
Даже самому разработчику проще разбиратся в маленьких коммитах, чем в простынях.
Неправильно.
Исходя из того, что в самом репозитории разработчика коммиты не стремятся к огромным размерам - то и стянутые другими разработчиками эти же коммиты не изменят свой размер.
Аудит.
Всем подряд разработчикам просто делать нечего как заниматься аудитом друг друга.
Ессьно, это касается лишь свободных разработчиков. Политики организаций этот вопрос могут решать по-своему.
Так вот: мне хочеться писать свои вещи, а вы предлагаете вместо этого заниматься аудитом?
Вобщем, спутаны 2 вещи: разработка и аудит.
Для примера взгляните сюда:
http://git.kernel.org/?p=linux/kernel/git/viro/audit-current.git;a=summary
человек ведет ветку с целью аудита кода некоторых подсистем.
Все. Он берет в эту ветку лишь исследуемый код и все.
Остальное все может быть вообще полным г-ном. Смысл его подвергать аудиту если даже идея хромает? И хромоту идеи нужно обсуждать тоже централизованно если имеет место единое хранилище. А это может быть и тормозом прогресса...
Вон посмотрите лишь на новость пару дней отроду об Pidgin'е. ВАУ-ВАУ! Форк! Ухты!
Да в распределенной системе об этом никто б не стал спорить. Повел я свою ветку, выложил у себя на сайте и до свидания.
Практически невозможно писать абсолютно правильно и рационально одну версию одного проекта. Кто авторитетно заявит, что выбранный путь - ТРУъ? А заявит человек. А раз человек - значит может быть неправ...
Собственно, Линукс своими темпами роста отчасти обязан правильно выбранной системе управления исходным кодом. Никто никому не указ. Каждый пиши что хочешь в своем домашнем репозитории :) А Торвальдс лишь собирает тот код в ваниллу, который считает нужным.
| | |
| |
| 4.15, fi (ok), 17:12, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Нелогично.
>Даже самому разработчику проще разбиратся в маленьких коммитах, чем в простынях.
Вы не подумав написали? или просто не работаете в этой области?
Простыня состоит из небольших коммитов в свой репозитарий, а затем мержить то все равно нужно.
>Аудит.
>Всем подряд разработчикам просто делать нечего как заниматься аудитом друг друга.
>Ессьно, это касается лишь свободных разработчиков. Политики организаций этот вопрос могут решать
>по-своему.
>Так вот: мне хочеться писать свои вещи, а вы предлагаете вместо этого
>заниматься аудитом?
Прежде чем сделать ci я всегда проверю на предмет, что поменялась в моей ветке без меня (сделаю diff и если нужно, затем сделаю up). Зачастую, я делаю проверки чаще чем коммиты. Естественно, я вижу многие вещи, нахожу ошибки (что недавно и произошло). В случаи децентрализованного хранилища, это затруднительно, т.к. изменения накапливаются в другом хранилище. А мержить один и тот же код всегда проблема.
Более того, реально работать с децентрализованном хранилище можно только, если ветки кода слабо связаны, как например в ядре. Там один драйвер зачастую отделен от другого.
В принципе, и сейчас в svn можно смешивать код из разный веток, но я не в курсе, чтобы можно было из разных хранилищ, может это имеется в виду.
| | |
| |
| 5.16, Nick (??), 23:45, 04/05/2008 [^] [^^] [^^^] [ответить] | +/– | ну а я что написал Мсье на читает написанное Или простыня - это просто много ... большой текст свёрнут, показать | | |
|
| |
| 5.18, Nick (??), 10:31, 05/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
вобщем "большое" и "малекое" - не технический спор.
И вообще, у каждого свое мнение.
Польза/вред децентрализованных репозиториев от этого не изменяется.
Но сама факт сабжа говорит об их правильности. Иначе SVN и не дергался бы.
| | |
|
|
|
|
| 1.5, Geol (?), 09:57, 04/05/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну вообщето Коллинз-Сассман не говорил об уходе от централизованной модели. А вот как задумана частичная децентрализация, я не совсем понял. Опять же, реплика Дмитрий Ю. Карпова педставляется довольно разумной, что подозрительно - данный персонаж обычно какую-нибудь теоретизированную пургу несёт...
Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и применения децентрализованых систем контроля версий?
| | |
| |
| 2.7, Andrew Kolchoogin (?), 10:05, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и
> применения децентрализованых систем контроля версий?
Разработка Linux Kernel?
| | |
| 2.10, Nick (??), 13:56, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Ну вообщето Коллинз-Сассман не говорил об уходе от централизованной модели. А вот
>как задумана частичная децентрализация, я не совсем понял. Опять же, реплика
>Дмитрий Ю. Карпова педставляется довольно разумной, что подозрительно - данный персонаж
>обычно какую-нибудь теоретизированную пургу несёт...
Вряд ли подозрительно :)
В данном треде его мнение не такое уж бесспорное.
>Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и
>применения децентрализованых систем контроля версий?
Да, Андрей правильно вот говорит.
Кроме Линуха сво больше проектов на sf.net используют git.
Как то ceph, nilfs...
Я вот Гентушник и заметил тенденцию (всего-ли за последние полгода, ну или 3/4) перехода
оверлеев с SVN на Git.
| | |
| |
| 3.12, Аноним (-), 14:59, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и
>>применения децентрализованых систем контроля версий?
>
>Да, Андрей правильно вот говорит.
>Кроме Линуха сво больше проектов на sf.net используют git.
>Как то ceph, nilfs...
Еще mozilla, Xorg...
В моей конторе Linux отдел естественно тоже :)
>Я вот Гентушник и заметил тенденцию (всего-ли за последние полгода, ну или
>3/4) перехода
>оверлеев с SVN на Git.
:) вот еесли б "emerge --sync" через git pull работал было б вообще зашибись :)
(Еще один "Я вот Гентушник")
| | |
| |
| 4.14, Nick (??), 15:10, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Еще mozilla, Xorg...
да, распределенные.
Но Мозиловцы на Меркурии обитают.
>:) вот еесли б "emerge --sync" через git pull работал было б
>вообще зашибись :)
не совсем ;)
rsync здесь как раз по месту. История всия портов среднему гентушнику ни к чему.
А git - это именно постоянное увеличение репозитория... Не очень гут... совсем не гут в общем случае.
А разработчики, ессьно, порты в репозитории держат.
>(Еще один "Я вот Гентушник")
:)
| | |
|
|
| 2.13, Аноним (13), 15:09, 04/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>А вот как задумана частичная децентрализация, я не совсем понял.
Локальные коммиты. То есть в случае оффлайновости, создается временная ветка local, куда и коммитится. При онлайне, локальная метка вмердживается в основную.
>Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и применения децентрализованых систем контроля версий?
Почитать можно в списке проектов, использующих соответствующие системы контроля версий: bzr, git, mercurial... Особенно разные svn vs bzr и прочие.
| | |
|
|
