用于大型模块化代码库的SCM

时间:2013-03-26 12:34:49

标签: git svn version-control mercurial git-submodules

我需要一些帮助来为我的代码库设计SCM。代码库相当复杂,首先,我将尝试描述它。

代码库由许多不同产品的代码组成,简单来说就是Product1Product2(实际上还有更多)。每个Product都有多个与之关联的软件Projects,例如Core Application和支持软件,例如iOSAndroid个应用(这取决于产品到产品)。每个Project都需要使用与Product相同的代码(即CoreiOSAndroid应用都需要共享一些公共代码)。此外,Products需要彼此分享内部图书馆。

实际上,你最终会得到这样的结构:

Library1
Library2
Product1
├── Common
├── Core Application
├── iOS
└── Android
Product2
├── Common
├── Core Application
├── iOS
└── Android

绝对需要以下功能:

  1. 能够检查项目的最小代码集 - 例如,如果我想构建Product1's Android应用程序,我只想查看Library1,{{1 },Library2Product1/Common。代码库是如此庞大,检查一切将花费大量时间
  2. 将共享库,公共代码和项目代码的状态恢复为特定版本 - 例如,我需要构建{2}之前的Product1/Android Product2's来测试错误,我需要Core ApplicationLibrary1Library2Product2/Common全部恢复为同一版本
  3. 将文件移动到不同的共享文件夹,同时保留历史记录 - 无法在开始时将Product2/Core Application的所有正确代码放入Product文件夹。随着时间的推移和新产品的要求不断变化,这意味着曾经生活在Common的代码需要转移到Product2/Core Application,甚至可能转移到Product2/Common
  4. 目前,我们使用的系统是一个巨大的SVN存储库,它包含所有Library2ProductsProjects。 SVN中可以选择性代码签出,因此我们可以选择仅签出特定文件夹。因为它只是一个存储库,所以一切都很好地恢复到相同的版本。当我们分支或标记时,我们分支/标记整个存储库!

    我想要的是正确地模块化代码库,例如,Libraries存在于自己的存储库中,并且仅包含在其他存储库中。 Library1无法实现这一点,因为它违反了要求2.

    我想使用某种形式的DVCS,原因如下:

    1. 性能 - 提交大变更集时SVN速度很慢
    2. Braching / Merging - 尝试合并大型SVN分支机构是一场噩梦,我们不惜一切代价避免它。我知道用DVCS这么容易。
    3. 对模块的正确支持。我知道Git有子模块,Mercurial有subrepos,这似乎符合我的设计目标,但似乎你必须在更改修订时手动更新子目录。我希望它能在一个简单的步骤中完成。
    4. 更清晰的存储库结构。使用subrepos,每个项目都将是自己的reposisotry,具有清晰的结构和清晰的依赖关系
    5. 有什么想法吗?

1 个答案:

答案 0 :(得分:1)

最近Mercurial发生了一些变化,旨在使subrepos更容易和更有效地使用。我没有密切关注它们 - 您可能希望查看最近的hg-crew提交历史记录,看看是否有任何可能影响您决定的内容。

我已广泛使用Git和Mercurial,但绝对对Mercurial有更深入的了解,而且更喜欢使用它。我已将项目从ClearCase,SVN和Git迁移到Mercurial,在所有情况下,转换都非常顺利 - 重要的是让几个人可以为您的团队设置工作流程并设置代表性的测试回购和先试试吧。

hg convert extension可以将存储库从各种源转换为Mercurial存储库,并且可以使用filemap仅转换部分repo,重命名文件/目录等。我确信在Git上有类似的东西但是我从来不需要使用它。