7

我怀疑我的合并信息已损坏，但我不确定。有谁知道我将如何做出决定以及有哪些资源可以帮助解决问题？

这就是问题所在。我的团队最近转向敏捷并使用功能分支（实际上是故事分支），不同的团队同时处理相同的资源。随着故事达到高度就绪状态，团队合并到主干。由于缺少更改、意外更改和冲突，合并需要几天或几周的时间。我们谈论的是 5-10 人的团队，工作量/流失率似乎很高。

人们使用这种合并模式 a) PULL - 合并主干到分支，解析，测试，提交 b) 推 - 合并分支到主干，解析，测试，提交 c) 重新创建分支（或通常创建新的故事分支和完成后就老掉牙）

到此结束时，分支和树干应该对齐。

我们看到的问题：

  1. 在主干到分支合并期间未报告的更改显示在后续的分支到主干中
  2. 合并期间 svn:mergeinfo 属性的冲突
  3. 文件丢失，但对分支中添加的新文件进行本地编辑并推送到主干
  4. 传入 + 本地删除（在主干和分支上删除的文件显示为冲突）

(1) 不应该发生。从分支到主干的拉动应该使两者在主干上已经发生的所有更改同步。分支到主干合并中的更改是主干上发生的更改。因此，在第一次合并中，它们应该传播到分支但没有传播。这表明合并信息数据中的损坏会“隐藏”主干更改。

(2) 不应该发生。SVN 应该管理合并跟踪中的更改。这也表明 mergeinfo 数据损坏

(3) 不应该发生。这是在分支上添加新文件的情况。它应该显示为添加到主干的新文件。这也表明合并信息数据损坏。

(4) 我相信这是一个 SVN 错误，我们无法修复它。如果这是我们唯一的问题，我会很高兴

我们目前在 svn 1.5.x 服务器上，客户端使用 svn 1.6.x 和 svn+ssh 进行连接。我们计划升级到最新最好的 SVN，因为一些修复可能会影响我们的问题。

不过，看起来我们的 mergeinfo 数据确实是错误的。

  • 不报告所有更改的合并
  • mergeinfo 属性合并中的冲突

有什么好地方让我开始寻找吗？

4

2 回答 2

3

由于类似的情况，我们遇到了类似的问题，并且基本上已经解决了这些问题。

主要的是这样的：

如果您在创建分支后从主干合并到您的分支，您需要使用分支提交标记主干（使用 svn merge --record-only），否则当您尝试重新集成回主干时，它会尝试合并提交树干到分支回到树干。

这显然最终会恢复在稍后的 trunk->branch 提交之后对主干所做的更改，往往会导致大量冲突（尤其是在主干中创建新文件或目录时的树冲突）等。

所以我们的过程是要么在创建后永远不要将主干同步到分支中（适用于短期分支），要么执行以下操作：

  • 来自主干的分支 b
  • 提交到主干和分支
  • 将主干重新集成到分支并提交（解决冲突但不进行任何更改，甚至编译）
  • 立即执行 svn merge --record-only 的主干到分支提交修订
  • 修复分支的任何其他问题并继续开发
  • 完成后从分支重新整合到主干。

我发现：http ://www.collab.net/community/subversion/articles/merge-info.html在找出我们做错了什么时很有帮助。

于 2011-08-31T21:09:59.400 回答
2

I did some experiments with SVN branching/merging, and I found out that there are some situations when the merging just doesn't work - for example changes from trunk are overwritten. So if you keep using SVN for feature branches, you'll be in world of pain.

I made similar experiments with git and I haven't found a way to get incorrect merge. If moving to git might be acceptable by team/management, I strongly recommend using it.

于 2010-05-07T18:18:35.850 回答