svn合并是幂等的吗？

Question

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

Answer 1

从理论的角度来看，合并不是幂等的。 真合并（其中的Subversion支持在一个破碎方式^1，因为V1.5 ^2）记录提交为具有两个（或更多）的父母; 通常你假设结果树是父提交的组合。 然而，大多数（但不是全部）版本控制系统注意到父项之一（合并中的一个分支）是另一个的严格祖先，而不是创建合并它只会推进一个分支。 （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日编辑：

如果操作的多个应用程序不改变结果，则操作是幂等的。 如果“scm merge branch_B && 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属性，则可能最终会将文件保留在冲突状态。