问题标签 [mergeinfo]

我正在window7上开发IntelliJ。从我的树干上的分支合并 7 个文件。但如下图所示，更改时会显示 7 个文件和 1 个目录。这个目录，我没有创建。

我认为这个目录不是物理目录，它只是元数据文件。你能解释一下这种情况和它目录的含义吗？

谢谢。

我正在调查我们在合并时遇到的问题，我最近发现了一些东西，我希望有人能告诉我这是否是问题的征兆。

我在svn:mergeinfo其^/trunk本身中找到了以下记录：

是否存在正常情况，在主干中包含有关主干本身的信息的合并信息记录是合乎逻辑的，或者这是出现问题的结果？

如果它是相关的：我们没有重命名主干。svn:mergeinfo在功能分支的重新集成合并期间似乎添加了“主干记录”

编辑： 似乎mergeinfo记录与重新集成的预期时间/trunk:1234一起意外添加到主干。这是第一次使用 Subversion 1.8，因此它使用了现在的自动重新集成功能。此外，1234 数字不是随机的，它是在创建分支之前存储库的版本。/branches/somebranch:1235-1241/branches/somebranch

我们没有发现任何我们可能做错的事情。我们得出结论，这可能是 Subversion 客户端中的一个错误 (TortoiseSVN-1.8.4.24972-x64-svn-1.8.5)

我正在寻找一个非常常见但被忽视的脚本，直到最后一分钟动作，SVN 合并。

理想情况下，它应该为当前用户运行，让我们说最近 2 天以您的名义提交。因此，在您在分支上工作的情况下，运行此脚本会将您的更改合并到主干并启动提交对话框，以便您可以在提交之前进行验证。

我们的分支策略允许使用trunk-branch1-branch1.1，因此您将从最后开始并合并到主干。

鉴于我们有大量的开发人员，我并不是在寻找灵丹妙药，而是在寻找可以促进这一过程的东西。

我查看了 svn 命令（mergeinfo），但不确定如何应用“按用户”过滤器。

非常感激

有时当我从主干合并项目时，即使我的版本和主干之间没有区别，一些文件也会出现修改（即，需要通过合并签入）。比较表明它们完全相同，即使空白没有不同。

• 这怎么可能？它与 mergeinfo 有关吗？
• 考虑到没有更改，不将这些文件签入我的分支有什么副作用...
• 当我尝试合并回主干时会不会有麻烦？

在这里向所有 SVN 专家提问！

我有一个基于主干的功能分支。我进行了合并以同步分支中主干中完成的工作，并提交了除分支 root 上的 mergeinfo prop 之外的所有更改。所以现在，当我尝试进行另一个同步合并时，它会尝试重新应用之前合并中已经应用的所有更改。

有没有一种简单的方法可以在 mergeinfo 属性中记录这些信息，使其行为正确？我确切地知道在错误合并中应用的更改。本质上它是以下输出：

其中 12345 是合并后的修订号。

提前致谢。

我早就听说过 svn 的合并冲突问题。

当我得知 svn 几个版本前实现了一个名为mergeinfo. 似乎它的引入将允许 svn 有足够的信息来解决它的合并问题，只要它们弹出。直到我遇到以下情况：

上图的脚本示例：

如果 svn 保留了每个分支来自何处的历史记录，为什么它不能理解b.txt保持不变 @ branch A？

如果它无法弄清楚这一点，svn 的实际用途是mergeinfo什么？

如果 svn 无法处理这个问题，难道不能在这方面创建一个工具来帮助我（即自动解决这种不费吹灰之力的问题..）吗？我猜也许一个已经存在？

谢谢

我们在使用新的 1.8 subversion 客户端时遇到了问题（我们使用 TortoiseSVN 1.8.5 和 SlikSVN 1.8.5）。在某些情况下，重新集成后能够继续使用功能分支的新 SVN 1.8 功能似乎不起作用。

当主干包含本地合并信息（文件或子树上的合并信息）时，它不起作用。这可能会导致重新集成后分支重用的问题。如果使用“keep alive dance”（使用仅记录选项）完成分支重用，这对 1.7 客户端来说不是问题。

我制作了一个脚本，从头开始说明这个问题。它可以使用 1.8 客户端针对空存储库运行。

下面的脚本有 10 个步骤。步骤 1-5 用于创建在主干中具有本地合并信息的启动情况。步骤 6-9 模拟在功能分支的生命周期中对主干进行的更改2。第 10 步是失败的步骤，它模拟了重新集成后功能分支重用的第一步。

这是第 10 步中的错误：

这是（Windows）脚本。

我不明白为什么会这样。此外，错误报告缺少 file1.txt 的范围，而似乎是缺少合并信息的 file2.txt。虽然不是解决方案，但删除主干中 file2.txt 上的本地合并信息似乎也可以解决问题。这也暗示错误消息报告了错误文件的内容。

编辑：对@gbjbaanb 的响应即使错误消息相同，此问题也比您所指的问题更微妙。在我的情况下，失败的不是重新集成到主干，而是分支之后的重用。

另外，如果我查看 file1.txt 和 file2.txt 的合并信息，似乎 file2.txt 缺少 featurebranch2 的合并信息记录，因此问题出在 file2.txt 而不是 file1.txt 的错误提示。因为 file1.txt 在 featurebranch2 的生命周期中在主干中发生了更改，并且 file2.txt 不是关于主干的合并信息，所以在步骤 8 的合并过程中没有在 file2.txt 上设置。我相信这是它开始的地方出轨。这不会影响重新集成到主干，但会阻止功能分支之后的重用。

编辑：回复@David W 我已经尝试过--record-only -c 11这也适用于 Windows 端。我已经在没有-c的情况下尝试过（通常你不应该，我知道，但在这种情况下没有其他更改）然后它报告：

为了更好地衡量，我还尝试了 --record-only -c 1-11，我期望这与不使用-c相同（因为 11 是 HEAD）。我最初的期望是它会以与不使用相同的方式失败-c，但事实并非如此。它的成功方式与-c 11相同。

但我这篇文章的重点是，使用 SVN 1.8，我们不需要做保持活动的诡计。（草案）文档说：

如果您在将分支重新集成到主干后选择不删除分支，您可以继续从主干执行同步合并，然后再次重新集成分支[37]。如果这样做，则只有在第一次重新集成后对分支所做的更改才会合并到主干。( http://svnbook.red-bean.com )。

从 Subversion 1.8 发行说明：

使用自动重新集成合并可以以任何顺序在两个分支之间来回合并（不再需要“keep-alive dance”）。为获得最佳结果，建议始终合并所有符合条件的修订，即不使用 svn merge 的 -r 或 -c 选项。仅合并符合条件的修订的子集会增加未来合并期间出现问题的可能性。（https://subversion.apache.org/docs/release-notes/1.8.html）

所以我的观点是，这个分支重用没有保持活动的诡计显然在本地合并信息面前不起作用，我的脚本似乎表明了这一点。

如果您仍然认为有关缺失范围的警告可能是正确的，除了可能报告的范围编号，请告诉我我的脚本中导致缺失范围的位置。我的脚本是主干和分支之间的简单来回切换，没有对它们进行并行处理。

您还可以解释为什么还要通过在步骤 7 中添加： “echo Additional file contents created in trunk. >> trunk\file2.txt” 来解释为什么要修改 file2.txt，这将导致在步骤 10 中没有错误。修改附加文件在主干上无法解决缺失范围问题。

我有一个从主干开始的分支 A 和一个从 A 开始的分支 B。定期地，从主干到 A 的合并，然后也执行从 A 到 B 的合并。当我想将 A 和 B 合并到主干时，我认为遵循这种方式：

• 重新整合从 B 到 A 的合并
• 重新整合从 A 到主干的合并

这是正确的吗？或者它会导致合并信息或其他问题的问题？在这种情况下，最佳做法是什么？

对不起，如果这不是一个有效的问题（我希望我是对的）。

我正在使用 SVN 进行的项目由两个“分支”组成。主干是完成大部分开发的地方，还有“发布”分支，这是发布最终版本的地方。

这个想法是，当我对主干进行更改并对其进行测试时，这些更改仅在我确信已找到大多数/所有错误时才合并到分支中并发布。但是，分支永远不会与主干完全相同。这是因为它使用不同的连接字符串、不同的图标等。

结果，每次我将主干中的新修订合并到分支中时，svn:mergeinfo 属性都会变得越来越大。现在它的值是“/trunk:2216-2225,2231-2234,2239,2246-2247,2253,2255,2259-2268,2271”。随着项目的继续，合并后的修订号将继续添加到其中。

注意：这是唯一存在的 svn:merginfo 属性，并且位于分支的根目录。

所以我的问题是我是否需要这个（最终是巨大的）价值留在那里，或者我是否可以删除它。

编辑澄清：分支永远不会合并回主干。只会进行主干到分支的合并。分支存在的原因是最新发布的版本始终可用，但由于来自主干的必要更改，标签无法完成这项工作。

我看到过类似的问题，但它们似乎都是关于在最新合并时更新的分支与主干相同或存在多个 svn:merginfo 属性的项目，所以我不确定相同的答案是否适用这里。

谢谢你。

我们在 SVN 中有不同的分支，并在分支之间进行 svn 合并。每个分支几乎都相互关联，因为我们的代码是增量的。假设如果一次大约有 5 个分支（分支 1 、分支 2 等....），并且分支 X 在某个时间线合并到分支 Y 中，并且两个分支也都有自己的代码开发：

• 分支 1 = 代码库 A（来自生产中的先前分支）
• 分支 2 = 代码库 A + 它自己对代码库 A 的更改

现在，如果分支 3 也具有分支 1 的代码库，并且有自己的更改，即（代码库 A + 分支 1 更改 + 分支 3 更改）。分支 4（从分支 1 创建并且也有自己的更改）

• A) 现在我如何将分支 2 合并到分支 3 以避免代码冗余和合并问题。**
• B）另外，我想将分支 3 合并到分支 4 并保持分支 3 的更改。

现在，我特别面临删除同一文件中的代码和重复代码的问题。

面临的问题

有时，未处于冲突状态的文件会在文件中两次获取代码内容。并且

分公司3、分公司4的案例

在分支 3 中删除的代码在分支 4 中以某种方式再次可见，尽管合并是通过正向方法完成的 (branch1 --> branch2--> branch3 --> branch4)

我们尝试每次都保持相同的基础，但仍然遇到上述问题。我想了解在上述情况下应该如何进行合并。请提出您的意见。任何具有 svn merge 实用知识的人都会非常有帮助。

PS：我已经研究过合并最佳实践，但现在有了清晰的方法。我知道合并的基本方法，但从未在这样的复杂场景中合并