如何确定 svn:mergeinfo 是否已损坏以及如何修复它？
我怀疑我的合并信息已损坏，但我不确定。有谁知道我将如何做出决定以及有哪些资源可以帮助解决问题？
问题就在这里。我的团队最近转向敏捷并使用功能分支（实际上是故事分支），其中不同的团队同时处理相同的源。当故事达到高度准备状态时，团队合并到主干。由于缺少更改、意外更改和冲突，合并需要几天或几周的时间。我们谈论的是 5-10 人的团队，工作量/流失率似乎很高。
人们使用这种合并模式 a) PULL - 合并主干到分支、解析、测试、提交 b) PUSH - 合并分支到主干、解析、测试、提交 c) 重新创建分支（或者通常创建新的故事分支并在完成后删除旧的分支）
到此结束时，分支和主干应该对齐。
我们看到的问题：
- 在主干到分支合并期间未报告的更改会出现在 svn:mergeinfo 属性的后续分支到主干
- 冲突中，合并
- 文件丢失，但对添加的新文件进行本地编辑分支并推送到主干
- 传入+本地删除（主干和分支上删除的文件显示为冲突）
（1）不应该发生。从分支到主干的拉取应该使两者对于主干上已有的所有更改保持同步。分支到主干合并中的更改是在主干上发生的更改。因此，在第一次合并中，它们应该传播到分支，但没有。这表明合并信息数据损坏，这将“隐藏”主干更改。
(2) 不应该发生的情况。 SVN 应该管理合并跟踪中的更改。这也表明合并信息数据损坏
(3) 不应该发生。这是在分支上添加新文件的情况。它应该显示为添加到主干的新文件。这也表明合并信息数据已损坏。
(4) 我相信这是一个 SVN 错误，我们无法修复它。不过，如果这是我们唯一的问题，我会很高兴
我们目前在 svn 1.5.x 服务器上，客户端使用 svn 1.6.x 和 svn+ssh 进行连接。我们计划升级到最新、最好的 SVN，因为一些修复可能会影响我们的问题。
尽管如此，看起来我们的合并信息数据确实是错误的。
- 不报告所有更改的合并
- mergeinfo 属性合并中的冲突
我有什么好地方可以开始寻找吗？
I suspect I have corrupt mergeinfo but I'm not sure. Does anyone know how I'd make a determination and what resources are out there to help fix problems?
Here’s the issue. My team recently moved to agile and uses feature branches (story branches really) where different teams work on the same sources concurrently. As the story achieves a high state of readiness the team merges to trunk. The merges are taking days or weeks due to missing changes, unexpected changes, and conflicts. We are talking about teams of 5-10 people and the effort/churn seems way to high.
People use the this merge pattern
a) PULL - merge trunk-to-branch, resolve, test, commit
b) PUSH - merge branch-to-trunk, resolve, test, commit
c) Recreate branch (or usually create new story branch and drop old since it's done)
By the end of this the branch and trunk should be in alignment.
Problems we are seeing:
- changes not reported during trunk-to-branch merge show up in subsequent branch-to-trunk
- conflicts on svn:mergeinfo properties during merge
- file missing, but local edit on new file added in branch and pushed to trunk
- incoming + local delete (file deleted on trunk and branch shows as conflict)
(1) Should not be happening. The pull from branch to trunk should put the two in sync for all changes already on trunk. The changes in branch-to-trunk merge are changes that happened on the trunk. So in the first merge they should have propagated to branch but didn’t. This points to corruption in mergeinfo data which would “hide” trunk changes.
(2) Should not be happening. SVN should be managing the changes in the merge tracking. This also points to corruption in the mergeinfo data
(3) Should not be happening. This is a case of a new file added on branch. It should show up as a new file added to trunk. This also points to corruption in the merge info data.
(4) I believe this is a SVN bug and that we can’t fix this. Still if this were our only problem I'd be happy
We are currently on svn 1.5.x server with clients using svn 1.6.x and svn+ssh for connecting. We plan to go up to the latest and greatest SVN since some fixes may impact our problems.
Still, it sure looks like our mergeinfo data is wrong.
- Merges that don't report all changes
- Conflicts in merge of mergeinfo properties
Any good places for me to start looking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于类似的情况，我们遇到了类似的问题，并且基本上已经解决了。
主要的一点是：
如果您在创建分支后从主干合并到分支，则需要使用分支提交标记主干（使用 svn merge --record-only），否则当您尝试重新集成回主干时尝试将主干到分支的提交合并回主干。
这显然最终会恢复在稍后的 trunk->branch 提交后对 trunk 所做的更改，往往会导致大量冲突（特别是如果您在 trunk 中创建了新文件或目录，则发生树冲突）等。
因此，我们的过程是要么从不同步创建主干后将其合并到分支中（对于短期分支工作正常），或者执行以下操作：
我发现： http://www.collab.net/community/subversion/ articles/merge-info.html 在找出我们做错了什么时很有帮助。
We had similar issues due to similar circumstances and largely have solved them.
The major one is this:
If you are merging into your branch from trunk after the branch creation, you need to flag trunk with the branch commit (using svn merge --record-only), otherwise when you try to reintegrate back to trunk it tries to merge the commit of trunk to the branch back into trunk.
This obviously ends up reverting changes to trunk made after the later trunk->branch commit, tends to cause massive conflicts (especially tree conflicts if you created a new file or directory in trunk), etc.
So our process is to either never sync trunk into a branch after it's been created (works fine for short lived branches), or to do the following:
I found: http://www.collab.net/community/subversion/articles/merge-info.html helpful while working out what we were doing wrong.
我对 SVN 分支/合并做了一些实验，我发现在某些情况下合并不起作用 - 例如主干的更改被覆盖。因此，如果你继续使用 SVN 来实现功能分支，你将陷入痛苦的境地。
我用 git 做了类似的实验，但我还没有找到一种方法来获得错误的合并。如果团队/管理层可以接受迁移到 git，我强烈建议使用它。
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.