用分支替换树干

将 subversion 存储库的一个分支设置为新主干的最佳方法是什么?

对整个系统进行了重大的重写: 事物被移动、重写、替换、删除、重命名等等。重写的代码已经经过测试，可以替换旧的主干了。

基本上，旧的主线(Trunk 5)已经被标记并将在这里结束。重写后的分支(分支6)将成为新的主线(主干7) :

Trunk(1) --> Trunk(2) --> Trunk(5) --> ×          +--> new Trunk(7)
\                             \                 |
fork                         merge             ???
\                             \               |
+--> Branch(3) --> Branch(4) --> Branch(6) --+

所有正在进行的改变，从旧的“主干”已经纳入“重写分支”

我怎么能这么做？

91318 次浏览
小开
最佳答案

使用 移动将旧主干的内容移动到其他地方，然后将分支重命名为主干。

注意，在 svn 中复制和移动的工作方式与文件操作类似。您可以使用它们来移动/复制存储库中的内容，并且这些更改也是版本化的。把“移动”想象成“复制 + 删除”。

[编辑] Nilbus 刚刚通知我，当您使用 svn move时，会遇到合并冲突。

我仍然认为这是正确的方法。它会导致冲突，但是如果仔细合并，很可能不会丢失任何数据。如果这让你感到困扰，使用一个更好的 VCS，如 反复无常或 饭桶。

小开

在 SVN 中，这是一种非常奇怪/不寻常的配置，即使我认为它根本不是一种“好的实践”，不管怎样，我想您可以这样做:

  • 检查所有的源树(svn co therootsourcetree)
  • 移除主干(svnrm 主干)
  • 将分支复制到主干(svn cp 分支/分支/主干)
  • 删除分支(svn rm 分支/分支)
  • 提交更改

祝你好运

小开

建议您通过存储库浏览器工具进行这些更改。

尝试通过工作副本执行大的删除 + 移动操作是杀死工作副本的一个很好的方法。 如果您被迫使用工作副本，请在每次删除或移动操作之后执行增量提交，并在每次提交之后更新您的工作副本。

小开

@ Aaron Digulla 和@kementeus 的解决方案是可行的。对于 Subversion 1.4存储库，复制/移动操作会使将来迁移到不同的存储库结构或者拆分存储库变得困难。

我相信1.5的改进包括对移动/复制历史的更好解析，所以对于1.5版本的存储库来说，这可能不是问题。

对于1.4存储库，我建议使用 svnadmin dump和 svndumpfilter在其他地方执行现有主干的移动，然后使用相同的机制将分支移动到主干。将这两个转储文件加载到一个测试存储库中，进行验证，然后将其移动到生产环境中。

当然，在启动之前备份您现有的存储库。

这样可以在不显式记录移动/复制的情况下保存历史记录，并使得以后的重组、保存历史记录更加容易。

编辑: 按照要求，1.4行为的文档，摘自1.4 Red-Bean 手册 过滤存储库历史记录

此外，复制的路径可以为您提供一些 Subversion 支持复制 操作，其中 通过复制一些 已经存在的路径。这是可能的 在一生中的某个时刻 您的存储库，您可能已经复制了 某个位置的文件或目录 svndumpfilter不包括 所包括的位置 转储数据 自给自足，svndumpfilter需要 仍然显示新的 路径ー包括任何 复制所创建的文件ー而不是 将该加法表示为来自 一个不会存在于你的 过滤转储数据流。但是因为 Subversion 存储库转储格式 只能显示每个人身上发生的变化 修订、副本的内容 来源可能不容易获得。 如果你怀疑你有 在你的 你可能要重新考虑一下 您的一组包含/排除路径, 也许包括 成为你们麻烦的来源 还有复制操作。

这适用于使用 svndumpfilter的迁移/重组。有时候，现在的一点额外工作可以节省以后的大量额外工作，通过保持对 svndumpfilter的简单使用，以便将来的迁移/重组可以以相对较低的成本降低风险。

小开

我同意使用 svnmove 命令来实现这个目标。

我知道这里的其他人认为这不寻常，但我喜欢这样做。当我有了一个功能分支，并准备将它与一个主干合并，这个主干也被显著地修改了，我将把它合并到一个新的分支，通常命名为 <FeatureBranchName>-Merged。然后解决冲突并测试合并的代码。一旦完成，我移动主干到标签文件夹，这样我就不会丢失任何东西。最后，我把我的 <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

小开

虽然上面的答案会起作用，但它们不是最佳实践。最新的 svn 服务器和客户端跟踪为您合并。因此，svn 知道哪些修订已经合并到一个分支中，以及从哪里合并。当保持一个分支是最新的，然后将其合并回主干时，这非常有帮助。

然而，无论您使用哪个版本的 Subversion，都有一个将分支中的更改重新放回主干的最佳实践方法。它在 Subversion 手册中有所概述: 版本控制与颠覆，第4章。分支和合并，保持分支同步。

小开

我最近正在研究这个问题，我非常满意的解决方案是表演

Svn 合并——忽略-祖先躯干-url 分支-url

在我的行李箱的工作副本上。

这并不试图以历史方式应用更改(维护主干中的更改)。它只是在主干和分支之间“应用差异”。这不会在未修改的文件中为用户创建任何冲突。然而，您会从分支中丢失历史信息，但是当您执行合并时会发生这种情况。

小开

如果您想让分支成为新的主干(即) ，那么可以删除自创建分支以来在主干中所做的所有更改 1. 创建主干的一个分支(用于备份) 2. 主干上的“恢复更改”(选择分支创建后的所有修订 3. 将分支合并回主干。

历史应该是这样的。

问候, 收到


提交答案