Svn 删除颠覆分支

我被指派在Subversion中将几个分支合并回主干。目前，项目设置如下所示

trunk
branches
    BranchA
    BranchB
    BranchC
tags
    // A bunch of tags (1 per release)

目标是将

BranchA

和

BranchB

重新集成到主干中，然后以某种方式将它们“隐藏”

我想我知道如何进行真正的合并。右键单击Windows资源管理器中的主干，然后

合并…

然后

重新整合分支

，选择分支，然后合并

问题1-这是正确的使用方法吗

我也不确定这样做后存储库会是什么样子。我们希望确保未来的开发人员不会错误地使用旧的分支

问题2-合并后分支机构是否无法运作，或者我们是否需要做其他事情？你能“删除”一个分支吗？如果是这样，分支历史会发生什么变化？或者我们需要做一些骇客的事情，比如对分支应用锁

感谢您的帮助。

来自命令行（回答问题1）：

$cd$DEVROOT/trunk $svn合并http://company.org/svn/proj/branches/BranchA .... $svn ci-m“合并分支机构” $cd rm-m“分行已合并”http://company.org/svn/proj/branches/BranchA $svn合并http://company.org/svn/proj/branches/BranchB .... $svn ci-m“合并分支机构” $cd rm-m“分行已合并”http://company.org/svn/proj/branches/BranchB 将主干合并到分支和向后合并到主干不是SVN的有效用法。原因-请阅读：

我无法回答您的问题2，因为我不知道您的实际要求。。。我建议阅读官方指南：

并建议使用功能叶用于功能开发，使用分支叶用于长期版本支持，使用标签用于发布

不要建议删除任何分支。为什么？因为在SVN中删除不会使存储库变小。。。仅使svn ls输出更短

请看我的向导：

---

• 每个主要版本都有自己的分支
• 另一个为发展保留的分支
• 最新的主要放松分支处于活动状态。所有较旧的主要分支都是被动的
• 被动主要分支仅用于最新版本的次要错误修复 此主要版本系列的代码（无新功能）
• 在开发分支中开发的功能。在发布之前，合并为活动 主要发布分支
• 该错误已在最早的主要版本分支中修复，必须提供该分支 并合并到所有下一个主要版本分支和开发分支
• 发布意味着在分支和服务器上完成一组功能和bug修复 将产品构建移动到发布服务器
• 经过测试和稳定释放。这意味着：
  • 版本文件已更新
  • 更改文件中填写了功能集、版本、数据和VCS版本 号码
  • 在VCS中通过标签标记释放
  • 调用由标记标记的源的生成。将结果复制到发布服务器
• 若在某个版本中发现了bug，它将在开发分支和 与新的次要/修复产品版本一起发布

• 不支持以前的主要/次要版本（仅使用最新版本）。 用户总是被迫更新到最新版本

在这里，t-标记，b-分支：

+--+-----+----------------------+-----+----+------+------+-----> dev| | ^ ^ | | | | | | | | | | | v v v | | | | | | +--+------+------+--> | | | | | | b2 | | | | | | | | | v v v | | | | | | t2.0.0 t2.0.1 t2.1.0 v v | | v v t0.1.0 +---+------+-+---+-+-----+------+------+------+------+---> b1 | | | | | | | | v v v v v v v v t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3 +--+-----+----------------------+-----+----+------+------+-----> 发展| | ^ | | | || || | | | v v v | | | | | | +--+------+------+--> || | | | | b2 | || || | | | v v v || | | | t2.0.0 t2.0.1 t2.1.0 v v | | v v t0.1.0+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--> b1 | | | | | || v v v v v v v t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3 在本例中，我们发布了标签1.0.1和1.0.2，并在分支中修复了错误 1因为开发部门尚未准备好生产

问题1-这是正确的使用方法吗

是的，这将把分支的内容合并到您的工作目录中。在提交（新合并的）主干之前，存储库不会发生任何事情。一旦您提交，主干更改不仅将出现在repo中，而且它还将记住从分支中合并的内容

问题2-合并后该分支机构将无法运作，还是我们会 需要做点别的吗

此时，您可以删除分支，也可以继续对分支进行更改。如果继续对分支进行更改，然后再进行另一次合并，则只有新的内容（而不是以前合并的内容）将合并到主干中

---

如果您确实想删除该分支机构，我发现的最简单的方法是打开回购浏览器，右键单击该分支机构并选择“删除”。分支将从最新版本中消失。它仍将在回购历史记录中，如果需要，您可以将其带回，但进行新签出的人不会看到它。

如果您想删除旧分支，为什么不寻找Git/Mercurial与SVN的集成？如果删除分支，您将如何查看/获取历史记录？啊。打开repo浏览器时，只需将其更改回仍具有分支的修订。我想知道是否有一种方法可以看到所有曾经存在的分支？ +--+-----+----------------------+-----+----+------+------+-----> dev| | ^ ^ | | | | | | | | | | | v v v | | | | | | +--+------+------+--> | | | | | | b2 | | | | | | | | | v v v | | | | | | t2.0.0 t2.0.1 t2.1.0 v v | | v v t0.1.0 +---+------+-+---+-+-----+------+------+------+------+---> b1 | | | | | | | | v v v v v v v v t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3