svn：用分支replace主干
使一个Subversion版本库的一个分支成为新的主干最好的办法是什么？
对整个系统进行了重大改写：事情已经被移动，重写，replace，删除，重命名等。重写的代码已经过testing，并准备replace旧的主干。
基本上，旧的主线（中继线5）被标记并将在此结束。 重写的分支（分支6）将成为新的主线（中继线7）：
中继线（1） - >中继线（2） - >中继线（5） - >×+ - >新中继线（7）
\ \ |
叉合并？
\ \ |
+ - >分支（3） - >分支（4） - >分支（6） - +
所有正在进行中的旧“Trunk”变化已经被纳入“改写的分支”
我怎样才能做到这一点？
使用svn move将旧的主干的内容移动到其他地方，然后将分支重命名为主干。
请注意，复制和移动svn像文件操作一样工作。 您可以使用它们在存储库中移动/复制东西，并且这些更改也是版本化的。 将“移动”看作“复制+删除”。
[编辑] nilbus刚刚通知我，你会得到合并冲突，当你使用svn move 。
我仍然认为这是正确的做法。 这会造成冲突，但是如果你仔细合并，很可能你不会丢失任何数据。 如果这样困扰你，请使用更好的VCS，如Mercurial或Git 。
我同意使用svn move命令来完成这个目标。
我知道这里的其他人认为它不寻常，但我喜欢这样做。 当我有一个function分支，并准备将它与一个也被大幅修改的主干合并时，我将它合并到一个新的分支，通常名为<FeatureBranchName>-Merged 。 然后我解决冲突并testing合并的代码。 一旦完成，我把主干移动到标签文件夹，所以我不会失去任何东西。 最后，我将我的<FeatureBranchName>-Merged到主干。
另外我更喜欢在做这些动作的时候避免工作副本，下面是命令的示例：
svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk
注：我使用1.5
最近我只是看着这个问题，而且我很满意的解决scheme是表演
svn merge –ignore-ancestry trunk-url branch-url
在我的箱子的工作拷贝上。
这不会尝试以历史的方式应用更改（保持主干中的更改）。 它只是“应用差异”之间的树干和分支机构。 这不会在未修改的文件中为您的用户造成任何冲突。 但是，您将从分支中丢失您的历史信息，但是当您进行合并时会发生这种情况。
build议您通过存储库浏览器工具进行这些更改。
尝试通过工作副本进行大量删除+移动操作是杀死工作副本的好方法。 如果您不得不使用工作副本，则在每次删除或移动操作后执行增量提交，并在每次提交后更新您的工作副本。
@Aaron Digulla和@kementeus解决scheme是可行的。 对于Subversion 1.4版本库，复制/移动操作可以使将来迁移到不同的版本库结构或分割版本库变得困难。
我相信1.5的改进包括移动/复制历史的更好的解决scheme，所以它可能不会是一个1.5版本库的问题。
对于1.4版本库，我build议使用svnadmin dump和svndumpfilter执行现有树干在其他地方的移动，然后用相同的机制将树枝移动到树干上。 将两个dumpfiles加载到testing存储库中，validation，然后将其转移到生产。
当然，在开始之前备份现有的存储库。
这保留了历史logging，而不明确logging移动/复制，并且使未来重新组织，保存历史更容易。
编辑：根据要求，从1.4红豆书， 过滤库历史logging 1.4行为的文档
另外，复制path可能会给你一些麻烦。 Subversion支持在存储库中的复制操作，通过复制一些已经存在的path来创build一个新的path。 有可能在版本库生命周期的某个时候，您可能已经从某个
svndumpfilter所在位置复制了一个文件或目录到它所包含的位置。 为了使转储数据自给自足，svndumpfilter仍然需要显示新增path（包括由副本创build的任何文件的内容），并且不会将该添加作为来自不存在的源的副本来表示在您的过滤的转储数据stream中。 但是因为Subversion版本库转储格式只显示每个修订版本发生了什么变化，所以复制源的内容可能不是现成的。 如果您怀疑在存储库中有这种types的副本，则可能需要重新考虑包含/排除path的集合，也可能包括用作麻烦复制操作源的path。
这适用于使用svndumpfilter迁移/重组。 有时候，稍加一点额外的工作可以节省大量额外的工作，并且通过简单地使用可用于未来迁移/重组的svndumpfilter ，以相对较低的成本减less风险。
如果你想使分支中的新主干（即）摆脱干线从分支创build以来所做的所有更改，可以1.创build主干分支（用于备份）2.“还原更改“在主干上（select分支创build后的所有修订版本）3.将分支合并回主干。
历史应该保持这种方式。
问候，罗杰
虽然上面的答案将起作用，但这不是最佳实践。 最新的svn服务器和客户端跟踪合并为您。 所以svn知道你已经将哪些版本合并到一个分支中，以及从哪里来。 当保持一个分支是最新的，然后把它合并回主干时，这会有很大帮助。
不pipe你使用的是哪一个版本的Subversion，都有一个最佳的实践方法来把一个分支的变化恢复到主干。 它在Subversion手册中进行了概述： 使用Subversion进行版本控制，第4章。分支和合并，保持分支同步 。
在SVN中这是一个非常奇怪的/不寻常的configuration，即使我认为它还远远不是一个“良好的实践”，无论如何，我想你可以做一些事情：
- 检出所有的源树（svn co therootsourcetree）
- 删除树干（svn rm trunk）
- 将分支复制到树干（svn cp branches / the branch / trunk）
- 删除分支（svn rm branches / thebranch）
- 提交更改
祝你好运
