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

发布于 2024-09-07 06:45:10 字数 442 浏览 9 评论 0原文

有很多网页建议 黑客方法让 svn 外部看起来像 git 子模块。我已经阅读了一些帐户了解差异是什么,但这似乎不是很根本:

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

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

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

心房的律动 2024-09-14 06:45:11

根本区别在于组合规则

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

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


git1.8.2 的注意事项

“git 子模块”开始学习一种新模式来与远程分支的尖端集成(而不是与超级项目的 gitlink 中记录的提交集成)。

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


(1.8.2 之前)每个模块只能有一个标签/SHA1。在一个公共父存储库中,您无法在模块内定义模块。
(但是一个模块,只是对外部 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

结果不是一个配置(“calc”的一个引用),而是一组选择规则的组合,这些规则定义了目录“calc”中所需的确切“拼凑” code>'


简而言之,您无法为 'calc' 子模块“计算”一个 SHA1,这与 ' calc' SVN 目录。

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.

秋叶绚丽 2024-09-14 06:45:11

如果您使用 SmartGit 与 svn:externalls 一起使用 SVN 存储库,您不会注意到任何真正的差异。

实际上,唯一真正的区别(至少是唯一的技术区别)是 SVN 允许外部指向 HEAD 修订版(不是固定值),而 Git 子模块则不允许。在我看来,所有其他差异都是微不足道的,所以你问这个问题是对的。

If you use SmartGit for working with SVN repository with svn:externalls, you won't notice any real difference.

Actually, the only real difference (at least the only technical difference) is that SVN allows external to point to HEAD revision (not fixed value), Git submodule doesn't. All the other differences are, to my opinion, insignificant, so you're right asking this question.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文