我一直在将生产修订（需要手动合并以解决与早期版本的冲突）合并回到它所来自的分支中。合并没有发现任何冲突，自动合并正在破坏合并的文件。谁能看到我做错了什么？
以下是我工作的SVN设置：
Trunk是生产代码，它自动部署到网络服务器，不会出现任何错误或问题。
＆＃34;开发＆＃34;是一个分支，每个人都在处理一般错误修正和大多数小开发。
大型项目还有其他分支，例如＆＃34; project1＆＃34;。
每天，Trunk（生产）合并到每个分支，包括Dev。这是因为我们不希望任何人在代码库上工作，这些代码库可能与我们的生产代码有任何不同，除了他们在该分支中所做的更改。
（我也欢迎批评我们的SVN结构/程序。）
注意：这适用于没有并发维护版本的大型Web应用程序，它只是全天候运行，我们不断修改/更新它，包含错误修正，新功能等。
我们曾经遇到过每天合并的问题，并且最近将我们的SVN实践重组为我上面描述的内容。在这种情况发生之前，它似乎没有问题。
当人们拥有经过全面测试并准备部署到生产环境的变更时，他们会将这些修订版本从其分支机构合并到生产环境中。这通常会导致从干线到当天晚些时候来自分支的变化的反向合并。我认为这可能是问题所在的地方，但它已经流畅地工作了几个星期，直到今天。
以下是我遇到的情况的详细信息：
开发人员正在Dev工作并有几个版本，他们已准备好部署到生产（主干），他们切换到主干，打开合并对话框，选择他们的分支，樱桃选择他们的几个修订版本＆＃39;重新计划部署，并点击合并（使用默认设置）。假设没有冲突，他们通常会提交到trunk（它会自动部署到Web服务器并在几秒钟内上线）。在这种情况下，存在冲突。其他人之前已经部署了对trunk进行修改，修改了其中一个相同的文件。开发人员手动合并两个修订版并测试文件，确认文件正在运行，并将合并的更改提交到trunk。
在一天结束时，我将trunk合并回我们所有的分支机构，以确保明天每个人都拥有最新的代码，并尽快发现任何冲突。为此，我一次切换到每个分支，打开合并，选择主干，并选择今天提交的要修改的修订。我使用默认设置运行合并，并将合并的更改提交到分支。在这种情况下，当我到达Dev分支，并从trunk中合并时，我遇到了问题。今天几乎所有的trunk中的更改实际上来自Dev分支，因此除了在开发人员尝试部署它时具有合并冲突的那个文件时，除了属性修改之外什么都没有引入。该文件自动合并。我打开文件看看它带来了什么，合并是可怕的搞砸了。它复制了一些代码行（导致代码错误），并使其他代码无序，等等。
还应该注意的是，我们的一些团队在Visual Studio中使用AnkhSVN，而我和其他一些人只使用TortoiseSVN。
答案 0 :(得分：2)
在尝试部署更改之前，开发人员可能需要将trunk合并到其分支中。你说你每天手动执行一次，但它应该在任何人尝试部署到主干之前发生，这样它们就完全是最新的。
根据我的经验，我发现在将任何分支合并到主干之前，最好先将trunk合并到该分支，以便解决冲突。
我通常也不会永久地在分支机构工作。我的团队通常这样做：
作为旁注，我认为在Git中你可以使用一个名为“rebase”的功能来完成你每晚所做的工作（将主干合并到每个人的分支中）。我认为它实际上重新排序了提交，使得它像你的分支实际上在trunk中的新提交后分支。可能值得研究。
答案 1 :(得分：1)
@Travis的后续行动“尽快合并”（+1来自我）
trunk -> branch是 BAD IDEA（tm） - 因为它纯同步合并（svn help merge 1-st表单并且必须以这种方式执行并且仅依赖mergeinfo（并且没有机会错过记录）svn mergeinfo --show-revs=eligible ^/trunk ^/DEV必须为空）对于你的“Merge-dance”开发使用VCS并合并为一等公民（对于Subversion来说仍然不是这样）将使生活变得更容易，而且头痛或普通操作要少得多：不再“合并地狱” 。使用SVN后台，迁移到Mercurial（不 Git）几乎是透明的，工作流程的变化很小（在发布和部署阶段）