为什么git子模块与svn externals不兼容?

And*_*ack 13 svn git git-svn svn-externals git-submodules

有很多网页在那里暗示让svn外部看起来像git子模块的hackish方法.我已经读过一些关于差异的说法,但这似乎不是很基础:

Git子模块链接到另一个项目的存储库中的特定提交,而svn:externals总是获取最新的修订.

为什么这种差异会使它们根本不相容?我们可以假设没有合理的默认值,例如大多数svn:externals指向永不移动的标签吗?

Von*_*onC 10

根本区别在于构图规则.

在真正的基于组件的方法中,您定义了一个配置,即:
项目"工作"所需的标签列表(对于Git的SHA1提交)(即"开发","编译","部署", ...).

配置中引用的每个提交都可以帮助您获取所有树的确切版本.没有例外.该树的每个文件都是您定义的配置指定的确切版本.


git1.8.2的注释

"git submodule"开始学习一种与远程分支的尖端集成的新模式(而不是与超级项目的gitlink中记录的提交集成).

很快(2013年3月),子模块可以引用上游HEAD,而不仅仅是固定的SHA1.


(1.8.2之前)每个模块只能有一个标签/ SHA1.从一个公共父repo,您​​无法在模块中定义模块.
(但是一个模块,它只是对外部Git仓库的引用,可以有自己的子模块定义:父仓库只会引用第一级子模块,而子模块又引用它自己提交的子模块)


SVN外部不是这样:您可以定义目录外部以及外部文件,其中包含或不包含显式修订.
您可以撰写各种外部属性.例如:

$ svn propget svn:externals calc
third-party/sounds             http://svn.example.com/repos/sounds
third-party/skins -r148        http://svn.example.com/skinproj
third-party/skins/toolkit -r21 http://svn.example.com/skin-maker
Run Code Online (Sandbox Code Playgroud)

结果不是配置(' calc'的一个引用),而是一个选择规则的组合,它定义了目录' calc'中所需的确切"拼凑" .


简而言之,您无法为一个' calc'子模块"计算"一个SHA1,这个子模块将完全等同svn:external于' calc'SVN目录中的一堆属性.

  • 这仍然令人非常不满意.我知道他们是不同的,但我不明白为什么不能有一些自动解决方法. (7认同)