Subversion：每个环境的分支？

我目前正在开发一个.NET项目，其中包含多个逻辑层和多个前端。这里是我们的SVN结构的粗略表示：Subversion：每个环境的分支？

trunk 
---doc 
---lib 
---src 
------console 
---------console.vbproj 
------domain 
---------domain.vbproj 
------... 
------web 
---------web.vbproj 
---.sln

我们所有的一天到一天的发展，发生在躯干 - 这是所有开发人员都签/承诺。

我正在寻找一种干净而方便地部署环境（测试和生产）的方法。

我的想法是创建两个分支，测试和生产，从干线解决方案和所有。我证明这对我自己的原因如下：

我有过哪些修改流程完全控制其从主干只合并到测试分支，从测试分支到分公司生产环境
我可以通过简单地查看Subversion中相应分支的日志，可以轻松查看在每个环境中执行的代码。

有没有人有类似这样的解决方案的经验？我缺少任何潜在的陷阱或疏忽吗？

来源

2010-09-07 TMcManemy

为了防止任何人仍然好奇，有几篇关于这种方法的博客文章;只是谷歌“每次促销分支”。我相信大部分材料都只是Jeff Atwood在2007年10月初次发表的文章的回顾：[see here]（http://www.codinghorror.com/blog/2007/10/software-branching-and -parallel-universes.html） – TMcManemy 2011-02-25 16:00:06

有没有人有类似这样的解决方案的任何经验？

是:-)

是否有我失踪的任何潜在的缺陷或疏忽？

随着时间的推移，测试版本和发行版本将逐渐远离开发环境，因为您很可能不会合并来自干线的所有更改。然后，开发人员将在稍微不同的环境中工作，并通过保持分支同步来浪费大量时间。这就是所谓的merge-mania anti-pattern。

我宁愿建议从每个计划版本的trunk中创建一个版本分支，一旦您获得了实现的所有功能。当时你的分支都是平等的。然后有一个团队来稳定和测试发布分支。发展在主干上并行发展。一旦您的版本被打磨，将修复程序合并回主干。

对每个版本重复该过程。这样你就可以限制合并的数量，并让人们始终处于最前沿。

我希望这些方面能够帮助您做出决定。该链接还显示了许多其他反模式。阅读所有这些内容，也许你会认识到一些经验教训，并会得到一些提示，以更好地解决它。

来源

2010-09-07 21:53:27 jdehaan

使用“分支每版本”方法，您将如何去实现自动化部署？例如，使用“每个环境的分支”，我可以构建脚本，以便每个分支都被编译并部署到各自的环境中。然后，部署就像合并到我想要的分支并运行相应的脚本一样简单。 – TMcManemy 2010-09-08 12:48:07

也许我不明白你的意思是什么。通常如果有一个共同的核心，你会切换（或外部svn：外部）特定于环境的代码。所以不需要合并。如果您可以运行脚本来执行合并，那么在您的设置中一定会有一些概念错误。合并是一项无法自动完成的增值工作。如果可以实现自动化，则不会增加任何值，因此在您的情况下可能只是不必要的开销。 – jdehaan 2010-09-08 19:33:27

Upvote向我介绍“合并躁狂症”一词。这导致了许多反分支模式。谢谢jdehaan。 – granadaCoder 2012-09-21 23:17:04

我们使用相同的布局没有任何问题。确保使用最新的svn版本。不应使用1.5之前的版本，因为缺少合并跟踪。

与来自atlassian的jira等错误跟踪工具一起使用（我没有赞助），您的设置变得更加透明。

来源

2010-09-07 21:39:07 zellus

Subversion：每个环境的分支？

回答

相关问题