与 Git 相比，SVN v 1.8 分支/合并如何？

How is SVN v 1.8 branching / merging compared to Git?

提问by Knuckles the Echidna

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.

我已经使用 Git 有一段时间了，最​​近有人问我为什么它的合并和分支功能比 SVN 的更好。多年前，当我使用 SVN 时，我发现分支和合并是非常麻烦且容易出错的操作。结果，我几乎没有分支。然而，就在上周，我尝试了新的 SVN 1.8 版本，我发现它的性能非常好。

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).

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

Thanks.

谢谢。

回答by randy-wandisco

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

了解 Subversion 合并引擎使用的模型很重要。它与 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.

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

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 在搜索合并历史以找到正确的合并基础时不考虑完整的 DAG。直接相关（父子）分支之间的合并得到了很好的支持，但是在远亲或兄弟姐妹的分支之间进行合并，贡献来自其他分支的间接贡献，通常会产生令人惊讶的结果。

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.

正如您所指出的，Subversion 合并支持随着时间的推移不断改进。它在 1.5 之前根本没有合并跟踪，在 1.8 中取得了巨大的飞跃，即将到来的 1.9 将改进重命名/移动跟踪。未来也有人在谈论“本地货架”。

(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.)

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

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.

另一方面，Git 有一个非常受人尊敬的合并引擎。它可以处理几乎任何复杂性的合并。事实上，它唯一的主要合并限制是它在事后推断移动/重命名。在非常复杂的重构情况下，它可能无法正确处理所有内容。

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.

• Subversion 和 Git 在常见的合并场景中都能很好地工作。
• Git 将更有效地处理更复杂的合并场景，特别是在没有直接父子关系的分支之间合并时。
• 这两个系统在重构期间都存在跟踪重命名/移动的问题，尽管 Git 在典型情况下可能做得更好。
• Git 的 merge 命令在简单的情况下更容易运行。如果您进行不寻常的操作，这两个系统的学习曲线都会很陡峭。
• Git 支持相关操作，例如在存储库之间进行变基和合并，在某些情况下可以改善您的工作流程。
• 为了充分利用 Subversion，请确保您拥有 1.8+ 的服务器和客户端。

Hope that helps!

希望有帮助！

回答by Steve Barnes

A couple of things spring to mind.

有几件事浮现在脑海中。

1. Git supports private branches which AFAIK SVN doesn't.
2. Git actively supports workflows where one or more members of the team are developing, possibly propitiatory or confidential branches with commits to the version control and collaboration without between sub-team members without "publishing" the work to the rest of the team(s) and without complex ACL controls to lock some of the branches from being accessible to the remainder of the team.
3. With git and multiple developers you can always recover your repositories, (or the majority of them), complete with history in the event of a failure short of every developers machine being wiped out - with SVN if something happens to the main server/repository then it is all down to your backup policy.

1. Git 支持 AFAIK SVN 不支持的私有分支。
2. Git 积极支持团队中的一个或多个成员正在开发的工作流，可能是调解或机密分支，提交版本控制和协作，而子团队成员之间没有“发布”工作给团队的其他成员和没有复杂的 ACL 控制来锁定团队的其他成员无法访问某些分支。
3. 使用 git 和多个开发人员，您始终可以恢复您的存储库（或其中的大部分），并在发生故障时完成历史记录，而不是每台开发人员机器都被消灭 - 如果主服务器/存储库发生问题，则使用 SVN这完全取决于您的备份策略。

I am sure that there are many more.

我相信还有更多。