SVN: 发布分支的头疼问题，如何在网站修订被批准上线时进行合并？
SVN: 发布分支的头疼问题，如何在网站修订被批准上线时进行合并？
如果可以的话，我在这里需要一个理智的检查，对于纠正/更改以下内容的任何想法都非常欢迎！最近我们在使用SVN方面遇到了一些问题，我们正在尝试通过建立一个主干/发布系统来纠正这个问题。
我们有一个大型的网站，我们在其中进行开发，并将所有内容存储在SVN中。以下是我们的想法：
- 我们有一个主干和一个发布分支
- 所有的工作都会被检入到主干。
- 当一个功能被认为准备好进入下一个发布时，它会被合并到发布分支中。
- 我们只有一个发布分支，并且只在发布时标记为“最新”
- 我们希望能够得到从“最新”到“Head”的所有更改文件，以便我们可以生成一个zip文件进行上传（有没有关于如何通过脚本轻松实现这一点的想法？）
所以我们设置了所有这些，对自己感到非常满意。但是它并没有起作用，原因如下。
我们同时处理许多不同的功能/修复/问题，并且它们并不总是被完整地检入（但至少能正常工作）。然后有时你必须等待客户的签名。结果是，你会在主干中找到“准备上线”的修订版本与“仍在进行中”的修订版本混杂在一起。这意味着已完成的修订版本没有按顺序合并。我以为SVN可以处理这个问题，它是一个聪明的小东西，但显然不行。
这里有一个例子：
- Pete更改一些CSS使新按钮看起来漂亮（修订版本1）
- Dave在与Pete相同的CSS文件底部添加一些CSS代码，用于新功能（修订版本2）
- Dave的修改得到认可，因此他将其合并到发布分支并提交，提交时包含修订版本号和bug跟踪ID的日志消息。
- Pete在完成这个修改时添加了更多的按钮，但没有CSS更改（修订版本3）
- Pete然后将他的修改（修订版本1和3）合并到发布分支的Head中（其中包含Dave的合并），但这将覆盖掉Dave的CSS添加，导致其完全消失。
这导致网站崩溃，并且发布分支几乎没有用处。
因此，我们尝试了其他一些想法，比如将发布分支还原为“最新”，然后按顺序合并所有的修订版本1、2和3。这一切都很好，直到我们有了一个未准备上线的修订版本4和一个准备上线的修订版本5。突然间，我们再次陷入了同样的问题中！
好吧，那么第三次尝试。还原到最新版本，合并修订版本5，然后进行任何更新返回到Head。树冲突无数！所以这是不行的。
我最终妥协并手动构建了所有的内容，但这不是我想经常做的事情，理想情况下我希望能够脚本化我们的部署，但由于发布分支的混乱，我无法这样做。
救命啊！我们到底做错了什么？我似乎找不到解决这个问题的办法，即希望在发布中有不连续的修订版本。如果不可能的话那没关系，但我们应该如何轻松上线呢？我们不能为每个单独的变更创建一个分支，网站需要花费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，并希望下个月切换过去（gulp！）
问题的原因：
通常情况下，人们会在主干上开发，并在某个时间点决定发布，然后使用“release_something”命名进行分支。这不是一个持续不断地尽可能多地合并发布内容的过程，而是一个标记和冻结的过程。然后，在发布分支上完成的工作主要包括bug修复，尽快合并到主干上。使用这种流程，就会容易得多。
解决方法：
根据你想要实现的目标，似乎你是对的：最好的解决方案是为每个功能创建一个分支，然后一个接一个地将它们合并到主干中，也可以选择性地合并到发布分支中。Subversion似乎不是这种开发方式的最佳工具。如果你使用的是像hg或git这样的分布式版本控制系统，你可以为每个开发人员建立一个代码库，要求他们尽快将他们的变更集合合并/推送到主干中，以便测试尽可能多的集成功能并找到潜在问题。但你还会有另一个仓库，名为“release”，由一个人维护，他将有选择地从开发人员的仓库中拉取某些功能/补丁。例如，在我比较了解的hg中，当你拉取尚未合并的变更时（例如，从dev仓库到release仓库），会创建多个“heads”，即某种匿名分支，你可以逐个变更、逐个功能地决定是否将这些“heads”合并到主分支中。
我相信，由于这种灵活性，以及分布式版本控制工具能够更好地处理分支和合并，它会更适合满足你的需求。
希望能对你有所帮助。
文章整理如下：
通常情况下，人们会在主干上开发，并在某个时间点决定发布，然后使用“release_something”命名进行分支。这不是一个持续不断地尽可能多地合并发布内容的过程，而是一个标记和冻结的过程。然后，在发布分支上完成的工作主要包括bug修复，尽快合并到主干上。使用这种流程，就会容易得多。
根据你想要实现的目标，似乎你是对的：最好的解决方案是为每个功能创建一个分支，然后一个接一个地将它们合并到主干中，也可以选择性地合并到发布分支中。Subversion似乎不是这种开发方式的最佳工具。如果你使用的是像hg或git这样的分布式版本控制系统，你可以为每个开发人员建立一个代码库，要求他们尽快将他们的变更集合合并/推送到主干中，以便测试尽可能多的集成功能并找到潜在问题。但你还会有另一个仓库，名为“release”，由一个人维护，他将有选择地从开发人员的仓库中拉取某些功能/补丁。例如，在我比较了解的hg中，当你拉取尚未合并的变更时（例如，从dev仓库到release仓库），会创建多个“heads”，即某种匿名分支，你可以逐个变更、逐个功能地决定是否将这些“heads”合并到主分支中。
我相信，由于这种灵活性，以及分布式版本控制工具能够更好地处理分支和合并，它会更适合满足你的需求。
问题的出现原因：开发人员在同一个分支上进行多个开发任务，并且这些任务的生命周期不同，不能同时发布。过去的困扰是切换工作副本时容易混淆正在工作的分支。
解决方法：对于每个开发任务定义一个分支，而不是每个开发人员，然后将这些分支合并到预发布分支中（以整合所有已批准的开发任务），当所有开发任务一起验证通过后，再将其合并到发布分支。
为了解决对正在工作的分支的混淆问题，可以在Windows资源管理器的详细视图中添加一个列，以显示正在工作的文件夹的URL。可以使用SVN短URL来实现这一点。
还可以通过在标题栏中渲染出主干/分支/标签名称的方式来提醒自己正在工作的版本。只在本地主机上显示，所以可以安全地保留。
有人建议使用git结合SVN来简化合并操作，因为git的分支管理更加灵活。也有人推荐阅读《PragProg Source Control with GIT》这本书来学习如何使用git与SVN结合。