1

我一起工作的团队决定从 svn 转向 git，我相信这是一件好事。我负责迁移并重新构建当前的 svn 布局。

我们目前在svn中的内容如下所示：

/externals  (external libs copyed there like cunit, etc.)
/include    (public headers only)
    /libA
    /libB
    /libC
/source     (source and private headers)
    /libA
    /libB
    /libC
/tests      (tests projects)
    /libA
    /libB
    /libC

在对 git 进行一些研究时，我发现模块化方法是首选。所以我想出了这个结构：

/externals      (repo externals.git)
/libA           (repo libA.git)
   /include
   /source
   /tests
/libB           (repo libB.git)
    ...

但是，我认为如果它们相互依赖（libB 需要 libA，libD 需要 libA 和 libC），我认为这种方式打破了模块化和拥有不同库的意义。您需要离开 libB 的范围才能将 libA 添加为依赖项。

那么我应该在每个库中添加一个“依赖项”文件夹并将它们作为子模块添加到那里，还是应该保留初始的 git 布局？

这里的首选方法是什么？

谢谢

4

1 回答 1

0

More reliable approach is to have independent project lifecycle for each module. Also, when you release a library, you should maintain version number. The dependency should tell which module and which version of library, e.g. libB:1.0.0 needs libA:1.2.5, libD:3.4.5 needs libA:1.3.7 and libC:5.3.9. There are dependency management systems, e.g. maven in java world, deb in linux distributives, nuget in c#. They allow to track exact versions and see conflicts in version numbers, e.g. if you have a myApp:6.2.5 which needs libB:1.0.0 and libD:3.4.5 it means that the myApp depends on two different (potentially incompatible) versions of libA - 1.2.5 and 1.3.7.

When you could have a Continious Integration server which will build changed modules and rebuild dependencies and run tests to hunt down compatibility issues very fast.

In other words, the version dependency management is not task for version control system such as git or svn, better to use special tools. However you could use the git submodules or svn-externals to handle it, but it doesn't work very well.

于 2013-04-03T14:44:11.230 回答