我对 SVN 中的分支和合并有基本的了解。你分支，做任何事情，合并回主干。
你必须合并回主干吗？
我的场景：
我在 ASP.NET MVC2 中有一个小应用程序，使用 Linq to SQL。随着 MVC3 的推出，我要么将其升级到 MVC3，要么从头开始重做（使用 EF 4）。无论哪种情况，下一个“版本”都将与我现在拥有的非常不同。
我想知道我应该如何处理 SVN 部分。我应该把它作为当前存储库 (/svn/project/trunk/mvc3) 的一个分支放在 SVN 中，还是应该启动一个新的存储库 (/svn/project_mvc3/trunk)。
将其保存在同一个存储库中。源代码历史不尊重人类的“版本”（发布）。
一旦应用程序在其生命周期中达到例行维护期，通常会创建一个分支来维护稳定版本，并在主干中继续开发即将发布的版本。通常，每次发布公开版本时，都应该将自己设为一个分支。
如果您想保留当前拥有的内容，但将执行您想要继续使用的重大更改，我建议为您当前的项目创建一个分支并将您的新更改放入主干。例如 (/svn/project/branches/mvc2) 可以保存您当前的项目，并且 (/svn/project/trunk) 可以是 MVC3 向前发展。
这在很大程度上取决于您希望使用 Subversion 最终实现的目标。版本控制使您能够跟踪开发迭代之间的更改。在最基本的层面上，它使您能够回滚到代码的先前版本并有效地撤消更改。
听起来（如果我误解了，请道歉）您认为版本控制是您代码的存储介质，但它可能远不止于此。当多个用户对代码进行更改时，它最强大。分支部分地为您提供了该功能。
在回答您的问题时，如果您认为您的代码将从当前版本演变为新版本（尽管有重大的架构更改），那么版本控制将为您提供所需的功能。如果您要替换应用程序批发，那么我质疑版本控制系统中的跟踪历史是否是正确的解决方案。
如果应用程序的两个版本根本不同，则可以说它们不是同一个应用程序，尽管终点是相同的。如果他们有共同的代码并且会慢慢地变成一个不同的应用程序，那么版本控制将是一个可能的解决方案。
所以这个问题的答案可能是：“这取决于”。版本控制为您做什么？为什么首先将应用程序置于版本控制中？如果这些问题的答案仍然适用于新版本，并且至关重要的是，适用于应用程序从一个版本到下一个版本的演变，那么分支/合并可能是正确的解决方案。
顺便说一句，如果您是应用程序的唯一开发人员，那么除非您需要在分支进行期间维护主干，否则实际上不需要分支和合并。如果主干在某处生产并且您需要在开发分支时应用错误修复，则可能会出现这种情况。
A final (if a little tangential) point is that a branch and the trunk are basically just subfolders within Subversion. You can merge either way (trunk to branch, or branch to trunk).