Перенос устаревшей кодовой базы из cvs в распределенный репозиторий (например, git или mercurial). Предложения, необходимые для первоначального дизайна хранилища

Введение и история вопроса

Мы находимся в процессе изменения системы контроля версий, и в настоящее время мы оцениваем git и mercurial. Общая база кода составляет около 6 миллионов строк кода, поэтому она не массивна и не очень мала.

Позвольте мне сначала начать с очень краткого введения в то, как выглядит текущий дизайн хранилища.

У нас есть одна базовая папка для полной базы кода, и под этим уровнем находятся всевозможные модули, используемые в нескольких разных контекстах. Например, "dllproject1" и "dllproject2" можно рассматривать как совершенно отдельные проекты.

Программное обеспечение, которое мы разрабатываем, - это то, что мы называем конфигуратором, который можно бесконечно настраивать для различных потребностей клиентов. Всего у нас, вероятно, 50 разных версий. Однако у них есть одна общая черта. Все они имеют несколько обязательных модулей (required_module1 ..). Эти папки в основном содержат код ядра / ядра и общие языковые ресурсы и т. Д. Все настройки могут быть любой комбинацией между другими модулями (module1 ..).

Поскольку в настоящее время мы используем cvs, мы добавили псевдонимы в файл CVSROOT/modules. Они могут выглядеть примерно так:

core –a mandatory_module1 mandatory_module2 mandatory_module3
project_x –a module1 module3 module5 core

Поэтому, если кто-то решит поработать над project_x, он / она может быстро оформить модули, необходимые для:

base>cvs co project_x

Вопросы

Интуитивно просто кажется неправильным иметь базовую папку в качестве единого хранилища. Как программист, вы должны быть в состоянии проверить точное подмножество кода, необходимое для текущего проекта, с которым вы работаете. Что вы думаете об этом?

С другой стороны, правильнее иметь каждый из этих модулей в отдельных репозиториях. Но это усложняет программистам проверку модулей, которые им нужны. Вы должны быть в состоянии сделать это с помощью одной команды. Итак, мой вопрос: существуют ли похожие способы определения псевдонимов в git / mercurial?

Любые другие вопросы, предложения, указатели приветствуются!

PS. Я искал похожие вопросы, но не чувствовал, что кто-либо из них применил 100% к моей ситуации.

Источник

2 ответа

Решение

Просто быстрый комментарий, чтобы напомнить вам, что:

  • такие миграции часто дают возможность реорганизовать источники не по модулям (каждый с одним репозиторием), а по разделению функционального домена (несколько модулей для одного и того же функционального домена помещаются в один и тот же репозиторий).

Затем следует использовать субмодули как способ определения конфигурации.

[...] CVS, то есть он действительно в значительной степени ориентирован на модель "один файл за раз".

И это хорошо, потому что вы можете иметь миллион файлов, а затем проверить только несколько из них - вы даже никогда не увидите влияния других 999,995 файлов.

Git принципиально никогда не смотрит меньше, чем весь репо. Даже если вы немного ограничиваете вещи (то есть проверяете только часть или возвращаете историю немного назад), git в конечном итоге все равно всегда заботится обо всем и несет знания.

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

И да, тогда есть проблемы "большого файла". Я действительно не знаю, что делать с огромными файлами. Мы сосем их, я знаю.

Эти два вышеупомянутых пункта выступают за более компонентно-ориентированный подход для большой системы (и большого унаследованного хранилища).

С подмодулем Git вы можете оформить их в своем проекте (даже если это двухэтапный процесс). Однако у вас есть инструменты, которые могут упростить управление субмодулями (например, git.rake).

Когда я думаю об исправлении ошибки в модуле, который используется несколькими проектами, я просто исправляю ошибку и фиксирую ее, и все просто делают свои обновления

Это то, что я описываю в Post Vendor Branch как "системный подход": все работают над последним (HEAD) из всего, и это эффективно для небольшого числа проектов.
Хотя для большого количества модулей понятие "модуль" все еще очень полезно, но его управление отличается от DVCS:

  • для тесно связанных модулей (то есть "в одной и той же функциональной области", например, "все модули, связанные с PNL - прибыль и убытки - или" анализ риска "в финансовой области), вам необходимо работать с последними (HEAD) все компоненты участвуют.
    Это будет достигнуто с использованием стратегии поддерева, не для того, чтобы вы публиковали (подталкивали) исправления в этих других подмодулях, а для отслеживания работ, выполненных другими командами.
    Git позволяет это с дополнительным бонусом, что это "отслеживание" не обязательно должно происходить между вашим хранилищем и одним "центральным" хранилищем, но также может происходить между вами и локальным хранилищем другой команды, что позволяет очень быстро обратная интеграция и тестирование проектов аналогичного характера.

  • однако для модулей, которые не находятся непосредственно в вашем функциональном домене, подмодули являются лучшим вариантом, потому что они ссылаются на исправленную версию модуля (коммит):
    когда меняется низкоуровневая структура, вы не хотите, чтобы она распространялась мгновенно, так как это повлияло бы на все другие команды, которые затем должны были бы отказаться от того, что они делали, чтобы адаптировать свой код к этой новой версии (вы хотите, однако, все остальные команды должны знать об этой новой версии, чтобы они не забыли обновить этот компонент низкого уровня или "модуль").
    Это позволяет вам работать только с официальными стабильными идентифицированными версиями других модулей, а не с потенциально нестабильными или не полностью протестированными HEAD.

Источник

Что касается Mercurial, рекомендация также состоит в том, чтобы реорганизовать большие устаревшие хранилища CVS/SVN в более мелкие компоненты. Общий код должен быть помещен в его собственные библиотеки, и тогда код приложения будет зависеть от этих библиотек аналогично тому, как он зависит от других библиотек.

Mercurial имеет расширение леса, которое позволяет вам управлять "лесом" "исходных деревьев". При таком подходе вы объединяете несколько небольших хранилищ в одно большее. С CVS вы делаете наоборот: вы извлекаете меньшую часть большого хранилища.

Я лично не использовал расширение леса, и на его странице написано, что нужно использовать обновленную версию по сравнению с версией, входящей в комплект Mercurial. Тем не менее, он используется большой организацией, такой как Sun, в своем проекте OpenJDK.

В настоящее время также ведется работа по добавлению отчета о вложенном хранилище непосредственно в ядро ​​Mercurial в соответствии с дизайном на странице вложенных хранилищ в вики Mercurial.

Источник
Другие вопросы по тегам