Svn 删除所有mergeinfo是在保留历史的同时重新开始的可行方法吗？

我在一个使用SVN维护我们网站代码的团队中工作。该团队已经使用SVN好几年了，但最近对SVN实践进行了彻底的改革，现在的操作方式略有不同

作为背景资料：

• trunk

  自动部署到生产环境中，这意味着它必须始终保持干净

• dev

  是解决大多数错误修复、小调整和小（1页）功能的地方

• xxx-dev

  我们还有其他几个分支用于更广泛的功能开发，它们都被命名为xxx-dev，其中xxx是功能的名称

• 每天，同步合并都会从

  主干运行

  ->所有其他分支。这有点乏味，但可以使我们的分支与

  trunk

  中的分支保持同步，同时最大限度地减少同步时必须解决的冲突数量。每天都有不同的人将更改部署到主干上，因此有必要使所有分支保持最新。我使用乌龟，并将修订范围框留空，以便将所有未合并的修订合并到来自

  主干的分支中
  

最近，来自旧分支的部署出现了问题（去年，由于执行了不正确的合并、跳过了修订等，我们的合并历史记录中发生了各种不好的事情）。我不知道到底发生了什么，但我无法再将合并从主干同步到分支。它试图重新合并一些已经合并的旧版本，但失败了，如果我试图通过它，它会给我各种各样的错误。在此事件之前，我们遇到了许多问题，这些旧版本在合并过程中破坏了东西，我们删除了分支并从主干中重新创建它们。然而，这可能会保留合并历史，我担心我们需要完全失去合并历史才能摆脱这些问题

考虑到上述信息，我认为我们最好的做法是完全删除所有合并历史记录，使用

trunk

中新的代码副本，通过复制新的

trunk

重新创建我们的所有分支，然后继续进行，但在我们开始进行每日同步之前没有任何错误的合并历史记录

我的问题：要执行我所描述的操作，我们是否应该对整个

主干

目录递归删除svn:mergeinfo属性？那会引起什么问题吗？我相信，由于

trunk

位于存储库的根目录下，如果出于某种原因需要，我们仍然能够查看旧的合并历史

如果我错了，或者我们的SVN政策有问题，也请告诉我

谢谢大家!

---

编辑：我应该提到我看到的冲突恰好发生在

svn:mergeinfo

属性本身上。。。因此，有一个错误的合并正在修改

svn:mergeinfo

我不知道团队中的任何人如何或为什么会意外删除此目录的

svn:mergeinfo

属性，但这次似乎导致所有问题的更改是一个已删除的

svn:mergeinfo

属性

此已删除的

svn:mergeinfo

位于子目录中，而不是分支的根目录

要执行我所描述的操作，我们是否应该在整个主干目录上递归删除svn:mergeinfo属性

是的，你能做到。您将丢失所有mergeinfo（当然），但之后，事情应该会顺利进行，直到下一次有人做一些“花哨”的事情（比如做子树合并，这可能是所有问题的入口）

那会引起什么问题吗

好吧，如果你找到一种合理的方法来重新创建所有分支（基本上，你必须从干净的主干创建新的分支，并手动将原始分支中的所有更改合并到它们的替换项中）

但是，我认为至少有两个选择，你也应该考虑：

手动修复

svn:mergeinfo

属性。如果只是一组旧合并（错误地）从主干合并到分支，为什么不手动修改主干/分支中的mergeinfo属性（或者使用

--record only

标志使Subversion为您执行此操作）

如果（1）不是一个选项，您应该查看是否所有分支都受到影响。如果没有，您只需要重新创建这些，与替换所有内容相比，可能会节省大量工作

希望有帮助。我对未来的建议是：明确禁止组中的子树合并，并进行提交审查（例如，在合并分支之前，至少让一名其他开发人员检查分支中的更改）。更好的方法可能是使用

git

，尽管我知道这对每个人来说都不是最好的选择（甚至不是可行的选择）

编辑 对于问题中的编辑：如果您只在子树mergeinfo方面有问题，那么解决方案就更简单了：假设您的所有分支都是主干的副本（而不是子树分支），只需继续删除存储库中所有子树（包括主干）的所有

svn:mergeinfo

属性

---

我们必须做一次完全相同的事情：基本上，我们签出了完整的存储库，手动（或编写脚本）删除除主干和分支根之外的所有文件夹的

svn:mergeinfo

属性，然后再次提交。之后，就没有问题了：）

我真的很想修复MergeInfo，但我不能100%确定它到底出了什么问题。我不相信我所做的更改以后不会导致奇怪的合并问题。错误地处理合并信息会不会导致以后的合并损坏文件或进行我们没有做的更改？我更新了我的que