问题标签 [svn-merge-reintegrate]

在预提交脚本中，是否有可能（如果有，如何）识别源自svn merge?

svnlook changed ...显示已更改的文件，但不区分合并和手动编辑。

理想情况下，我还想区分标准merge和merge --reintegrate.

背景：

我正在探索使用预提交挂钩来为我们的项目强制执行 SVN 使用策略的可能性。

其中一项政策规定，某些目录（如/trunk）不应直接修改，只能通过重新集成功能分支进行更改。因此，预提交脚本将拒绝对这些目录所做的所有更改，除了分支重新集成。

有任何想法吗？

更新：

我已经探索了这个svnlook命令，最接近的是检测和解析svn:mergeinfo对目录属性的更改。这种方法有一些缺点：

1. svnlook可以标记属性更改，但不能标记更改了哪个属性。proplist（需要与先前版本的差异）
2. 通过检查 中的更改svn:mergeinfo，可以检测到svn merge已运行。但是，无法确定提交是否纯粹是合并的结果。合并后手动进行的更改将不会被检测到。（相关文章：Diff transaction tree against another path/revision）

我从主干创建了一个分支。随着我分支的开发完成，我想将我的分支合并（重新集成）到主干中。是否有启用选项或设置？似乎 Netbeans 7.1 无法将分支重新集成到主干中。

我错了吗？

假设我从发布分支“Version1.0”创建了一个 SVN 功能分支“Feature123”，用于开发新功能。我已经在我的功能分支中进行了一些更改并将它们提交到存储库，但尚未将功能分支重新集成到发布分支中。同时，我们还创建了一个“Version2.0”发布分支，以备将来发布。现在我的经理告诉我，他不希望我的 feature123 在 1.0 版中，而是在 2.0 版中。

有没有一种方法可以将我的 Feature123 分支重新集成到 Version2.0 中，即使功能分支是作为 Version1.0 的分支创建的？

我在存储库和本地都有主干和分支代码库。

目前我正在本地分支上进行测试，当测试正常时，我将分支从存储库重新集成到本地主干中。

现在有人告诉我，在重新集成之前，我需要从主干同步到分支。

我可以从本地分支重新集成到本地主干，还是必须在同步到存储库中的分支后提交，然后重新集成？

我相信我可以进行“本地”重新整合，但我不能 100% 确定这是否安全。

使用：Subversion 命令行客户端，版本 1.7.8。

我正在尝试清理这个旧的 svn 存储库。项目回购非常简单：

• /trunk/曾经是主要分支，自 531 版以来一直未受影响。
• /branches/Version2是新的主分支，版本 1300。它现在基本上是主分支；每个人都在这个分支工作。它与最新合并trunk。

我们想重新Version2融入trunk.

当我做：

我一直有问题。SVN 崩溃，或者在仅合并数千个文件后出现“截断的 html 响应”错误。

老实说，这是一个如此简单的合并（实际上是天真地替换trunk为Version2），是否有其他方法可以解决合并失败的问题？我错过了一些明显的东西吗？

我们使用 SVN 1.6 我们喜欢在分支之间执行代码合并，我们处于两难境地。

分支 A 存在
人们在分支 A 上进行代码更改
从分支 A 创建的分支 B
人们在分支 A 和 B 上都进行代码更改 分支
A 同步代码合并到分支 B
一段时间后
，从分支 A 创建的分支 C 分支
A 继续同步代码合并到分支 B（短时间）
人们在分支 C 上进行代码更改 人们停止在分支 A 上更改代码并“冻结”分支，不再有 ci
人们在分支 B 上进行代码更改
分支 C 同步代码合并到分支 B
人们进行代码更改在分支 B 和 C 上
经过一段时间

现在的困境：我们喜欢将分支 B 合并到分支 C

因为分支 B 来自分支 A 而不是分支 C，我们无法应用 --reintegrate 选项将代码从 B 合并到 C，因为它们不共享共同祖先

合并（没有 --reintegrate 选项）以防止 (C in B) 的“双重合并/重复代码”进入分支 C 的风险最小的方法是什么？

环境：

操作系统： Linux Mint 14

SVN：1.8.3

此问题发生在命令行和 subclipse 插件下。

我在现有项目下创建了一个新的 java 包，并在这个包中添加了许多类。当我提交到分支时，一切正常。但是，当我尝试将分支合并到主干中时，也就是重新集成（不要使用 --reintegrate 选项，它在 svn 1.8 中已弃用）发生任何错误并且没有冲突报告。合并带来所有修改，包括新包及其文件。

当我尝试提交或检查修改（svn 状态）时，只显示包。这些文件似乎是版本化的，并且在我的 repo 的最新版本中。这个事实也发生在其他分支中。每个包含新包的提交都有一个要合并到工作副本中的问题。

这很有趣，因为当我按修订合并分支修订时，它可以工作。似乎问题与自动合并有关。

I want to merge my branch to trunk and basically want to over-write all the code in branch to the trunk..While receiving conflicts I kept doing "theirs full" for all the conflict; but still at the end it shows so many conflicts.

All I want is over-write complete branch on my trunk. Surely a possible way is to branch out from my branch but then my trunk becomes useless !

Also, while doing svn merge can I give an option so that for all conflicts it takes a particular value ( in this case Full-theirs ) and I dont have to type it always for all the conflicts.

我们在使用新的 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 到主干的合并

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