几周前，我在 git上观看了 YouTube 演示技术讲座：Linus Torvalds ，其中一句话似乎一直萦绕在我的脑海中。
在这个演示文稿中（大约 33 分钟），Linus 说了类似“有些人克隆一个 SVN 存储库，进行合并（=在 SVN 中的头痛），然后将结果推送回 SVN。”。
我的想法是：如果这是可能的，那我们为什么不将GIT的强大合并能力移植到SVN中呢？
这样，我们对 SVN 有了很大的增强，并且我们不必迁移我们的公司存储库和相关脚本，这些脚本与各种问题跟踪和持续集成系统挂钩。
我肯定错过了什么。它是什么？
SVN 和 GIT 之间还有一个很大的区别，除了一个是集中式的，另一个不是。GIT 跟踪内容，SVN 跟踪文件。
如果您在 SVN 中合并分支，SVN 会计算您在分支中所做的更改并将这些更改应用于主干（或任何您的合并目标）。然后通过正常提交将这些修改传输到存储库，并且忘记源信息（分支中的历史记录）。在后来的 SVN 版本 (>=1.5) 中，合并行为得到了改进，SVN 现在可以记住分支的哪些修订已合并，哪些未合并，但基本问题仍然存在。
OTOH GIT 会在其日志中愉快地告诉您，您的某些代码行来自分支 xyz，并且它们在分支的修订版 a、b 和 c 中被修改。这使得做疯狂的合并事情变得非常容易，比如创建一个分支，处理它，更新到主线，做更多的工作，合并到主线，分支分支等等，没有任何问题。
更新：
底线：SVN 和 GIT 只是在跟踪修改的方式上有所不同，SVN 合并可能会变得像在 GIT 中一样酷而不会成为 GIT。
请注意，提到的关于 Git 的 Google Talk（顺便说一句，您可以在 Git Wiki 上阅读成绩单：LinusTalk200705Transcript）发生在 Subversion 1.5 之前。那时 Subversion 根本没有存储类似 Git 的智能合并合并跟踪信息所需的信息（除非您使用svnmerge扩展程序或 SVK，它是在 Subversion 之上（半）分布式 SCM）。
您是否知道自 1.5 以来 Subversion中改进的合并功能？它比以前丰富得多。自从迁移到 1.5 以来，我没有遇到合并问题。我很想看看 GIT 有哪些 Subversion 版本缺少的特性。
Git 和 SVN 是解决同一问题的两种完全不同的方式，一种是分布式的，一种是集中式的，因此您不能将 GIT 代码插入 SVN。这就像尝试将 JQuery 与旧版 VB6 应用程序集成一样。
自 2009 年以来，至少有一项“修复” svn merge 的举措：
请参阅“是时候修复 Subversion 合并”，2011 年 7 月（尽管大多数评论都敦促使用 Git；））
并查看项目页面“ Subversion NewMerge 合并修复”，其中涉及更改合并的跟踪方式。
但是，这个项目似乎还没有发布任何版本。