题 svn:用branch替换trunk


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

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

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

中继线(1) - >中继线(2) - >中继线(5) - >×+  - >新中继线(7)
  \ \ |
  fork merge ???
    \ \ |
     +  - >分支(3) - >分支(4) - >分支(6) -  +

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

我怎样才能做到这一点?


149
2017-12-01 16:43


起源




答案:


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

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

[编辑] nilbus刚刚通知我你使用时会遇到合并冲突 svn move

我仍然认为这是正确的做法。它会引起冲突但如果你仔细合并,很可能你不会丢失任何数据。如果这困扰你,请使用更好的VCS 水银 要么 混帐


113
2017-12-01 16:47



如果这样做,那么在原始主干中更改工作副本的任何人都会发生冲突,即使他们的更改应该合并。这是因为文件被删除并重新添加 - 它们被视为具有单独历史记录的单独对象。 - Edward Anderson
@nilbus:你试过吗? IIRC,SVN显示文件已删除并重新读取但在内部,它将知道文件已被移动。 - Aaron Digulla
是。我查了两份。在第一个副本中,我将dir A移动到A2,dir B移动到A.然后将A移动到B,然后移动到A到A.(重命名并重命名。)在第二个检出中,我对文件进行了更改并尝试svn更新。它有冲突,因为我更改的文件“已被删除”。在内部,它不会保存文件的重复副本,但是当您遇到冲突时,您看到的删除确实会影响您。 - Edward Anderson
@nilbus:在这一点上,我想引用Linus Torvalds:“Subversion的口号有一段时间是”CVS做对了“,或类似的东西,如果你从那种口号开始,那么你无处可去去吧。没有办法做正确的CVS。“ - Aaron Digulla
是的。我同意。为了解决这个问题,我实际上用svn-git检查了repo,并使用git将分支重新绑定到master上。 - Edward Anderson


我同意使用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


64
2017-12-04 00:44



+1用于添加示例命令谢谢 - Aaron Williams
这可能不是最好的做法,但当你拥有一个非常古老的行李箱并且每个人都在一个分支上工作时,它肯定是最有效的,就好像它是行李箱一样。它解决了我的问题! - Alex Perrin


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

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

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

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


12
2017-07-21 22:41



发布svn 1.5你应该能够进行保存历史记录的合并。 - NSherwin


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

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


8
2017-12-01 17:19



链接到Repo会很方便(只是为了方便 - 保存谷歌搜索:)) - Brian M. Hunt
抱歉。拼写让我觉得我指的是一个特定的工具(已编辑)。实际上,大多数SVN GUI工具都应该具有存储库浏览器功能。仅供参考:我使用乌龟 tortoisesvn.tigris.org - Chris Nava


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

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

对于1.4存储库,我建议使用 svnadmin dump 和 svndumpfilter 在其他地方执行现有行李箱的移动,然后用相同的机构将分支移动到行李箱。将两个dumpfile加载到测试存储库中,进行验证,然后将其移至生产环境。

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

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


编辑:根据要求,1.4行为的文档,来自1.4 Red-Bean一书, 过滤存储库历史记录

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

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


3
2017-12-01 17:32



为什么“svn move”不够?你的建议似乎是用大锤挤压苍蝇。 - Rob Williams
我被这个1.4行为所困扰 - 如果SVN存储库包含目录或分支/标签的移动(重命名),使用svndumpfilter帮助重新组织/迁移存储库到新结构可能会失败,因为它无法处理历史记录好。据记载,我会挖掘裁判。如果你喜欢 - Ken Gentle
你能添加对这种行为的引用吗? - Jacco


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

历史应该保持这种方式。

问候,   罗杰


3
2017-08-04 13:06





虽然上面的答案可行,但它们并非最佳实践。最新的svn服务器和客户端跟踪为您合并。因此,svn知道您已将哪些修订合并到分支中以及从何处合并。这在保持分支最新并将其合并回主干时有很大帮助。

无论您使用哪种版本的Subversion,都有一种最佳实践方法,可以将分支中的更改恢复到主干。它在Subversion手册中概述: 使用Subversion进行版本控制,第4章。分支和合并,保持分支同步


2
2017-12-18 02:01



Thx官方信息,以便我可以通过官方approch合并分支到主干。关键字是 重返 - Junyo


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

  • 查看所有sourcetree(svn co therootsourcetree)
  • 卸下后备箱(svn rm trunk)
  • 将分支复制到trunk(svn cp branches / thebranch / trunk)
  • 删除分支(svn rm branches / thebranch)
  • 提交更改

祝你好运


-3
2017-12-01 16:49



这破坏了“svn move”将保留的历史痕迹。 - Rob Williams