Используют ли какие-либо компании по производству оборудования (ASIC) Mercurial (hg)?

Знаете ли вы о каких-либо крупных компаниях (желательно аппаратных), успешно использующих Mercurial в качестве своей системы контроля версий (vcs.)

У меня есть опыт работы с svn / cvs / perforce и небольшим git. Внутренняя политика подталкивает нас к резюме, хотя я считаю, что это плохой выбор:

Причины, по которым мне нравится больше всего:

  1. Боевые испытания в ч / б роте.
  2. хорошо обрабатывает большие двоичные файлы.
  3. очень хорошо справляется с большими проектами> 10G.
  4. очень разумно обрабатывает символические ссылки.
  5. предоставляет атомарные проверки.
  6. гибкий механизм разветвления.
  7. инструменты слияния работают хорошо.
  8. пользователю никогда не нужно использовать команды администратора.

Причины, по которым мне не нравится CVS:

  1. не поддерживает атомарные проверки.
  2. база данных может быть искажена.
  3. может потребоваться команда администратора для исправления ошибки пользователя.

Причины, по которым мне нравится CVS:

  1. Боевые испытания.
  2. большинство людей хотя бы немного с ним знакомо.

person user929821    schedule 22.06.2012    source источник


Ответы (1)


Ты прав. CVS - плохой выбор. Отсутствие атомной проверки достаточно, чтобы дисквалифицировать его в моей книге. Людям это нравится, потому что они знают это и не понимают, что с этим не так.

Единственная разница между использованием системы для фирм, производящих оборудование, и программных фирм, как правило, заключается в том, что модули RTL имеют очень четко определенные интерфейсы и обычно принадлежат одному человеку, поэтому разработка очень сегментирована. На самом деле это довольно хорошо работает с централизованной системой, поскольку уменьшается потребность в ветвлении. Разработчики не так сильно наступают друг другу на пятки.

Я видел, как одна фирма по производству оборудования пробовала Mercurial, и это было беспорядочно. Дело не в том, что это был неправильный инструмент, а в том, что у них был образ мышления CVS и они пытались заставить его работать как CVS. Я написал довольно громкую учетную запись здесь.

Лично я считаю, что SVN очень хорошо подходит для разработки оборудования, особенно для людей, пришедших из CVS. Также может быть полезна его способность проверять поддеревья. Тем не менее, в настоящее время я работаю в месте, которое пытается создать рабочий поток «функциональной ветки» с SVN, и слияние имеет множество подводных камней. Они думают о git / hg в будущем. Однако это небольшая прогрессивная фирма.

Фирма, которая перешла с CVS на Mercurial, перешла к Perforce. Для них все было о контракте на поддержку и о том, что кого-то винить. Для пользователей ... ну ... я думаю, что это действительно сложная задача для пользователя. Вся концепция рабочего пространства - это просто излишество, а управление филиалами было головной болью. Как система, она способна, но требует много работы.

Если бы мне пришлось развернуть Mercurial в другой аппаратной компании, я бы интенсивно использовал суб-репозитории . Я бы сделал это, чтобы вернуть полезную часть извлечения поддерева из Subversion, т.е. чтобы модуль RTL можно было извлекать и разветвлять изолированно. Это также дало мне концепцию проекта интеграции, который был бы проектом, в который я бы включил все подмодули. Затем это до некоторой степени отделяет выпуски RTL от разработки RTL и упрощает использование одних и тех же модулей для разных микросхем. Кроме того, благодаря разделению модулей история также остается изолированной, что упрощает отслеживание изменений модулей. Наконец, он позволяет избежать проблемы «сотни разработчиков, обращающихся к одному центральному репо и участвующих в гонках слияний», которые я описал в своем другом ответе.

person Paul S    schedule 26.06.2012