有很多网页建议hackish ways to make svn externals look like git submodules。我已经阅读了some accounts 的区别是什么，但这似乎不是很根本：
Git 子模块链接到另一个项目存储库中的特定提交，而 svn:externals 始终获取最新版本。
为什么这种差异使它们从根本上不兼容？难道没有我们可以假设的合理默认值，例如大多数 svn:externals 指向永远不会移动的标签吗？
【问题讨论】：
标签： svn git git-svn git-submodules svn-externals
根本区别在于作曲规则。
在真正的基于组件的方法中，您定义一个configuration，即：
您的项目“工作”（即“开发”、“编译”、“部署”...）所需的标签列表（Git 的 SHA1 提交）。
配置中引用的每个提交都可以帮助您获得所有树的确切版本。也不例外。该树的每个文件都是您定义的配置指定的确切版本。
git1.8.2 的注意事项
“git submodule”开始学习一种新的模式来与远程分支的尖端集成（而不是与超级项目的gitlink中记录的提交集成）。
很快（2013 年 3 月），子模块可以引用上游 HEAD，而不仅仅是固定的 SHA1。
（1.8.2 之前）每个模块只能有一个标签/SHA1。从一个共同的父仓库中，您不能在一个模块中定义一个模块。
（但是一个模块，它只是对外部 Git 仓库的引用，可以有自己的子模块定义：父仓库只会引用第一级子模块，而第一级子模块又会引用它在自己内部提交的任何子模块）
在 SVN external 中不是这样：您可以定义外部目录以及外部文件，无论是否有明确的修订。
您可以组合各种外部属性。例如：
$ 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
结果不是配置（“calc”的一个参考），而是选择规则的组合，这些规则定义了您在目录“calc”中所需的确切“拼凑”
简而言之，您不能为“calc”子模块“计算”一个 SHA1，这完全等同于“calc”SVN 目录上的一组 svn:external 属性。
【讨论】：
git svn clone 父级时，至少作为默认值，我是否足以散列该特定修订版？
git svn dcommit？您将如何推回您在 Git 存储库的“子模块”部分中可能进行的任何更改（请参阅“子模块的真实性质”stackoverflow.com/questions/1979167/git-submodule-update/…），这些更改实际上对应于几个 SVN 存储库，其中一些具有明确的修订而不是应该搬家？
如果您使用SmartGit 与 svn:externalls 一起使用 SVN 存储库，您不会注意到任何真正的区别。
实际上，唯一真正的区别（至少唯一的技术区别）是 SVN 允许 external 指向 HEAD 修订版（不是固定值），Git 子模块不允许。在我看来，所有其他差异都是微不足道的，所以你问这个问题是对的。
【讨论】：