svn - svn 合并是幂等的吗？

Question

在我看来他们应该是这样。我假设您已经解决了第一次合并操作期间出现的任何冲突。

Answer 1

从理论上讲，merge 不是幂等的。真正的合并(从 v1.52 开始，Subversion 以一种 splinter 的方式支持)将提交记录为具有两个(或更多)父项；通常你假设结果树是父提交的组合。然而，大多数(但不是全部)版本控制系统注意到父级之一(合并中的分支之一)是另一个的严格祖先，它不会创建合并，而是只会推进一个分支。 (Git 将这种情况快进或更新)。

合并后，在分支“A”上的“scm merge B”之后，我们有以下情况(下面是ASCII艺术图的尝试):

---*---*---*---A---M <---主干(分支A)
/
---*---*---*---B-/<--- 分支(分支B)

合并提交“M”有 parent “A”和“B”。现在重复“scm merge B”可能会造成以下情况:

---*---*---*---A---M---N <---主干(分支A)
//
---*---*---*---B-/----/<--- 分支(分支B)

其中合并提交“N”有“M”和“B”作为父提交。 (在某些情况下 Bazaar 可以创造这种情况)

2009 年 7 月 22 日编辑:

操作是idempotent如果多次应用该操作不会改变结果。合并将是幂等的，如果“scm merge branch_B && scm merge branch_B”将给出与单个“scm merge branch_B”相同的结果。一些版本控制系统有幂等合并；例如，Git 会在行中的第二个相同合并时声明“已经是最新的”，并且不会创建新的提交。一些版本控制系统没有；如果我根据提供给合并命令的选项正确理解，Bazaar 可以创建新的合并提交，父项“M”(先前合并)和“B”(来自 branch_B)和树(内容)与合并“M”相同。

脚注

客户端合并跟踪(如果 PhilM 不正确)？合并信息应该存储在存储库中(在像 Subversion 这样的集中式版本控制系统的情况下，这意味着将其存储在服务器上)

您可以使用 svnmerge 扩展 , 或 SVK 它是建立在 Subversion 之上的(半)分布式版本控制系统。