问题标签 [mergeinfo]

生产发布分支（Branch PR）的标签从 1 到标签 20 。在这里，标签 20 是最终产品标签

分支 A ：从当前生产标签创建，例如：标签号 1 。分支 B ：从分支 A + 自己的更改创建现在标签 2 到标签 20 合并到分支 B 中。

即Branch B ----> tag 1 + tag 2 to tag 20 (from merging) + 自己的变化。

分支 C ：从生产标签 1 创建，然后将标签 2 到标签 8 合并到其中

即分支C---->标签1 +标签2到标签8（从合并）+它自己的变化。

现在我可以直接从分支 B 合并到分支 C 吗：

这里 Branch C 还包含 B 的更改（即标记 1 到标记 8 ）

我进行了合并，但没有将标记 9 更改为标记 20（其他分支更改很容易与一些冲突合并）。例如，在标签 20 中删除的代码片段在合并后仍然存在。此代码片段是在标签 8 中引入但在标签 20 中删除的。任何人都可以帮忙：

1.合并信息属性在这里如何发挥作用？和 2.svn 如何使用文件的过去 svnmerge info 属性，同时在其他分支中再次合并该文件。

这对于 svnmerging 来说是非常重要的学习。PS：请不要建议重新整合>我已经阅读了合并最佳实践并根据我们的环境遵循其中的大部分提前谢谢

我的两个分支之间的合并信息中有以下修订。

我想从这个列表中删除其中一个修订，以便我可以尝试再次进行合并。我该怎么做呢？

我最近开始在使用 SVN 1.5.5 作为存储库的环境中处理遗留代码库。这里的开发团队在 SVN 分支的机制上遇到了足够多的困难，以至于它已经被放弃了。我想在适当的时候保持分支的做法，并且遇到了一些我以前使用 SVN 从未经历过的困难。

在将trunk合并到一个分支时，我们发现有几十个没有改变的文件被列为已修改，而且它们往往会发生严重的冲突。SVN 将冲突显示为与自身混合的文件的一部分。由于没有人真正编辑过这些文件，因此很容易选择正确的版本并继续前进，但这仍然让开发人员对这个过程感到不安全。然后，当将分支合并回主干时，没有人编辑的同一组文件将发生冲突。除了在一个或两个分支或主干中合法编辑文件时，svn 合并算法因创建其他烦人的冲突而臭名昭著。

我们通常按照本指南中的做法进行分支和合并。但是，开发团队中有 12-15 人会直接与存储库交互，我不能保证每个人都 100% 地遵循“最佳实践”。在过去 8 年多的时间里，这个项目还有许多其他开发人员。

我们还在 svn mergeinfo 上看到很多没有人编辑过的文件的冲突。每次发生这种情况时，它都是一组完全不同的文件，但它保证在涉及分支的任何时候都会发生。自分支创建以来的时间越长，产生的神秘冲突就越多。

有时，使用“--dry-run”选项可以预测这些许多冲突但未编辑的文件。有时，使用“--dry-run”不会显示任何意外冲突，但运行相同的合并命令最终会导致大约 45 个没有更改的文件发生冲突。

如果我在主干的根目录运行'svn propget svn:mergeinfo'，我会得到一个很大的分支名称列表和它们涵盖的修订号，例如：

总共 54 行这样的行。这是 propget mergeinfo 的预期输出 - 只是一个分支列表？

我正处于我相信某些东西被破坏的地步，并且这不能是以看似默认的方式分支/合并的预期结果。从 2007-08 年开始，我使用 SVN 一年多，从未遇到过如此严重的问题。但是，我不太确定从哪里开始寻找解决方案。我和一些同事考虑了以下几点：

• 我们的 svn 版本 (1.5.5) 有问题。我们需要升级，这可能需要与一些官僚作斗争，但不应该太痛苦。

• 在存储库历史的某个时刻，svn mergeinfo 已损坏，或以某种方式手动编辑。有没有办法检查这个？如果是这样，有没有办法解决它？

• 在存储库历史的某个时刻，它以某种方式变得“损坏”。不知道如何在这里进行。

有没有其他人遇到过类似的问题？如何解决此问题，以使未修改的文件不会列为冲突，并且我的团队可以继续使用分支，而不必担心破坏代码库中的随机内容？

（作为记录，有一个长期项目要切换到 git。不幸的是，暂时被 SVN 卡住了。）

我试图让 SonarQube 为我的第一个项目工作，现在在分析 C++ 代码期间遇到此错误消息：

我找到了这个相关的答案，但我们在我们的服务器上运行 v1.6.11，而不是 v1.7。

我注意到 subversion 1.6 确实支持 mergeinfo 但也许 SonarQube 使用 v1.6 的错误语法进行查询？

如何使用 svn server v1.6.11 让 mergeinfo 与 SonarQube v5.2 和 SVN 插件 v1.2 一起使用？

在将我们的 SVN 服务器移动到完全不同的机器上之后，在不同的路径上，我发现我们所有的开发团队都无法再正确合并了。

具体来说，这个问题有点类似于这个问题，但这似乎不是路径区分大小写的问题。

更详细地说，这是我们目前使用的：

• 颠覆：1.8.16（32 位）
• ToitoiseSVN：1.9.4（64 位）
• 服务器：从 Ubuntu 12（32 位）移至 Windows 10（64 位）

正如我所说，这个问题类似于链接问题中的问题，但是在这种情况下，我检查了本地工作副本中的存储库路径和完成合并的路径，它们是相同的。

我也尝试过重新结帐，但仍然没有运气：TortoiseSVN 说工作副本属性已更新，但实际上没有。

实际上，在提交合并时，我没有看到属性更新。

如果我手动添加它们，那么一切顺利。

除了每次手动记录mergeinfo之外，我能做些什么来解决这个问题？

我在命令下运行

svn mergeinfo --show-revs 合格 --log svn:///svn/branches/16.1.3.x svn:///svn/trunk -R -v

但是，在输出中，我从 16.1.1.x 和 16.1.2.x 等其他分支获得修订，而不是来自 16.1.3.x 的单个修订。然而，如果我从Tortoise svn 的合并屏幕显示日志，那么我只会得到分支 16.1.3.x 的修订版。

我希望 mergeinfo 命令具有相同的行为。请帮忙。

我认为我必须在我的理解中遗漏一些基本的东西，这使我无法理解这一点。

在执行合并时，您希望在什么情况下使用 --ignore-ancestry 选项？据我了解，使用此选项可防止在目标分支上更新 mergeinfo 属性，但在什么情况下您不希望记录 mergeinfo？

我使用 Tortoise 1.9 作为 Apache Subversion Server 1.7 的 SVN 客户端。我意识到我的所有合并都没有记录到 svn:mergeinfo。"svn mergeinfo --show-revs" 和 Tortoise 属性显示都不会显示合并后的版本。记录其他开发者（不是全部）的合并。似乎同一个开发人员总是维护 svn:merginfo 而其他人从不维护这个。

我不确定，与服务器版本相比，这是否是客户端版本的问题。我搜索了几篇处理相同问题的文章 - 但没有找到任何解释。我可以做些什么来调试/跟踪这个吗？

我正在寻找一种方法来获取从一个分支到另一个分支存在合并的所有点。我可以从 eclipse 图形工具中看到这些（想说 subclipse 4.3.0 提供了这个功能）。但是，我还没有想出一个可以生成完整修订列表或合并位置列表的终端命令。

到目前为止，我已经尝试了一些命令，包括 (svn log -v -g)，但遇到了一些问题。例如命令的 repo 版本或格式错误。我怀疑这是由于远程仓库是 v1.6.11 而我的本地 svn 是 v1.12.0。以及回购是格式12（我认为是v1.7）。

另外，当我运行'svn log -v -g'时，我收到以下错误：svn：E200007：查询mergeinfo需要FSFS文件系统架构的版本3；文件系统 '/opt/svn/REPOS2/NAME/db' 仅使用版本 2

我也是 svn 的新手，所以如果你能解释你提供的任何命令或包含我可以阅读的资源，那将是很酷的。如果这很重要，我也在使用老一代的 mac。我也是新手，因为我传统上使用 Windows 作为我的日常工作站操作系统。