Вы правы. CVS - плохой выбор. Недостаточно атомной проверки достаточно, чтобы дисквалифицировать ее в моей книге. Людям нравится, потому что они знают это, и они не понимают, что с ним не так.
Единственная разница между использованием системы для аппаратных фирм и фирм-разработчиков программного обеспечения имеет тенденцию быть RTL-модулями, которые имеют очень четко определенные интерфейсы и обычно принадлежат одному человеку, поэтому разработка очень сегментирована. Это действительно хорошо работает с централизованной системой, поскольку потребность в ветвлении уменьшается. Разработчики не наступают друг на друга.
Я видел, как одна аппаратная фирма попробовала Mercurial, и это был беспорядок. Дело не в том, что это был неправильный инструмент, но у них был образ мышления CVS и он пытался заставить его работать как CVS. Я написал довольно разборную учетную запись here.
Лично я считаю, что SVN вполне подходит для аппаратного обеспечения, особенно для людей, прибывающих из CVS. Это также может быть полезно для проверки поддеревьев. Тем не менее, я в настоящее время работаю в месте, которое пытается использовать «ветку функций» с SVN, и слияние имеет многочисленные подводные камни. Они думают о git/hg в будущем. Тем не менее, это небольшая, прогрессивная фирма.
Фирма, которая переехала из CVS в Mercurial, отправилась в Перфорс. Для них речь шла о контракте поддержки и о том, чтобы кто-то виноват. Для пользователей .... ну .... я думаю, что он представляет собой очень сложный фронт для пользователя.Вся концепция рабочего пространства просто переборщила, а управление филиалами было больно. Как система, она способна, но много работы для использования.
Если бы я должен был разместить Mercurial в другой фирме-аппарате, я бы интенсивно использовал sub-repositories. Я бы сделал это, чтобы вернуть полезную часть проверок поддерева из подрывной деятельности, то есть модуль RTL можно было бы проверить и разветвить изолированно. Это также даст мне концепцию интеграционного проекта, который был бы проектом, в который я бы потянул все подмодули. Это в некоторой степени отделяет RTL-релизы от разработки RTL и облегчает использование разных чипов с использованием тех же модулей. Кроме того, сохраняя отдельные модули, история также сохраняется изолированной, что облегчает отслеживание изменений на модулях. Наконец, это позволяет избежать «сотен разработчиков, получающих доступ к одному центральному репо и попаданию в проблемы слияния», о котором я рассказал в своем другом ответе.