我在一个团队中工作，该团队使用SVN来维护我们网站的代码。该团队已经使用SVN几年了，但最近对SVN实践进行了大修，现在运行方式略有不同。
作为背景资料：
trunk已自动部署到生产中，这意味着它必须始终保持清洁。dev是大多数错误修正，小调整，小（1页）功能的地方 xxx-dev我们还有其他几个分支用于更广泛的功能开发，它们都被命名为xxx-dev，其中xxx是功能的名称。
每天都会从trunk - ＆gt;运行同步合并。所有其他分支。这有点单调乏味但让我们的分支与trunk中的内容保持同步，同时最大限度地减少我们在同步时必须解决的冲突数量。由不同的人每天将更改部署到主干，因此有必要使所有分支保持最新。我使用乌龟，我将修订范围框留空，以便所有未合并的修订版本合并到trunk的分支中。
最近，从较旧的分支机构部署出现问题（去年由于合并执行不当，跳过修订等，我们的合并历史中发生了各种不好的事情）。我无法确切地知道发生了什么，但我不能再将主干的合并同步到我们的分支机构。它试图重新合并一些已经合并的旧版本，并且没有这样做，如果我试图通过它就会给我带来各种错误。在此事件发生之前，我们已经遇到了许多问题，这些旧版本在合并过程中破坏了一些问题，我们继续删除分支并从主干中重新创建它们。但是，这可能会保留合并历史记录，我担心我们需要完全失去合并历史记录才能摆脱这些问题。
鉴于上述信息，我认为我们最好的做法是完全放弃所有合并历史记录，使用trunk代码的全新副本，通过复制新的{{1}来重新创建我们所有的分支。和我们一样，继续前进，但在我们开始进行日常同步之前没有任何糟糕的合并历史记录。
我的问题：要完成我所描述的内容，我们是否应该在整个trunk目录中递归删除svn：mergeinfo属性？这会导致任何问题吗？我相信，因为trunk位于存储库的根目录下，如果由于某种原因我们需要，我们仍然可以查看旧的合并历史记录。
如果我错了或我们的SVN政策有问题，请告诉我。
谢谢！
编辑：我应该提到我所看到的冲突恰好出现在trunk属性本身......所以有一个错误的合并正在修改svn:mergeinfo我不知道如何或者为什么团队中的任何人都会意外删除此目录的svn:mergeinfo属性，但这次导致所有问题的更改是删除的svn:mergeinfo属性。
此已删除的svn:mergeinfo位于子目录中，而不是分支的根目录。
答案 0 :(得分：2)
要做我刚才所描述的，我们是否应该在整个trunk目录上递归删除svn：mergeinfo属性？
是的，你可以这样做。你将失去所有的mergeinfo（当然），但之后，事情应该顺利进行，直到下次有人做某事时，＃34;幻想＆＃34; （比如做一个子树合并，这可能是各种问题的大门）。
这会导致任何问题吗？
好吧，如果你找到一种理智的方式来重新创建所有分支（基本上，你必须从干净的主干创建新的分支，并将原始分支中的所有变化合并到它们的替换中）。
但是，我认为至少还有两个选项需要考虑：
svn:mergeinfo属性。如果只是一组旧的合并（错误地）从主干合并到分支，为什么不用手修改trunk / branches中的mergeinfo属性（或使用--record-only标志让Subversion为你做这件事）？希望有所帮助。我对未来的建议：明确禁止在您的组中进行子树合并并进行提交审核（例如，至少有一个其他开发人员在合并之前查看分支中的更改）。可能更好的是使用git代替，虽然我知道这不是每个人的最佳选择（甚至是可行的选择）。
修改 回答问题中的编辑：如果你只遇到子树mergeinfo的问题，那么解决方案就更容易了：假设你的所有分支都是主干的副本（而不是子树分支），那就继续删除所有{{ 1}}存储库中所有子树的属性，包括trunk。
我们必须做同样的事情：基本上我们检查完整的存储库，手动（或脚本化）删除除了trunk和branch根之外的所有文件夹的svn:mergeinfo属性，然后再次提交。之后，没有更多问题：）