AFAICS большая часть сопротивления любому из DVCSs приходит от людей, не понимающих, как их использовать. Часто повторяемое утверждение о том, что «центрального хранилища не существует», очень пугает людей, которые были заперты в модели CVS / SVN с незапамятных времен и не могут представить ничего другого, особенно для руководства и старших (опытных и / или циничные) разработчики, которым требуется надежное отслеживание и воспроизводимость исходного кода (и, возможно, также, если вы должны удовлетворять определенным стандартам в отношении ваших процессов разработки, как мы делали в месте, где я когда-то работал). Ну, вы можете иметь центральное "благословенное репо" Вы просто не закованы в это. Например, подгруппе легко на некоторое время настроить внутреннее репо на одной из своих рабочих станций.
Существует так много способов снять шкуру с пресловутой кошкой, что вам придется сесть и тщательно обдумать свой рабочий процесс. Подумайте о своих нынешних практиках и о том, что дает вам почти бесплатное клонирование и ветвление. Вероятно, что то, что вы делаете в настоящее время, будет развиваться, чтобы обойти ограничения модели типа CVS; будьте готовы сломать плесень. Вам, вероятно, нужно будет назначить одного или двух чемпионов, чтобы облегчить всем переход; с большой командой вы, вероятно, захотите подумать об ограничении доступа коммитов к blessed .
На моей работе (небольшой дом программного обеспечения) мы перешли с CVS на hg и больше не вернулись. Мы используем его в основном централизованно. Преобразование нашего основного (древнего и очень большого) репо было болезненным, но это будет любым способом, которым вы идете, и когда это будет сделано, это будет сделано - будет намного легче изменить VCS позже. (Мы обнаружили ряд ситуаций, когда инструменты преобразования CVS просто не могут понять, что произошло; когда чьи-то коммиты выполнялись лишь частично, а они не замечали в течение нескольких дней; разрешали ветки продавцов; общее безумие и безумие, вызванное появлением времени в обратном направлении, не помогает фиксация временных отметок по местному времени из разных часовых поясов ...)
Большое преимущество, которое я получил от DVCS, - это возможность делать ранние и частые коммиты, только когда они готовы. Когда я достигаю различных этапов работы, мне нравится проложить линию на песке, чтобы у меня было где-то, к чему я могу вернуться, если это будет необходимо - но это не коммиты, которые должны быть представлены команде, поскольку они явно неполны бесчисленными способами. (Я делаю это в основном с ртутными очередями.) Все дело в рабочем процессе; Я никогда не смог бы сделать это с помощью CVS.
Полагаю, вы уже знаете это, но если вы планируете отойти от CVS, вы можете сделать это намного лучше, чем SVN ...
Для монолита или для модуля? Любая смена парадигмы будет непростой, независимо от того, с какой VCS вы работаете, с распределением или без; Модель CVS довольно специфична тем, что она позволяет вам фиксировать файл за файлом, не проверяя актуальность остальной части репо (и не будем упоминать головную боль, которую, как известно, вызывали псевдонимы модуля).
- Работа с монолитными хранилищами может быть довольно медленной. Ваш vcs-клиент должен сканировать вашу копию всей вселенной на предмет изменений, а не только одного модуля. (Если вы работаете в Linux, посмотрите на расширение hg inotify, если вы еще этого не сделали.)
- Монолитное РЕПО также вызывает ненужные условия гонки при фиксации (толкании). Это похоже на актуальную проверку CVS, но применяется ко всему репо: если у вас много активных разработчиков, часто совершающих коммиты, этот укусит вас.
Я бы предположил, что стоит того, чтобы держаться подальше от монолитного, но имейте в виду, что это потребует дополнительных затрат в плане дополнительной сложности в вашей системе сборки. (Примечание: если вы находите что-то утомительное, автоматизируйте это! Мы, программисты, в конце концов, ленивые существа.) Разделение репо на все составляющие его модули может быть слишком экстремальным; может быть на полпути можно найти связанные компоненты, сгруппированные между небольшим количеством хранилищ. Также вам может пригодиться поддержка субмодулей mercurial - Вложенные репозитории и Расширение леса (оба из которых я должен попытаться обдумать).
На прежнем рабочем месте у нас было несколько десятков компонентов, которые хранились как независимые модули CVS с довольно регламентированной метаструктурой. Компоненты объявляли, от чего они зависели, и от каких частей сборки они должны были быть экспортированы; система сборки автоматически пишет make фрагменты, чтобы то, над чем вы работали, получало то, что ему нужно. Как правило, это работало очень хорошо, и было довольно редко проваливать актуальную проверку CVS. (Был также чертовски сложный, но чрезвычайно мощный сборочный бот с минимальным отношением к разрешению зависимостей: он не перестроил бы компонент, если бы уже был тот, который отвечал вашим требованиям. Добавьте к этим метакомпонентам, которые собрали установщики и все ISO-образы, и у вас есть хороший рецепт для простых начальных и завершенных сборок и для всего, что происходит. Ученик Sorcerers. Кто-то должен написать об этом книгу ...)