svn合并是幂等的吗？

Question

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

Answer 1

从理论的角度来看，合并不是幂等的。真正的合并（Subversion以破解的方式支持 ¹ ，因为v1.5 ² ）将提交记录为具有两个（或更多）父项;通常你假设结果树是父提交的组合。然而，大多数（但不是全部）版本控制系统注意到父项之一（合并中的一个分支）是另一个的严格祖先，而不是创建合并它只会推进一个分支。 （Git将此情况快速转发或更新）。

合并后，在“scm merge B”之后，当在分支“A”上时（以下是尝试ASCII-art图），我们有以下情况：

---*---*---*---A---M               <--- trunk (branch A) 
                                  /
---*---*---*---B-/                     <--- branch (branch B)

合并提交“M”具有父母“A”和“B”。现在重复“scm merge B”可能会产生以下情况：

---*---*---*---A---M---N               <--- trunk (branch A) 
                                  /       /
---*---*---*---B-/----/                     <--- branch (branch B)

其中合并提交“N”具有“M”并且“B”作为父项提交。 （在某些情况下，Bazaar可以创造这种情况）

---

2009年7月22日编辑：

如果操作的多个应用程序不更改结果，则操作为idempotent。如果“scm merge branch_B＆amp;＆amp; scm merge branch_B”将给出与单个“scm merge branch_B”相同的结果，则合并将是幂等的。某些版本控制系统具有幂等合并功能;例如，Git会在行中的第二个相同的合并上声明“已经是最新的”，并且不会创建新的提交。有些版本控制系统没有;如果我根据给出合并命令的选项正确理解，Bazaar可以创建新的合并提交，父母“M”（先前合并）和“B”（来自branch_B）和树（内容）相同，合并为“M”。

---

脚注

1. 客户端 - 合并跟踪（如果PhilM不正确）？合并信息应存储在存储库中（对于像Subversion这样的集中版本控制系统，它意味着将其存储在服务器上）
2. 您可以使用 svnmerge扩展或 SVK ，这是在Subversion之上构建的（半）分布式版本控制系统。

Answer 2

如果您正在使用Subversion 1.5或更高版本并且您的svn:mergeinfo属性正在正确更新，那么是。但是，由于Subversion使用客户端合并跟踪，如果以删除/更改合并历史记录的方式修改svn:mergeinfo属性，那么您可能最终会将文件留在冲突状态。