1

我正在将我们的旧 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 对某个项目进行新的生产构建，我是否可以进入子存储库并仅对子存储库进行拉取/更新/合并？这种替代方案实际上删除了全局\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
...

还有其他想法吗？你怎么做呢？在过去的 4 年中主要使用 .NET 工作，我不再那么喜欢这些全局\source/\include文件夹，但我不明白我们如何才能完全摆脱它们。绝对应该可以稍微削减源代码或将一些代码移动到库中，从而最大限度地减少那些 .h/.cpp 文件中的项目间依赖关系，但仍然需要存在一些简单的代码重用。

附加问题：我可以看到\include甚至\source在 SAME 存储库中，因为它们几乎是同步的，你是这样做的吗？

4

0 回答 0