单个文件的mergeinfo总是被触及
我有几个文件似乎总是在通过常规合并工作周期执行的各种合并任务上设置新的 svn:mergeinfo 。
该文件已经几个月没有更改了，但是合并信息却不断被修改。我有一种感觉，合并信息在某个时刻变得混乱并且从未恢复。我不确定要寻找什么来破解合并信息并进行更正，或者只是将其全部删除并继续。
有什么建议吗？
I have a couple of files that always seem to be getting new svn:mergeinfo set on various merge tasks performed through the regular work cycle of merges.
The file has not changed in months, but the mergeinfo is persistently touched. I have a feeling that the mergeinfo got confused at some point and never recovered. I'm not sure what to look for to hack the mergeinfo and correct, or just delete it all and go forward.
Any tips?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议您删除文件上的所有合并信息并继续，假设您的合并信息在包含整个项目的目录（如“主干”）上是正确的。对于典型的合并场景，您永远不应该看到在文件上设置合并信息 - 它应该只在作为合并操作目标的目录（例如“主干”）上设置。
我的猜测是，在某一时刻，您（或您团队中的某人）意外地执行了合并，其中目标是这些文件中的一个或多个。该合并操作在这些文件上设置了合并信息，从那以后您就一直坚持使用它（每次进行合并时，svn 都会看到这一点，并更新合并信息，即使文件本身在合并中没有被修改）。我以前见过这种情况发生，最好的解决方案是删除文件上的合并信息。
如果您还没有，请确保您提供了 颠覆书的第 4 章——关于分支和合并——很好的通读，这样你就可以理解 svn 中合并所涉及的问题。
I recommend you delete any mergeinfo on files and go forward, assuming that your mergeinfo is correct on the directory (like "trunk") that contains your whole project. For typical merge scenarios, you should never see mergeinfo set on a file -- it should only be set on the directory that was the target of the merge operation (the "trunk", for example).
My guess is that at one point, you (or someone on your team) accidentally performed a merge where the target was one or more of these files. That merge operation set mergeinfo on those files, and you've been stuck with it since (svn will see that every time you do a merge, and update the merge info, even if the file itself was not modified in the merge). I have seen this happen before and the best solution is to just remove the mergeinfo on the files.
If you haven't already, make sure you give chapter 4 of the subversion book -- on branching and merging -- a good read-through so that you understand the gotchas involved with merging in svn.