SVN:发布分支令人头疼，如何在清除上线时合并网站修订？

Question

如果可以的话，我需要在这里进行完整性检查，非常欢迎任何关于更正/更改以下内容的想法!我们最近一直在使用我们的 SVN，并试图通过放置一个中继/发布系统来纠正它。

我们有一个大型网站供我们开发，并将其全部存储在 SVN 中。这是我们想到的:

我们有主干和一个发布分支

所有工作都被 checkin Trunk。

当一个功能被认为为下一个版本做好准备时，它被合并到一个发布分支中。

我们只有一个发布分支，并且在推送上线时只标记“最新”

我们希望能够将所有文件从“最新”更改为“头”，以便为我们提供一个可以上传的 zip(任何关于通过脚本执行此操作的简单方法的想法？)

所以我们设置了这一切，并且对自己非常满意。除了它不工作和继承人为什么。

我们同时处理许多不同的功能/修复/问题，并且它们并没有很好地检查功能完整(但至少总是工作)。然后有时您必须等待客户签字。结果，您最终将“准备好上线”的修订与“仍在进行中”的修订分散在主干中。这意味着完成的修订不会按顺序合并，而是按顺序合并。我认为 SVN 可以处理这个，聪明的小东西，但显然不是。

这是一个例子:

Pete 更改了一些 CSS 以使新按钮看起来很漂亮(修订版 1)

Dave 为新功能(修订版 2)在与 Pete 相同的 CSS 文件的底部添加了一些 CSS

Dave 的 mod 得到了认可，因此他将其合并到 Release 中，并使用提及修订号和错误跟踪 ID 的日志消息提交。

Pete 添加了更多按钮来完成这个 mod，虽然这里没有 CSS 更改(修订版 3)

然后，Pete 将他的 mods(修订版 1 和 3)合并到发布负责人(其中有 Daves 合并)中，但这会覆盖 Daves CSS 添加，现在完全消失了。

这会导致站点被破坏并且 Release 分支几乎无用。

因此，我们尝试了一些其他想法，例如将 Release 恢复为“最新”，然后按顺序合并所有修订版 1、2 和 3。这一直很好，直到我们有了还没有准备好上线的第 4 版和已经准备好上线的第 5 版。突然间，我们再次陷入困境，遇到完全相同的问题!

好吧，拿三个。恢复到最新，合并到修订版 5，然后将任何更新返回到 Head。树冲突一应俱全!所以那是不，不。

我最终破解并手动构建了它，但这不是我想要经常做的事情，理想情况下我想编写我们的部署脚本，但不能在 Release 陷入如此困惑的情况下。

帮助!我们到底做错了什么？我似乎找不到任何解决方案来解决这个在 Release 中想要不同的非顺序修订的问题。如果它不可能，那很好，但我们到底是怎么想让东西轻松生活的。我们不能对每一个更改都进行分支，该站点需要 30 分钟以上的时间来检查它会花费太长时间。

旁注，我们正在使用 TortoiseSVN，所以我们可以在任何答案中将命令行示例保持在最低限度吗？

最新版本的 TSVN 和 SVN 1.6 版，所以我们有时髦的合并跟踪等。

编辑:一篇关于开发/发布周期的优秀博客文章(虽然使用 GIT 但仍然相关)认为如果每个人都发现这个问题很有趣，他们都想阅读它。 ( http://nvie.com/git-model )

编辑 2:我写了一篇博客文章，介绍如何在其他人问我的网站上显示您正在处理的分支( http://www.offroadcode.com/2010/5/14/which-svn-branch-are-you-working-on.aspx)。希望有帮助。与此同时，我们正在关注 Kiln 并希望在下个月进行转换(大口大口!)

Answer 1

What the heck are we doing wrong?

您正在一个分支上进行多项开发工作，并且这些工作不应同时进行(因为它们的生命周期不同，即它们不会同时发布)

您应该为每个开发工作(而不是每个开发人员)定义一个分支，并将这些分支合并到一个预发布分支中(以集成所有已批准的开发发布)，并在所有开发都一起验证后最终合并到发布。
如果每个开发人员的每个开发都是相当有序的，这意味着每个开发人员可以为每个常规任务保留一个工作区，并且只 check out 该组任务的相关工作区:实际更改的文件数量会很少，从而大大减少 check out 时间。

见:

purpose of branching

branches and SVN

merge workflow (以尽量减少合并期间的冲突)