【问题标题】:How do I determine if svn:mergeinfo is corrupt and how would I fix it?如何确定 svn:mergeinfo 是否损坏以及如何修复它?
【发布时间】:2011-02-16 22:36:50
【问题描述】:

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

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

人们使用这种合并模式 a) PULL - 合并主干到分支、解析、测试、提交 b) PUSH - 合并分支到主干、解析、测试、提交 c) 重新创建分支(或者通常创建新的故事分支并在完成后丢弃旧的分支)

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

我们看到的问题:

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

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

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

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

(4) 我认为这是一个 SVN 错误,我们无法修复它。不过,如果这是我们唯一的问题,我会很高兴

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

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

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

有什么好地方可以让我开始寻找吗?

【问题讨论】:

  • SVN 1.6.11 客户端可能是我的答案。我使用了 wandisco 升级站点(其中摇滚)并且合并地狱不那么令人讨厌
  • 您是否使用“--reintegrate”标志进行“推送”合并?事实上,你在它之后有一个“解决”步骤,这表明你不是。我找不到具体的文档说没有“--reintegrate”的双向合并不能工作,但是“--reintegrate”的存在表明svn的合并不能胜任任务。

标签: svn merge branch agile-processes


【解决方案1】:

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

主要是这样的:

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

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

因此,我们的流程是在创建分支后永远不要将主干同步到分支中(适用于短期分支),或者执行以下操作:

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

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

【解决方案2】:

我对 SVN 分支/合并进行了一些实验,发现在某些情况下合并不起作用 - 例如来自主干的更改被覆盖。因此,如果您继续使用 SVN 进行功能分支,您将陷入痛苦的世界。

我用 git 做了类似的实验,但我还没有找到一种方法来得到不正确的合并。如果团队/管理层可以接受迁移到 git,我强烈建议使用它。

【讨论】:

  • 我听说了,但是 mergeinfo 属性上的冲突似乎表明存在更深层次的问题
  • 我想我应该让自己更清楚:我试图打破 SVN 中的合并,我第二次尝试成功,但我无法在 Git 中创建损坏/不正确的合并。因此,您可以尝试跟踪 mergeinfo 问题的根本原因,或者您可以更有效地利用时间并切换到对分支更友好的版本控制系统。
  • 在我正在运行的时间范围内迁移到 git 不是一种选择。所以,我需要在 SVN 中解决我的问题
  • 团队选择迁移到 git 并合并问题似乎消失了。现在,我们将使用团队作为试点来确定 git 在整个组织范围内是否可行。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-09-04
  • 2022-11-20
相关资源
最近更新 更多