我有一个cvs存储库，主要是java代码。每个包都位于它自己的顶级目录中，就像这样，源代码以典型的java方式布局。
$CVSROOT/my.domain.module1/src/my/domain/module1 $CVSROOT/my.domain.module2/src/my.domain/module2 $CVSROOT/my.domain.share1/src/my/domain/share1
这意味着我们可以编写构建脚本，可以轻松地将任何软件包组合从存储库中拉出来，以构建特定的可发送软件。
因此，如果我检查了my.domain.module1，那么该模块中的构建脚本也会引入my.domain.share1。这确实促进了代码重用。
这种方法有优点和缺点 - 今天对此并不感兴趣 - 只是考虑到这种方法，在mercurial或git中复制是可能的/合理的。
据我所知，你需要为每个包定义一个完整的存储库，或者每次都签出并提交整个存储库！
答案 0 :(得分：2)
关于DVCS，一般来说，每个组件的回购是正确的大小。由于他们拥有各自组件的所有历史记录，因此只有一个回购用于任何组件，因此无法很好地扩展。
Git将使用 submodules ，Mercurial Hg将使用 subrepos 。
这个想法是定义一个超级项目（一个独立的回购），它将：
如果直接在其中一个子组件中对主项目进行一些修改，则必须首先提交这些子项目，然后在主项目中提交该主项目（它不包含所有数据，只有它自己的数据，以及一些指向你之前提交的新子模块引用的指针）
答案 1 :(得分：2)
听起来您使用ivy设置了精彩设置。它允许构建系统处理依赖项的下拉和编译部分，源代码控制只跟踪模块的时间点。
然后在您的常春藤依赖文件中，您可以清楚地记录其他人所依赖的每个组件的版本，并且可以轻松地恢复/推进。
您也可以使用mercurial子回购，但我更喜欢使用像常春藤这样的优秀依赖管理器。