SVN如何解决在两个分支上添加文件时的新树冲突
当合并几个分支（使用 SVN 1.6.1）时，两个分支上都添加了一个文件（然后在这些单独的分支中处理），我遇到了新的树冲突之一：
C foo.txt
> local obstruction, incoming add upon merge
我需要两个分支的更改，但树冲突并没有给我通常的 .working、.merge-left 和 .merge-left 。 .merge-right 文件——由于冲突的性质，这是可以理解的。 其中存在相当多的冲突，并且每个分支上都发生了相同文件的删除，但它们很容易解决。
我该如何解决这个问题？ SVN redbean 的书（1.6 版）没有涵盖这种情况。
When merging a couple of branches (using SVN 1.6.1) where a file has been added on both branches (and then worked on in those separate branches) I'm getting one of the new tree conflicts:
C foo.txt
> local obstruction, incoming add upon merge
I need the changes from both branches, but the tree conflict doesn't give me the usual .working, .merge-left & .merge-right files -- which is understandable due to the nature of the conflict. There are quite a few of these conflict, and ones where a delete of the same file has occurred on each branch, but they're simple to resolve.
How can I resolve this issue? The SVN redbean book (for 1.6) doesn't cover this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我发现帖子建议了一个解决方案。 即将运行：
这将声明本地版本文件正常。
您可以针对单个文件或整个项目目录运行它。
I found a post suggesting a solution for that. It's about to run:
which will claim the local version files as OK.
You can run it for single file or entire project catalogues.
正如 “树冲突”设计文档：
（顺便说一句，这在 ClearCase 中也称为“邪恶双胞胎”）：
一个文件在两个不同的分支中创建两次（此处“添加”两次），为两个不同的元素创建两个不同的历史记录，但名称相同。
理论上的解决方案是手动合并这些文件（使用外部 diff 工具）到目标分支“
B2”中。如果您仍在源分支上工作，理想的情况是从源分支
B1中删除该文件，然后从B2合并回B1 以使该文件在B1上可见（然后您将处理同一元素）。如果由于合并仅从
B1到B2发生而无法合并回，则每个B1->B2都需要手动合并> 合并。As was mentioned in an older version (2009) of the "Tree Conflict" design document:
(This is also called "evil twins" in ClearCase by the way):
a file is created twice (here "added" twice) in two different branches, creating two different histories for two different elements, but with the same name.
The theoretical solution is to manually merge those files (with an external diff tool) in the destination branch '
B2'.If you still are working on the source branch, the ideal scenario would be to remove that file from the source branch
B1, merge back fromB2toB1in order to make that file visible onB1(you will then work on the same element).If a merge back is not possible because merges only occurs from
B1toB2, then a manual merge will be necessary for eachB1->B2merges.svnresolve --acceptbase
svn resolve --accept base
我只是设法完全融入自己，尝试遵循上面 user619330 的建议。 情况是：（1）：我在我的初始分支branch1上工作时添加了一些文件； (2) 我创建了一个新分支，branch2 以便进一步开发，将其从主干分支出来，然后合并我对branch1 的更改 (3) 一位同事将我的 mods 从branch1复制到他自己的分支，添加了更多mods，然后合并回主干； (4) 我现在想将 trunk 中的最新更改合并到我当前的工作分支branch2 中。 这是 svn 1.6.17 的情况。
合并与新文件存在树冲突，我想要来自主干的新版本，因为它们不同，所以从branch2的干净副本中，我对冲突文件进行了svn删除，提交了这些branch2更改（从而创建了一个临时文件）没有相关文件的branch2版本），然后从主干进行合并。 我这样做是因为我希望历史记录与主干版本匹配，这样以后在尝试合并回主干时就不会遇到更多问题。 合并进展顺利，我得到了文件的主干版本，svn st 显示一切正常，然后我在尝试提交更改时遇到了更多树冲突，在我之前完成的删除和合并中的添加之间。 svn 是否解决了有利于我的工作副本（现在具有文件的主干版本）的冲突，并提交了它。 一切都应该很好，对吧？
嗯，不。 对branch2 的另一个副本的更新导致文件的旧版本（主干合并前）。 所以现在我有两个不同的branch2工作副本，据说更新到了相同的版本，有两个不同版本的文件，并且都坚持认为它们是完全最新的！ 签出branch2 的干净副本会导致文件的旧（主干之前）版本。 我手动将这些更新到主干版本并提交更改，返回到我的第一个工作副本（我最初从其中提交了主干更改），尝试更新它，现在在相关文件上出现校验和错误。 删除有问题的目录，通过更新获取新版本，最后我有了主干更改的分支2 的良好版本。 我希望。 警告开发商。
I just managed to wedge myself pretty thoroughly trying to follow user619330's advice above. The situation was: (1): I had added some files while working on my initial branch, branch1; (2) I created a new branch, branch2 for further development, branching it off from the trunk and then merging in my changes from branch1 (3) A co-worker had copied my mods from branch1 to his own branch, added further mods, and then merged back to the trunk; (4) I now wanted to merge the latest changes from trunk into my current working branch, branch2. This is with svn 1.6.17.
The merge had tree conflicts with the new files, and I wanted the new version from the trunk where they differed, so from a clean copy of branch2, I did an svn delete of the conflicting files, committed these branch2 changes (thus creating a temporary version of branch2 without the files in question), and then did my merge from the trunk. I did this because I wanted the history to match the trunk version so that I wouldn't have more problems later when trying to merge back to trunk. Merge went fine, I got the trunk version of the files, svn st shows all ok, and then I hit more tree conflicts while trying to commit the changes, between the delete I had done earlier and the add from the merge. Did an svn resolve of the conflicts in favor of my working copy (which now had the trunk version of the files), and got it to commit. All should be good, right?
Well, no. An update of another copy of branch2 resulted in the old version of the files (pre-trunk merge). So now I have two different working copies of branch2, supposedly updated to the same version, with two different versions of the files, and both insisting that they are fully up to date! Checking out a clean copy of branch2 resulted in the old (pre-trunk) version of the files. I manually update these to the trunk version and commit the changes, go back to my first working copy (from which I had submitted the trunk changes originally), try to update it, and now get a checksum error on the files in question. Blow the directory in question away, get a new version via update, and finally I have what should be a good version of branch2 with the trunk changes. I hope. Caveat developer.