我怀疑我的合并信息已损坏,但我不确定。有谁知道我将如何做出决定以及有哪些资源可以帮助解决问题?
这是问题。我的团队最近转向敏捷并使用功能分支(实际上是故事分支),其中不同的团队同时处理相同的源。当故事达到高度准备状态时,团队合并到主干。由于缺少更改、意外更改和冲突,合并需要数天或数周的时间。我们谈论的是 5-10 人的团队,努力/流失似乎很高。
人们使用这种合并模式
a) PULL - 合并主干到分支、解析、测试、提交
b) PUSH - 合并分支到主干、解析、测试、提交
c)重新创建分支(或通常创建新的故事分支并在完成后删除旧的)
到最后,分支和树干应该对齐。
我们看到的问题:
(1) 不应该发生。从分支到主干的拉动应该使两者同步,以应对主干上已有的所有更改。分支到主干合并中的更改是发生在主干上的更改。所以在第一次合并中,他们应该传播到分支,但没有。这表明合并信息数据中的损坏将“隐藏”主干更改。
(2) 不应该发生。 SVN 应该管理合并跟踪中的更改。这也指出了合并信息数据中的损坏
(3) 不应该发生。这是在分支上添加新文件的情况。它应该显示为添加到主干的新文件。这也表明合并信息数据损坏。
(4) 我相信这是一个 SVN 错误,我们无法修复。不过,如果这是我们唯一的问题,我会很高兴
我们目前在 svn 1.5.x 服务器上,客户端使用 svn 1.6.x 和 svn+ssh 进行连接。我们计划升级到最新最好的 SVN,因为一些修复可能会影响我们的问题。
尽管如此,看起来我们的合并信息数据确实是错误的。
有什么好的地方可以让我开始寻找吗?
最佳答案
由于类似的情况,我们遇到了类似的问题,并在很大程度上解决了这些问题。
主要的是这个:
如果您在分支创建后从主干合并到您的分支,则需要使用分支提交标记主干(使用 svn merge --record-only),否则当您尝试重新集成回主干时,它会尝试合并提交树干到分支回到树干。
这显然最终会恢复在以后的 trunk->branch 提交之后对主干所做的更改,往往会导致大量冲突(尤其是在主干中创建新文件或目录时的树冲突)等。
因此,我们的流程是在创建后永远不要将主干同步到分支(适用于短期分支),或者执行以下操作:
我找到了:http://www.collab.net/community/subversion/articles/merge-info.html在找出我们做错了什么时很有帮助。
关于svn - 如何确定 svn :mergeinfo is corrupt and how would I fix it?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2790471/