Svn 我的乌龟怎么了？

我在将生产版本（需要手动合并以解决与早期版本的冲突）合并回其来源的分支时遇到问题。合并未发现任何冲突，自动合并正在损坏合并的文件。有人能看出我做错了什么吗

以下是我工作的SVN设置：

• 主干是生产代码，它是自动部署到Web服务器的，永远不会有任何错误或问题

• “Dev”是一个分支，每个人都致力于一般错误修复和大多数小型开发

• 大型项目还有其他分支，如“项目1”

• 每天，主干（生产）都被合并到每个分支中，包括开发人员。这是因为我们不希望任何人在一个代码库中工作，这个代码库可能与我们的生产代码有任何不同，但他们在该分支中所做的更改除外

（我也欢迎对我们SVN结构/程序的批评。）

注意：这适用于没有并发维护版本的大型web应用程序，它只是全天候运行，我们不断地使用错误修复、新功能等对其进行修改/更新

我们以前每天都会遇到合并的问题，最近我们将SVN实践重组为我上面所描述的。在这之前，它似乎没有任何问题

当人们有经过充分测试并准备部署到生产环境中的更改时，他们会将这些修订从分支合并到生产环境中。这通常会导致在当天晚些时候将主干中的更改反向合并到分支中。我想这可能是问题的根源，但它在几周内一直运作顺利，直到今天

---

以下是我所经历情况的全部细节：

一个开发人员在Dev中工作，有几个修订版准备部署到生产环境（trunk），他们切换到trunk，打开合并对话框，选择他们的分支，选择他们计划部署的几个修订版，然后点击merge（使用默认设置）。假设没有冲突，它们通常会提交到trunk（trunk自动部署到web服务器并在几秒钟内上线）。在这种情况下，存在冲突。其他人以前在trunk中部署了一个修订版，该修订版修改了相同的文件之一。开发人员手动合并两个修订并测试该文件，确认其正常工作，并将合并的更改提交到trunk

在一天结束时，我将trunk合并回我们所有的分支，以确保明天每个人都有最新的代码，并尽早意识到任何冲突。为此，我一次切换到每个分支，打开merge，选择trunk，然后只选择今天提交合并的修订。我使用默认设置运行合并，并将合并的更改提交到分支中。在本例中，当我到达Dev分支并从主干合并时，我遇到了问题。今天主干中几乎所有的更改实际上都来自Dev分支，因此除了属性修改之外，没有其他更改，只有一个文件在开发人员试图部署它时发生了合并冲突。该文件自动合并。我打开文件查看它带来了什么，合并过程糟糕透顶。它复制了一些代码行（导致代码错误），并将其他代码行置于无序状态，等等

---

---

还应该注意的是，我们团队中的一些人在VisualStudio中使用AnkhSVN，而我和其他一些人只使用乌龟VN

在尝试部署更改之前，开发人员可能需要将主干合并到分支中。您说您每天手动执行一次，但应该在任何人尝试部署到主干之前执行，以便他们完全处于最新状态

根据我的经验，我发现在将任何分支合并到主干之前，最好先将主干合并到该分支，以解决冲突

我通常也不会永远在分支机构工作。我的团队通常会这样做：

创建主干的分支以处理特定任务

把工作交给分支机构

代码检查分支

修复代码复查中发现的任何问题，然后再次复查

根据需要重复3和4

将主干合并到分支中，以获得自分支以来的所有已完成工作，并解决冲突

最后，将分支重新整合到主干中

作为补充说明，我认为在Git中，您可以使用一个名为“rebase”的功能，它将完成您每晚所做的工作（将主干合并到每个人的分支中）。我认为它实际上对提交进行了重新排序，使之像您的分支在主干中的新提交之后实际分支一样。可能值得研究。

跟进@Travis“尽快合并回来”（+1来自我）

用于日常同步合并的GUI合并是个坏主意（tm）-“GUI无法自动化”

Cherry pick merges for merges

trunk->branch

是一个坏主意（tm）——因为它是纯同步合并（

svn帮助合并

1-st表单），必须以这种方式执行，并且只依赖mergeinfo（并且没有丢失记录的机会）

您（或“合并主机”）必须验证所有分支或至少DEV是否存在跳过的中继修订（

svn mergeinfo--show revs=qualified^/trunk^/DEV

必须为空）

如果您的SVN客户机仍然高于1.8版本，请升级并使用此版本：它不会消除所有合并地狱，但会使某些方面更容易

对于您的“合并舞蹈”开发，使用VCS和Merge作为一等公民（这对于Subversion来说仍然不是真的）将使生活变得更加轻松，同时显著减少头痛或普通操作：不再有“合并地狱”。在SVN背景下，迁移到Mercurial（notGit）几乎是不可能的