我对SVN中的分支和合并有基本的把握。你分支，做任何事情，合并回主干。
你有合并回主干吗？
我的情景：
我在ASP.NET MVC2中有一个小应用程序，使用Linq to SQL。有了MVC3，我要么将它升级到MVC3，要么从头开始重做（使用EF 4）。在任何一种情况下，下一个“版本”将与我现在的版本大不相同。
我想知道我应该如何处理SVN部分。我应该把它作为当前存储库的分支（/ svn / project / trunk / mvc3）放在SVN中，还是应该启动一个新的存储库（/ svn / project_mvc3 / trunk）。
答案 0 :(得分：2)
将其保存在同一个存储库中。源代码历史不尊重人类的“版本”（发布）。
一旦应用程序在其生命周期中达到例行维护期，通常情况是为稳定版本的维护创建分支，并继续在trunk中开发即将发布的版本 / em>的。通常，每次进行公开发布时，都应该让自己成为一个分支。
答案 1 :(得分：1)
如果你想保留你现在拥有但你将要进行的重大改变，我会建议为你当前的项目创建一个分支，并将你的新变化放入主干。例如（/ svn / project / branches / mvc2）可以保存当前项目，（/ svn / project / trunk）可以是MVC3继续前进。
答案 2 :(得分：1)
这在很大程度上取决于你最终要用Subversion实现的目标。通过版本控制，您可以跟踪开发迭代之间的更改。在最基本的层面上，它使您能够回滚到以前版本的代码并有效地撤消更改。
听起来好像（如果我误解了道歉）您认为版本控制是代码的存储介质，但它可能远不止于此。当多个用户对代码进行更改时，它是最强大的。分支部分为您提供了这种功能。
在回答您的问题时，如果您认为您的代码将从其当前版本发展为新版本（尽管有重大架构更改），那么版本控制将为您提供所需的功能。如果您要更换批发应用程序，那么我会质疑版本控制系统中的跟踪历史记录是否是正确的解决方案。
如果应用程序的两个版本根本不同，那么可以说它们不是相同的应用程序，尽管终点是相同的。如果他们有共同的代码并且将慢慢转变为不同的应用程序，那么版本控制将是一种可能的解决方案。
所以问题的答案可能是：“这取决于”。版本控制为您做什么？为什么首先将应用程序置于版本控制中？如果这些问题的答案仍然适用于新版本，并且批判性地适用于从一个版本到下一个版本的应用程序的演变，那么分支/合并可能是正确的解决方案。
顺便说一句，如果您是该应用程序的唯一开发人员，那么除非您需要在分支正在进行的期间维护主干，否则实际上不需要分支和合并。如果主干在某个地方生产，并且您需要在开发分支时应用错误修复，则可能就是这种情况。
最终（如果有点切向）点是分支和主干基本上只是Subversion中的子文件夹。您可以合并任一方式（中继到分支，或分支到中继）。