我的 TortoiseSVN 合并做错了什么？答案

【问题标题】：What am I doing wrong with my TortoiseSVN merges?我的 TortoiseSVN 合并做错了什么？
【发布时间】：2014-08-14 15:50:11
【问题描述】：

我在将生产版本（需要手动合并以解决与早期版本的冲突）合并回它所在的分支时遇到问题。合并没有发现任何冲突，并且自动合并正在破坏合并的文件。谁能看到我做错了什么？

这是我工作的 SVN 设置：

Trunk 是生产代码，它会自动部署到网络服务器，不会出现任何错误或问题。
“Dev”是每个人都致力于一般错误修复和大多数小型开发的分支。
还有其他用于大型项目的分支，例如“project1”。
每天，Trunk（生产）都会合并到每个分支中，包括 Dev。这是因为我们不希望任何人使用与我们的生产代码有任何不同的代码库，除了他们在该分支中所做的更改。

（我也欢迎批评我们的 SVN 结构/程序。）

注意：这是针对没有并发维护版本的大型 Web 应用程序，它只是 24/7 全天候运行，我们会不断对其进行修改/更新，包括错误修复、新功能等。

我们过去每天都会遇到合并问题，最近我们将我们的 SVN 实践重组为我上面描述的内容。在这件事发生之前，它似乎没有问题。

当人们的更改经过全面测试并准备好部署到生产环境时，他们会将这些修订从其分支合并到生产环境中。这通常最终导致将更改从主干反向合并到当天晚些时候它们来自的分支中。我认为这可能是问题的根源，但直到今天它已经顺利运行了数周。

以下是我所遇到情况的详细信息：

一名开发人员在 Dev 中工作，并准备好部署到生产环境（主干）的几个修订版，他们切换到主干，打开合并对话框，选择他们的分支，挑选他们计划部署的几个修订版，然后点击合并（使用默认设置）。假设没有冲突，他们通常会提交到主干（自动部署到网络服务器并在几秒钟内上线）。在这种情况下，存在冲突。其他人先前已将修订版部署到主干，该修订版修改了其中一个相同的文件。开发人员手动合并两个修订并测试文件，确认它正在工作，并将合并的更改提交到主干。

在一天结束时，我将主干重新合并到我们所有的分支中，以确保明天每个人都拥有最新的代码，并尽早而不是迟到意识到任何冲突。为此，我一次切换到每个分支，打开合并，选择主干，然后只选择今天提交的修订进行合并。我使用默认设置运行合并，并将合并的更改提交到分支中。在这种情况下，当我到达 Dev 分支并从主干合并时，我遇到了问题。几乎今天所有的主干更改实际上都来自 Dev 分支，所以除了属性修改之外什么都没有引入，除了在开发人员尝试部署它时发生合并冲突的那个文件。该文件会自动合并。我打开文件看看它带来了什么，合并被搞砸了。它复制了一些代码行（导致代码错误），并将其他代码行乱序等。

还应该注意的是，我们团队中的一些人在 Visual Studio 中使用 AnkhSVN，而我和其他一些人只使用 TortoiseSVN。

【问题讨论】：

标签： svn tortoisesvn ankhsvn

【解决方案1】：

在尝试部署更改之前，开发人员可能需要将主干合并到他们的分支中。你说你每天手动执行一次，但它应该发生在任何人尝试部署到主干之前，因此它们是完全最新的。

根据我的经验，我发现在将任何分支合并到主干之前，最好先将主干合并到该分支以解决冲突。

我通常也不会永久在分支机构工作。我的团队通常这样做：

从主干创建一个分支以处理特定任务
将工作提交给分支
代码审查分支
修复代码审查中发现的任何内容并再次审查
根据需要重复 3 和 4
将主干合并到分支以获取自分支以来已完成的任何工作并解决冲突
最后，将分支重新整合到主干中

顺便说一句，我认为在 Git 中你可以使用一个叫做“rebase”的特性来完成你每晚所做的工作（将主干合并到每个人的分支中）。我认为它实际上对提交进行了重新排序，以使其就像您的分支在主干中的新提交之后实际分支一样。可能值得研究。

【讨论】：

感谢您的反馈。我同意你在提交之前从主干合并。这实际上列在我们针对团队的 SVN 指南中，而且大多数情况下人们都会这样做。在这种特殊情况下，我有点困惑，因为导致问题的修订是在一周前提交给主干的。这意味着自从进行更改以来，我已经多次将主干合并回该分支，但不知何故，该更改从未真正进入该分支。我现在想知道是不是我在不知不觉中搞砸了合并。
您对如何修复这些文件有什么建议吗？主干包含正确版本的代码，而开发分支没有，但是我现在无法从主干合并回开发分支，因为它破坏了代码。 [编辑：我绝对对 GIT 很感兴趣，但我不确定我能否说服团队很快切换到它。]
还有一条评论，因为字符限制相当低：关于您通常不会在分支之外永久工作，我认为这是一个好方法。我们最近对政策的重组要求我们在最终更改合并到主干后删除特定项目的分支，如果该项目需要再次处理，我们会从主干中为其创建一个新分支。对于一般的 Dev 分支，我没有办法做到这一点，除非我们只是随意重新集成然后定期重新创建分支，因为一般维护永远不会结束。
这是一个令人困惑的问题。有时我注意到在这种情况下，我的工作副本被搞砸了，为了解决这个问题，我已经做了一个新的结帐再试一次。这是一个很长的猜测，但它可能会有所帮助。除此之外，也许您可以尝试从新主干分支并在新分支中进行编辑？我知道这并不理想，因为您的分支历史记录会有所不同，但它可能会揭示一些问题。
给您的另一条评论：这听起来像我们在一个分支中开发的类似情况，将其合并到主干，然后删除该分支。不过，我们确实有一些永久分支机构。每当我们创建软件的稳定版本时，我们都会在那时创建一个分支。这样，如果出现任何问题，我们可以修复分支中的错误并将错误修复合并到主干中。在此期间，可以在主干上继续正常开发，而不会影响稳定发布分支。正如您所描述的，通过多年令人费解的合并问题，我们刚刚决定合并是严格的分支->主干。

【解决方案2】：

跟进@Travis“尽快合并”（来自我的 +1）

日常同步合并的 GUI 合并是 BAD IDEA (tm) - “GUI 无法自动化”
Cherry-pick merges for merges trunk -> branch 是 BAD IDEA (tm) - 因为它纯同步合并（svn help merge 1-st 形式）并且必须是以这种方式执行并且仅依赖于 mergeinfo（并且丢失记录的可能性为零）
您（或“merge-master”）必须验证所有分支或至少 DEV 是否有跳过的主干修订（svn mergeinfo --show-revs=eligible ^/trunk ^/DEV 必须为空）
如果您的 SVN 客户端仍然早于 1.8 - 升级并使用此版本：它不会消除所有合并地狱，但会使某些方面更容易

对于您的“Merge-dance”开发，使用 VCS 和 merge 作为一等公民（对于 Subversion 仍然不是这样）将使生活变得更轻松，并且显着减少头痛或普通操作：不再有“Merge Hell” .使用 SVN 背景，迁移到 Mercurial（不是 Git）将几乎是透明的，工作流程的变化很小（在发布和部署阶段）

【讨论】：

我很抱歉，我觉得你真的在帮助我，但我很难理解你所说的一些事情。例如“因为它纯同步合并（svn help merge 1-st form）并且必须以这种方式执行并且仅依赖于mergeinfo”另外，“将VCS与merge作为一等公民”。感谢您的帮助。
我“挑选”从trunk->branch合并的原因是因为在我们切换到当前政策之前，人们正在挑选trunk->branch并完全忽略了一些修订，这个导致我无法合并所有修订版本的 SVN 存储库状态，因为它会导致成百上千的冲突，并且通常无法完全合并。因此，自从我们开始执行这项新政策以来，我会挑选自上次每日同步（昨天）以来已提交到主干的 100% 的修订，并确保将它们合并回分支中。