为什么 git 子模块与 svn externals 不兼容? [英] Why are git submodules incompatible with svn externals?

问题描述

有很多网页建议 使 svn 外部看起来像 git 子模块的黑客方法.我已经阅读了一些帐户的区别，但这似乎不是很基本:

<块引用>

Git 子模块链接到另一个项目存储库中的特定提交，而 svn:externals 始终获取最新版本.

为什么这种差异使它们从根本上不兼容?难道没有我们可以假设的合理默认值，例如大多数 svn:externals 指向从不移动的标签?

解决方案

根本区别在于组合规则.

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

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

<小时>

git1.8.2 的注意事项

<块引用>

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

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

<小时>

(1.8.2 之前)每个模块只能有一个标签/SHA1.从一个共同的父存储库，你不能在一个模块中定义一个模块.
(但是一个模块，它只是对外部 Git 存储库的引用，可以有自己的子模块定义:父存储库将只引用一级子模块，而一级子模块又将引用它在自身内部提交的任何子模块)<小时>

在 SVN 外部:您可以定义目录外部和文件外部，无论是否有明确的修订.
您可以组合各种外部属性.例如:

$ svn propget svn:externals calc第三方/声音 http://svn.example.com/repos/sounds第三方/皮肤 -r148 http://svn.example.com/skinproj第三方/皮肤/工具包-r21 http://svn.example.com/skin-maker

结果不是配置('calc' 的一个参考)，而是选择规则的组合，这些规则定义了目录 'calc'

<小时>

简而言之，您不能为calc"子模块计算"一个 SHA1，这与 ' 上的一堆 svn:external 属性完全等效calc' SVN 目录.

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 子模块与 svn externals 不兼容?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！