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

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

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

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

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

Программное обеспечение, которое мы разрабатываем, мы называем конфигуратором, который можно настраивать бесконечно для разных потребностей клиентов. В целом мы, вероятно, имеем 50 различных версий. Однако у них есть одна общая черта. Все они имеют пару обязательных модулей (обязательный_модуль1..). Эти папки в основном содержат код ядра/ядра и общие языковые ресурсы и т.д. Все настройки могут быть любой комбинацией между другими модулями (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% к моей ситуации.

ОТВЕТЫ

Ответ 1

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

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

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

  • Git в порядке, но из сам вход Linus, чтобы помещать все в один репозиторий, может быть проблематично.

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

В настоящее время также ведется работа по добавлению отчета субрепозитория непосредственно в ядро ​​Mercurial, согласно проекту на странице