当我应该为一些重大更改（Subversion，TortoiseSVN）创建一个分支时，我一直在 Trunk 工作答案

【问题标题】：I kept working in Trunk when I should have created a Branch for some major changes (Subversion, TortoiseSVN)当我应该为一些重大更改（Subversion，TortoiseSVN）创建一个分支时，我一直在 Trunk 工作
【发布时间】：2011-04-22 20:37:38
【问题描述】：

我着手进行了一系列涉及应用程序许多不同领域的重大更改，需要更改数据库架构、我们的对象和演示代码。我从 rev.1101 开始，您可以认为它是创建分支的完美案例，以便稍后在经过测试和完成后合并并集成回主干。

但我没有创建新的分支。我继续在 Trunk 上工作。

Trunk 现在是 rev.1116，我处于令人羡慕的 (?) 位置，我必须对大约 15 个版本前的版本执行一些错误修复，这是当前生产版本，然后发布错误修复的“rev. 1101+bugfixes" 到生产，没有任何 revs 1102-1116 的工作。

问题：我如何“恢复”主干并将所有最近的更改移动到分支？我是否从主干中的内容创建一个分支并变成 /Branches/MajorChangeSet，然后将 Trunk 恢复到 rev.1101，将其视为现在正式的 Trunk 并开始修复那里的错误？

更新：我遵循了下面 ChrisH 推荐的程序（根据上面的模型），我们现在状态很好。我们一直在继续更新“rev. 1102 产品”，包括修复和小功能增强。这些已经很容易合并到主干中，以确保这些更改也使其成为我们新的开发工作。谢谢大家！

Branch v. Trunk | Branch/Tag/Trunk? | Branch when?

【问题讨论】：

标签： svn tortoisesvn

【解决方案1】：

我建议您每次开始发布候选版本时都创建一个发布分支。 Trunk 在发布中未发布的内容（版本为 .next，正如我们所说的那样）保持活跃。发布分支仅保留用于错误修复和发布中必须包含的内容。最好总是先将它们提交到主干，然后将它们合并到发布分支。始终尝试将 FROM 主干合并到其他分支中，因为这样可以使事情变得更容易。将“功能分支”重新集成到主干中很好，但应避免在发布分支中修复错误然后将其合并回主干。

发布发布后，发布分支会保留以修复其他错误并最终进行次要发布。您仍然应该首先修复主干中的错误（没有必要在 .next 版本中发布它们）并将它们合并到您仍在积极维护的每个发布分支中。

好消息是您可以在事后开始使用这种方法。返回构建当前版本的主干的修订版，并从中创建一个发布分支。 TortoiseSVN 有一个方便的菜单，当您在日志查看器中右键单击修订时，可以从特定修订创建标签和分支。

一旦你有了你的发布分支，你需要检查它并开始合并你想要发布的错误修复。您在后备箱中的所有新工作都保留在原处。如果主干和发布分支有很大分歧，那么您可能需要直接在发布分支上进行修复，但尽量在主干中进行修复并尽可能合并到发布分支。

还有一件事。每次从发布分支发布发布时，您都应该复制到带有发布版本标签的标签。稍后可以方便地找出版本之间的更改或如果需要重新构建旧版本。我们会在发布版本时从标签进行完整的构建，因为我们在产品版本中嵌入了 SVN 修订号，这样如果客户报告错误，我们就可以准确地知道他们正在运行什么代码（因为 SVN 修订是唯一的跨存储库）。

希望有帮助，祝你好运。

【讨论】：

我很高兴它对你很有效，我喜欢用图表更新问题。图片比我贴的文字墙更容易理解。 :)
Houuuuuuuse 中的 Balsamiq 模型。
@MarkA：谢谢！我只是想知道您是如何绘制这些图表的：P 非常有用的图表！ :)

【解决方案2】：

一种方法是为每个主要版本创建一个分支，您可以在其上应用错误修复，而无需在主干中进行任何工作。

要追溯创建分支，请尝试：

svn copy http://svn/path/to/trunk@1101 \
         http://svn/path/to/branches/last_monday_release

@1101 是一个 peg 修订版 - 本质上我们是在说“找出修订版 1101 中提到的 trunk，然后复制它以创建一个分支”。

（SVN 书中有一个scary explanation 的钉修订版，如果你觉得勇敢的话）

【讨论】：

我阅读了挂钩修订的说明，谢谢您的建议。我认为这就是我创建的分支？我使用了 TortoiseSVN 的“显示日志”并从 r1101 创建了一个新分支。这比预期的要容易得多！
是的，Tortoise 几乎肯定在幕后做这件事。很高兴你把它整理好了，我也喜欢这些图表！

【解决方案3】：

嗯，不管你怎么看，它都有点混乱，但你也没有做任何明显的错误。您只是在您的主干中继续开发 - 这是正确的 - 但现在您需要返回到以前的版本并添加一些更改然后重新发布。

问题似乎是您对错误修复和新功能进行了一系列修订，而您只是试图从某个时间点开始处理错误而忽略其他所有内容。如果错误修复是在离散的修订版中进行的（至少出于识别目的）会更容易一些，但它们往往会伴随其他更改。

两种选择：

获取您发布的最后一个修订版本的一个分支，然后手动移动您的错误修复。
采用已修复错误的上一个版本的分支，然后删除新功能。

根据新功能和错误修复之间的平衡，其中一个可能会比另一个更容易。无论哪种方式，您都希望得到一个专门针对此版本的分支。

【讨论】：

【解决方案4】：

解决这个问题的一种方法是

从主干的 HEAD 创建一个工作分支
删除主干
从意外更改之前的主干修订版重新创建主干

这样您就不会在主干上的日志/责备中看到意外提交和恢复。但是在更新工作副本时要注意 - 我不确定svn update 处理存储库位置的删除和重新创建的效果如何。

【讨论】：

哎呀。我想在这些操作过程中会丢失很多日志历史记录？
@Mark 您不会丢失任何日志历史记录。 svn log trunk 只会显示额外的复制操作。并且您可以再次将意外更改更改为分支，而不会丢失任何历史记录。