Я в процессе переноса нашей старой кодовой базы C / C ++ в Mercurial.Мне немного неясно, как должна выглядеть структура хранилища оптимально (или, по крайней мере, почти оптимально), поскольку примеры, которые я нашел, относятся к .NET или Java.Моя проблема в основном связана с Каталогами VC ++ , которые мы много использовали с тех пор, как до меня.
currently, on disk:
\DEV
\include
\source
\lib
\static-link1.lib
\static-link2.lib
\static-link3.lib
...
\projects
\projA
\projB
\projC
...
\lib1-src
\lib2-src
\lib3-src
...
Вот как я мог бы увидеть, что мы сделали бы это безмного размышляю, но я могу предвидеть некоторые проблемы с версиями / зависимостями, возникающие во время линковки (ссылки на старый .lib).\source, \include и \static-libs в этом примере будут старыми глобальными VC ++ Каталогами при извлечении.
mercurial (alternative #1):
\repo: include
\repo: source
\repo: lib1-src
\repo: lib2-src
\repo: lib3-src
...
\repo: static-libs
\static-link1.lib
\static-link2.lib
\static-link3.lib
...
\repo: projA-prod
\repo: projA-dev
\repo: projB-prod
\repo: projB-dev
\repo: projC-prod
\repo: projC-dev
...
На альтернативу # 2.Будет ли это лучше?Могу ли я зайти в подпункт и выполнить извлечение / обновление / слияние только подпункта, если единственное, что я хотел бы сделать, - это создать новую производственную сборку определенного проекта с помощью только новой версии библиотеки?Эта альтернатива практически удаляет глобальный каталог \lib и вместо этого делает его для каждого проекта, что, как мы надеемся, делает его немного более гибким.С другой стороны, было бы неправильно проверять скомпилированные библиотеки.
mercurial (alternative #2):
\repo: include
\repo: source
\repo: static-libs (only for subrepos)
\repo: projA-prod
\subrepo: static-libs
\repo: projA-dev
\subrepo: static-libs
\repo: projB-prod
\subrepo: static-libs
\repo: projB-dev
\subrepo: static-libs
\repo: projC-prod
\subrepo: static-libs
\repo: projC-dev
\subrepo: static-libs
...
\repo: lib1-src
\repo: lib2-src
\repo: lib3-src
...
Есть еще идеи?Как ты делаешь это?Проработав в основном с .NET последние 4 года, я больше не люблю эти глобальные папки \source / \include, но я не понимаю, как мы можем полностью от них избавиться.Определенно должна быть возможность немного сократить исходный код или переместить некоторый код в библиотеки, таким образом сводя к минимуму межпроектные зависимости в этих файлах .h / .cpp, но некоторое простое повторное использование кода все равно будет существовать.
Дополнительный вопрос: я мог бы видеть \include и \source даже в одном и том же хранилище, так как они в значительной степени предназначены для блокировки, это как вы это делаете?