奇怪的树与SVN 1.7重新整合合并冲突

我最近加入了一个使用SVN 1.7.5的新团队，他们处理分支和合并的方式与我略有不同。我始终遵循以下模式：

干枝 根据需要将主干合并到分支 主干到分支的最终合并 -重新整合分支到主干的合并 删除分支 出于某种原因，他们确信，在初始副本之后，不应该将主干合并到分支。相反，它们只是在完成后将分支合并回主干，并在那里解决所有冲突。我不确定他们是进行常规合并还是重新合并。他们还做了一些奇怪的事情，将不相关的概念验证分支的内容直接合并到主干中，并且有多个主干。我不确定这是否是一个长期存在的分支，它放在主干旁边，而不是分支目录

我遇到的问题是，每当我以我通常认为是正确的方式处理分支和合并时，在重新集成功能分支时，我会遇到大量的树冲突。我现在举的一个例子是，有几个文件起源于一个概念验证分支，该分支被合并到主干中，随后又被合并到我的功能分支中。我还没有接触到这些文件，但重新整合给了我本地添加，一些但不是全部的文件在合并后会被添加

团队中的另一个人也决定尝试一下，并在重新整合之前将主干合并到他的功能分支。在他的例子中，他得到了大量的树冲突，其中一个是在一个直接添加到主干的文件上，并且从未在任何分支上修改过。他解决这个问题的方法是将他的分支卷回修订版，然后像其他人一样重新整合主干

---

我们的存储库中是否可能存在已损坏的内容？其他人正在使用的分支方案是否会导致SVN感到困惑？我能做些什么来修复出现的问题吗？

SVN 1.7在客户端和服务器上都使用吗？存储库是否已升级为当前格式？如果存储库是使用旧版本创建的，则必须使用svnadmin升级才能使用合并跟踪。主干中的子目录对svn:mergeinfo有不同的值吗？我还没有问过，但是如果有人使用的是1.7版本之前的客户端，我会感到震惊。这个存储库是几个月前创建的，所以我相信它一直都是1.7。然而，我认为这曾经在Git中出现过，有人认为他们更喜欢SVN。Git->SVN转换是否会产生错误的mergeinfo？我不知道如何判断trunk的子目录是否有不同的mergeinfo。如果我使用svn-propget-svn:mergeinfo^/trunk、svn-propget-svn:mergeinfo-R^/trunk，或者使用一个工作副本路径，我只会得到所有分支的相同列表，并且没有以trunk开头的分支。只需使用svn-propget-R-svn:mergeinfo^/即可。该命令应仅输出顶级分支和主干目录。如果它打印任何子目录，这可能是合并冲突的原因。我的处境几乎相同。据我所知，您的工作流也是正确的，我不记得以前遇到过这些树冲突，但在过去5年左右的时间里，我一直在使用git和hg。我知道，当本地操作和传入操作相同时，在本例中是add/add-on-merge，只需“resolve-accept-working”就相当安全了。我们还有一半的团队使用cmdline，另一半使用tortoise，所以我仍然在解决这个问题。如果我找到了来源，我会写一个答案。