0
我们一直在工作中使用工作流几个月，其中SVN开发人员创建SVN修复分支，这些分支使用git合并到一个集成分支中，并提交回SVN，与dcommit一次合并。在这个工作流程中，有一个git-svn回购协议完成所有合并工作。git-svn：保留两个不同的git-svn回购合并
这个工作流程工作得很好，git合并通常忠实地保存在原始的git-svn回购中。
但是，现在我们决定将合并工作负载分散到许多用户，每个用户都有自己的git-svn repo。不幸的是，我们现在发现由一个git-svn用户执行的合并有时（但并非总是）在另一个用户的git-svn repo中显示为单个父提交，而不像两个父合并。
合并历史记录的损失对历史分析造成严重破坏，并导致不必要的合并冲突，因为git无法再识别正确的合并基础，如果在所有存储库中保留合并父项，它可以执行的操作。
有没有人有任何帮助避免导致合并历史记录在一个或多个git-svn回购中与常见的SVN回购同步的情况下损坏的做法？
我一直在使用git-svn一段时间，并没有遇到这个问题。也许是由于我遵循了一个简单的工作流程。你提到的所有git分支都是“分支”吗？您可以提供您工作流程的更多细节。 – 2013-05-09 13:50:27
分支是SVN分支。 git合并总是在对应于两个SVN分支的提示的两个git提交之间，并且在成功合并之后，总是立即dcommit'd到SVN。 正如我所说，这一直工作得很好，当时我正在做所有的整合合并。然而，现在一个同事已经开始承担一些合并工作量，有时我失去了他合并的第二个父母，反之亦然 - 他有时会失去我所做合并的第二个父母。 – jonseymour 2013-05-09 13:59:19
BTW：我们有341个SVN标签和560个SVN分支。因此，集成分支尖端的svn：mergeinfo属性值非常复杂和庞大。 – jonseymour 2013-05-09 14:05:08