将GIT合并功能移植到SVN？

Question

几周前我观看了YouTube演示文稿Tech Talk: Linus Torvalds on git，似乎有一句话在我脑海中浮现。

在这个演讲中（大约33分钟），Linus说了一句“有些人克隆SVN存储库，合并（= SVN头痛）然后将结果推回SVN。”。

我的想法是：如果这是可能的，那么为什么我们不把GIT的强大合并能力移植到SVN的一个组成部分？

通过这种方式，我们对SVN进行了很大的改进，我们不必迁移我们的公司存储库和相关脚本，这些脚本可以连接到各种问题跟踪和持续集成系统。

我一定错过了什么。它是什么？

Answer 1

SVN和GIT之间存在另一个很大的区别，除了一个集中化而另一个不集中。 GIT跟踪内容，SVN跟踪文件。

如果您在SVN中合并分支，SVN会计算您在分支中所做的更改并将这些更改应用于主干（或者您的合并目标）。然后通过正常提交将这些修改转移到存储库，并且忘记源信息（分支中的历史）。在后来的SVN版本（＆gt; = 1.5）中，合并行为得到了改善，SVN现在记住了哪个分支的修订被合并，哪些不合并，但基本问题仍然存在。

OTOH GIT将在其日志中高兴地告诉您，您的代码的某些行来自分支xyz，并且它们在分支的修订版a，b和c中被修改。这使得它可以非常容易地进行疯狂的合并，例如创建分支，处理它，更新到主线，做更多工作，合并到主线，分支分支等等，没有任何问题。

更新：

结论：SVN和GIT跟踪修改的方式不同，SVN合并可能会变得像GIT一样酷，而不会成为GIT。

Answer 2

注意提到谷歌谈论Git（BTW你可以阅读Git Wiki上的成绩单：LinusTalk200705Transcript）发生在Subversion 1.5之前。那时Subversion只是没有存储所需的智能Git合并合并跟踪信息（除非你使用svnmerge扩展，或SVK是（半） ）在Subversion之上分发SCM）。

Answer 3

你知道自1.5以来Subversion中的improved merging capabilities吗？它比以前更丰富。自从转向1.5以来，我没有遇到合并问题。我有兴趣看看GIT在后续版本的Subversion中缺少什么功能。

Answer 4

Git和SVN是解决同一问题的两种完全不同的方式，一种是分布式集中式，因此您不能将GIT代码插入SVN。这就像尝试将JQuery与传统的VB6应用程序集成一样。

Answer 5

自2009年以来，至少有一项“修复”svn合并的举措：

请参阅2011年7月的“It's Time to Fix Subversion Merge”（尽管大多数评论都要求与Git一起使用;）） 并查看项目页面“Subversion NewMerge merge fix”，其中涉及更改how merge is tracked 但是，这个项目似乎还没有产生任何版本。