我怀疑我有腐败的mergeinfo，但我不确定。有谁知道我如何做出决定以及有哪些资源来帮助解决问题？
这是问题所在。我的团队最近转向敏捷并使用功能分支（真正的故事分支），其中不同的团队同时处理相同的源。随着故事达到高度准备状态，团队合并到主干。由于缺少更改，意外更改和冲突，合并需要数天或数周。我们谈论的是5-10人的团队，努力/流失似乎很高。
人们使用这种合并模式 a）PULL - 合并trunk-to-branch，解析，测试，提交 b）PUSH - 合并分支到中继，解析，测试，提交 c）重新创建分支（或者通常创建新的故事分支，并在完成后丢弃旧分支）
在此结束时，分支和主干应该对齐。
我们看到的问题：
（1）不应该发生。从分支到主干的拉动应使两者同步，以便在主干上进行所有更改。分支到中继合并的变化是主干上发生的变化。因此，在第一次合并时，它们应该传播到分支但不会。这指向mergeinfo数据中的损坏，这将“隐藏”主干更改。
（2）不应该发生。 SVN应该管理合并跟踪中的更改。这也指出了mergeinfo数据中的损坏
（3）不应该发生。这是在分支上添加新文件的情况。它应该显示为添加到trunk的新文件。这也表明合并信息数据存在损坏。
（4）我认为这是一个SVN错误，我们无法解决这个问题。如果这是我们唯一的问题，我会很高兴
我们目前在svn 1.5.x服务器上，客户端使用svn 1.6.x和svn + ssh进行连接。我们计划推出最新最好的SVN，因为一些修复可能会影响我们的问题。
但是，看起来我们的mergeinfo数据确实是错误的。
任何好的地方让我开始寻找？
答案 0 :(得分：3)
由于类似的情况，我们遇到了类似的问题，并且很大程度上解决了这些问题。
主要的是：
如果你在分支创建后从trunk合并到你的分支，你需要用分支提交标记trunk（使用svn merge --record-only），否则当你尝试重新集成回trunk时它会尝试合并将树干提交回分支机构。
这显然最终会在后来的trunk-＆gt;分支提交之后恢复对trunk的更改，往往会导致大量冲突（特别是如果你在trunk中创建了一个新的文件或目录，则会发生树冲突），等等。
所以我们的过程是在创建分支后永远不会将trunk同步到分支中（对于短期分支很好），或者执行以下操作：
我发现：http://www.collab.net/community/subversion/articles/merge-info.html在解决我们做错的事情时很有帮助。
答案 1 :(得分：2)
我做了一些SVN分支/合并的实验，我发现在某些情况下合并不起作用 - 例如，来自trunk的更改会被覆盖。因此，如果您继续使用SVN进行功能分支，那么您将陷入痛苦的世界。
我用git进行了类似的实验，但我还没有找到一种方法来获得不正确的合并。如果团队/管理人员可以接受转移到git，我强烈建议您使用它。