svn:用branch替换trunk

时间:2008-12-01 16:43:55

标签: svn version-control

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

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

基本上,旧主线(Trunk 5)已被标记,并将在此处结束。重写的分支(分支6)将成为新的主线(Trunk 7):

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

旧“主干”的所有持续变化已经包含在“重写分支”

我该怎么做?

8 个答案:

答案 0 :(得分:116)

使用svn move将旧主干的内容移动到其他位置,然后将分支重命名为trunk。

请注意,在svn中复制和移动的工作方式与文件操作类似。您可以使用它们在存储库中移动/复制内容,并且这些更改也会进行版本控制。将“移动”想象为“复制+删除”。

[编辑] Nilbus刚刚通知我,当你使用svn move时会发生合并冲突。

我仍然认为这是正确的做法。它会引起冲突但如果你仔细合并,很可能你不会丢失任何数据。如果这让您感到困扰,请使用更好的VCS,例如MercurialGit

答案 1 :(得分:65)

我同意使用svn move命令来实现此目标。

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

答案 2 :(得分:12)

我最近只是在看这个问题,我非常满意的解决方案是

svn merge --ignore-ancestry trunk-url branch-url

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

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

答案 3 :(得分:8)

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

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

答案 4 :(得分:3)

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

我相信1.5的改进包括更好地解决移动/复制历史记录,所以它可能不会成为1.5存储库的问题。

对于1.4存储库,我建议使用svnadmin dumpsvndumpfilter在其他位置执行现有主干的移动,然后使用相同的机制将分支移动到主干。将两个dumpfile加载到测试存储库中,验证,然后将其移至生产。

当然,在开始之前备份现有的存储库。

这可以保留历史记录,而无需明确记录移动/复制,从而使未来的重新组织,保存历史变得更加容易。


编辑:根据要求,1.4行为的文档,来自1.4 Red-Bean书,Filtering Repository History

  

此外,复制的路径可以给你一些   麻烦。 Subversion支持复制   存储库中的操作,其中a   通过复制一些来创建新路径   已存在的路径。有可能的   在生命的某个阶段   您的存储库,您可能已复制   某个位置的文件或目录   那个svndumpfilter被排除在外   它包含的位置。在   为了生成转储数据   自给自足,svndumpfilter需要   仍然显示新的添加   路径 - 包括任何内容   由副本创建的文件而不是   代表该添加作为副本   你不会存在的来源   过滤转储数据流。但是因为   Subversion存储库转储格式   只显示每个内容的变化   修订,副本的内容   来源可能不容易获得。   如果你怀疑你有任何   你的这类副本   存储库,您可能想重新考虑一下   你的包含/排除路径集,   也许包括那些路径   作为你麻烦的来源   复制操作。

这适用于使用svndumpfilter的迁移/重组。有些时候,现在一些额外的工作可以节省大量的额外工作,并且通过轻松使用svndumpfilter可用于将来的迁移/重组,可以以相对较低的成本降低风险。

答案 5 :(得分:3)

如果你想让分支成为新的主干(即)去除自创建分支以来所做的主干中的所有更改,你可以 1.创建主干分支(用于备份) 2.在主干上“还原更改”(在创建分支后选择所有修订) 3.将分支合并回主干。

历史应该保持这种状态。

此致   罗杰

答案 6 :(得分:2)

虽然上述答案可行,但它们并非最佳做法。最新的svn服务器和客户端跟踪为您合并。所以svn知道你已经合并到一个分支中的哪些修订版本。这有助于保持分支最新,然后将其合并回主干。

无论您使用的是哪种版本的Subversion,都有一种最佳实践方法可以将分支中的更改恢复到主干。 Subversion手册中概述了它:Version Control with Subversion, Chapter 4. Branching and Merging, Keeping a Branch in Sync

答案 7 :(得分:-3)

在SVN中这是一个非常奇怪/不寻常的配置,即使我认为它根本不是一个“好习惯”,无论如何,我想你可以做类似的事情:

  • 查看所有sourcetree(svn co therootsourcetree)
  • 取下行李箱(svn rm行李箱)
  • 将分支复制到主干(svn cp branches / thebranch / trunk)
  • 删除分支(svn rm branches / thebranch)
  • 提交更改
祝你好运