与Git相比，SVN v 1.8如何分支/合并？ [英] How is SVN v 1.8 branching / merging compared to Git?

问题描述

我现在一直在使用Git，最近被问及为什么它的合并和分支功能比SVN更好。几年前，当我使用SVN时，我发现分支和合并非常麻烦并且容易出错。结果，我几乎没有分支。然而，就在上周我尝试了新的SVN 1.8版本，我发现它做的很好。

我其实尝试了一些复杂的分支内容，并没有发现有趣的错误。当然，这是非常缓慢的，但我主要关心的是功能，而不是速度（至少在试图说服某人时）。

所以我的问题是多少不同SVN v1.8和Git分支/合并功能。特别是，我也有兴趣知道是否有一些分支和合并操作（或工作流程）可以用Git完成，但不能用SVN完成（或者也许可以用SVN完成，但这很困难）。

谢谢。

解决方案

理解模型非常重要， Subversion合并引擎使用。它与Git完全不同。

Subversion支持两种基本类型的合并。第一个是同步合并，用于使开发（功能/任务/主题）分支与主干保持同步。第二个是用于将完成的工作提升到主干的重新合并合并。因此，该模型是支持功能分支和发布分支的主线（中继线）模型。

一个重要的限制是Subversion在搜索合并历史记录时找不到完整的DAG来查找正确的合并基础。直接相关的（父 - 子）分支之间的合并得到很好的支持，但是在远离祖先或兄弟姐妹的分支之间合并，并且间接从其他分支进入的分支通常会产生令人惊讶的结果。

随着时间的推移，Subversion合并支持正在改进。它一直没有合并跟踪，直到1.5，在1.8中有了巨大的飞跃，即将到来的1.9将会改进重命名/移动跟踪。未来还会谈到'本地货架'。

（顺便说一下，我知道其中的一些原因，因为我上周参加了Subversion / Git Live会议，提交者在合并引擎上进行了演示。）

另一方面，Git拥有备受推崇的合并引擎。它可以处理几乎任何复杂的合并。事实上，它唯一的主要合并限制是它在事实之后推断移动/重命名。在非常复杂的重构情况下，它可能无法正确拾取一切。总结：

• Subversion和Git在普通合并场景。


• Git将更有效地处理更复杂的合并方案，特别是在不具有直接父 - 子关系的分支之间进行合并时。


• 在重构过程中，这两个系统都有跟踪重命名/移动的问题，尽管在典型情况下Git可能做得更好。


• Git的合并命令在简单情况下更容易运行。如果您正在进行不寻常的操作，那么这两个系统的学习曲线都会非常陡峭。
Git支持相关操作，例如存储库之间的重新布局和合并，可以改善您的工作流程。

• 为了充分利用Subversion，请确保您拥有1.8+以上的服务器和客户端。

希望这有助于！

I have been using Git for a while now, and have been recently asked why its merging and branching capabilities are better than those of SVN. Years ago, when I used SVN, I found that branching and merging were quite cumbersome and error prone operations. As a result, I barely branched. However, just last week I tried the new SVN 1.8 version, and I found out that it was doing things quite nicely.

I actually tried some complicated branching stuff and I got no funny errors. Of course, it was tremendously slow, but my main concern is about functionality, not speed (at least when trying to convince someone).

So my question is how much different are SVN v1.8 and Git branching/merging capabilities. In particular, I would also be interested to know if there is some branching and merging operations (or workflow) that can be accomplished with Git but not with SVN (or maybe it can be accomplished with SVN but it is quite difficult).

Thanks.

解决方案

It's important to understand the model that the Subversion merge engine uses. It's very different from Git.

Subversion supports two basic types of merges. The first is a 'sync' merge that is done to keep a development (feature/task/topic) branch up to date with trunk. The second is a 'reintegrate' merge that is used to promote finished work to the trunk. So the model is a mainline (trunk) model that supports feature branches and release branches.

An important limitation is that Subversion does not consider the full DAG when searching merge history to find the right merge base. Merging between directly related (parent-child) branches is well supported, but merges done between branches that are distant ancestors or siblings, with contributions coming in indirectly from other branches, will often give surprising results.

Subversion merge support is improving over time as you noted. It had no merge tracking at all until 1.5, made huge leaps in 1.8, and the upcoming 1.9 will improve rename/move tracking. There's also talk of 'local shelves' in the future.

(By the way, I know some of this because I attended the Subversion/Git Live conference last week and the committer who works on the merge engine gave a presentation.)

Git on the other hand has a very well respected merge engine. It can handle merges of almost any complexity. In fact its only major merge limitation is that it deduces move/renames after the fact. In very complicated refactoring situations it may not pick up everything properly.

To summarize:

• Both Subversion and Git will work well in common merge scenarios.
• Git will handle more complicated merge scenarios more effectively, particularly when merging between branches that don't have a direct parent-child relationship.
• Both systems have problem with tracking renames/moves during refactoring, although Git probably does a better job in typical cases.
• Git's merge command are easier to run in simple cases. Both systems can have a steep learning curve if you're doing unusual operations.
• Git supports related operations like rebasing and merging between repositories that can improve your workflow in some cases.
• To get the best use out of Subversion, make sure you have 1.8+ server and clients.

Hope that helps!

这篇关于与Git相比，SVN v 1.8如何分支/合并？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！