问题标签 [svn-reintegrate]

情况是这样的：

一个团队致力于长期的功能分支（18 个月）。定期将主干合并回此功能分支（每月开始，之后每两/三个月）。

今天我们想使用 reintegrate 功能将功能分支合并回主干。

问题是我们得到了很多（数千！）：

但是，当我检查 svn 日志时，我可以看到 94000-96500 范围确实在过去的某个时间被合并了。

这里发生了什么？如果不是真的，为什么 svn 会抱怨“缺少范围”？如果我在 94000-96500 上看到合并信息，是否会有 r94959 丢失的原因？我该如何解决这个问题（正如我所说，我们正在谈论数千个“缺失”的修订）？

谢谢您的帮助。

我正在使用 SVN。我有一个从另一个分支创建的分支，该分支又从主干创建。现在将我的分支重新整合到主干的正确程序是什么？

我们决定为某些功能创建一个分支，这样我们就不会影响头部，现在的问题是，在我们的分支中继续合并来自 trunc 的更改是个好主意吗？这会使最终的重新融合变得更容易吗？

我们使用 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 的风险最小的方法是什么？

我有我的项目，我必须在主干中重新整合 2 个分支......情况是这样的：

现在我想将这两个分支统一并重新整合到一个新的分支中。

我尝试使用以下方法创建一个新分支：

svn cp ^/trunk ^/branches/app-v2

然后在新分支中创建一个：

svn merge ^/branches/branch1 --reintegrate

但我得到了：

svn: '/svnrepos/!svn/bc/xxx/branches/app-v2' path not found

我认为这取决于创建branch1时app-v2不存在。

如果我尝试使用常规合并（没有--reintegrate）我有很多冲突......

如何将两个分支合并为一个新分支？

谢谢

环境：

操作系统： Linux Mint 14

SVN：1.8.3

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

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

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

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

经过一番阅读，打算了解什么是真正的 svn reintegrate。

有人可以举一个例子：

svn 合并分支到主干和 svn merge --reintegrate 分支到主干

哪个给出不同的结果？

我使用 TortoiseSVN 在 SVN 中管理源文件。我添加了文件并将它们提交到修订版，随后决定分支。我用我需要的文件进行了分支，并在不打算使用的文件的主干上执行了删除。

现在我正在尝试将分支重新整合到主干。使用乌龟，我已经从主干合并到分支的修订范围，从主干上的删除到头部。这使分支保持最新状态。

现在我切换到主干，并尝试将分支中的修订合并到主干，合并表明新文件被“跳过”或删除我现在已完成的文件。

我在合并到最新的主干时是否遗漏了一些东西？

我已经阅读了SVN 1.8 的这些发行说明和关于将分支与 SVN 1.8 重新集成的问题。

我找不到答案的问题如下：

选择有没有区别

1. all revisions
2. specific range连同一个空盒子

在将分支重新集成到树干时的乌龟合并对话中？

在这两种情况下，Turtoise 是否使用带有合并跟踪的自动合并？我该如何验证呢？

我有一个我正在研究的 Ruby on Rails 项目，它使用 SVN（1.6.17，Debian）进行版本控制。在本地，我正在使用带有 git-svn 的 Git（2.5.4，OS X），并且我一直在开发一个分支（称为“ruby22rails42”）以对项目进行重大更新（使用新的框架版本）并定期进行更改从 SVN "trunk" 跟上项目的最新情况。最近，我在我们的在线SVN服务器上创建了一个镜像分支（“/branches/v8.5-ruby22rails42”），将我本地的Git分支推送到那里，并再次与主干合并，供其他开发人员查看。

现在我基本上希望“/branches/v8.5-ruby22rails42”成为新的“主干”，并将旧的 SVN 主干保留为版本化分支（我们称之为“/branches/v8.4-ruby19rails3”）。不幸的是，“svn merge --reintegrate”似乎因“不支持合并信息”错误而失败：

会svnadmin upgrade修复这个错误吗？我现在不想更新服务器上的 SVN 实用程序，因为许多其他工具也可以访问 SVN 存储库。

如果不：

（如何）我可以在 SVN 服务器和我的 git-svn 本地存储库上重命名主干并将我的分支用作新的“主干”，从而完全避免 SVN 中繁琐的合并过程吗？我如何告诉我本地的 Git 存储库来跟踪这个重命名过程？这可能需要所有客户端放弃本地结帐并重新签出新中继，但这是可以接受的。

如果这是不可能或不可取的，我如何使用 Subversion 1.6.17 避免上述合并信息错误并成功地将我的分支合并到主干中？然后，我可以从合并之前的最后一次提交创建一个新分支，并将其保留为我的“v8.4-rails3ruby19”分支。