为什么git submodules与svn externals不兼容？ [英] Why are git submodules incompatible with svn externals?
问题描述
有很多网页提示 havish让svn外部看起来像git submodules 。我已经阅读了一些账号，但它看起来并不是非常基本的：
Git子模块链接到另一个项目存储库中的特定提交，而svn：externals始终提取最新的修订。
为什么这种差异使它们从根本上不兼容？没有我们可以假设的合理的默认值，例如大多数svn ：外部指向永远不会移动的标签？
基本的区别在于组合规则。
在真正的基于组件的方法中，您可以定义一个 配置 ，即：
标签列表（SHA1提交Git）你需要你的项目工作（即开发，编译，部署，...）。
配置中引用的每个提交可帮助您获取所有树的确切版本。没有例外。该树的每个文件都是由您定义的配置指定的确切版本。
注意git1.8.2
git submodule开始学习一种新的模式，以便与远程分支的提示集成（而不是整合超级项目的gitlink中记录的提交）。
所以很快（2013年3月），子模块可以引用上游HEAD，而不仅仅是一个固定的SHA1。
（在1.8.2之前）每个模块只能有一个标签/ SHA1。从一个普通的父级回购，你不能在一个模块中定义一个模块。
（但是一个模块，只是一个外部的Git回购的引用，可以有自己的子模块定义：父级回购只会
没有这样的 外部SVN ：你可以定义目录外部以及外部文件，有或没有显式修订。
您可以撰写各种外部属性。例如：
$ svn propget svn：外部计算
第三方/声音http：//svn.example .com / repos /听起来
第三方/皮肤-r148 http://svn.example.com/skinproj
第三方/皮肤/工具包-r21 http://svn.example.com /皮肤制造商
结果不是配置（ calc '），但是一个选择规则组合可以在目录' calc '中定义所需的精确拼凑。
总之，您不能为一个' calc '子模块计算一个SHA1这与' calc ''SVN目录中一堆 svn：external 属性的确切等价。
There are lots of webpages out there suggesting hackish ways to make svn externals look like git submodules. I have read some accounts of what the difference is, but this doesn't seem very fundamental:
Git submodules link to a particular commit in another project's repository, while svn:externals always fetch the latest revision.
Why does this difference make them so fundamentally incompatible? Isn't there a reasonable default we can assume, such as that most svn:externals point to tags that never move?
The fundamental difference is the composition rule.
In a true component-based approach, you define a configuration, that is:
The list of labels (of SHA1 commits for Git) you need for your project to "work" (i.e. "develop", "compile", "deploy", ...).
Each commit referenced in a configuration helps you to get the exact versions of all trees. There is no exception. Each file of that tree is at the exact version specified by the configuration you have defined.
Note for git1.8.2
"git submodule" started learning a new mode to integrate with the tip of the remote branch (as opposed to integrating with the commit recorded in the superproject's gitlink).
So soon (March 2013), a submodule could reference an upstream HEAD, and not just a fixed SHA1.
(Before 1.8.2) There can be only one label/SHA1 per module. From one common parent repo, you cannot define a module within a module.
(But a module, which is just a reference to an external Git repo, can have its own submodules definition: the parent repo will only refer the first-level submodule, which in turn will reference whatever submodules it had committed within itself)
No so in SVN external: you can define directory externals as well as file external, with or without an explicit revision in it.
You can compose various external properties. For instance:
$ 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
The result is not a configuration (one reference for 'calc'), but a composition of selection rules which define the exact "patchwork" you need in the directory 'calc'
In short, you cannot "compute" one SHA1 for a 'calc' submodule which would be the exact equivalent of a bunch of svn:external properties on a 'calc' SVN directory.
这篇关于为什么git submodules与svn externals不兼容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
