1

我对 SVN 中的分支和合并有基本的了解。你分支，做任何事情，合并回主干。

你必须合并回主干吗？

我的场景：

我在 ASP.NET MVC2 中有一个小应用程序，使用 Linq to SQL。随着 MVC3 的推出，我要么将其升级到 MVC3，要么从头开始重做（使用 EF 4）。无论哪种情况，下一个“版本”都将与我现在拥有的非常不同。

我想知道我应该如何处理 SVN 部分。我应该把它作为当前存储库 (/svn/project/trunk/mvc3) 的一个分支放在 SVN 中，还是应该启动一个新的存储库 (/svn/project_mvc3/trunk)。

4

3 回答 3

2

将其保存在同一个存储库中。源代码历史不尊重人类的“版本”（发布）。

一旦应用程序在其生命周期中达到例行维护期，通常会创建一个分支来维护稳定版本，并在主干中继续开发即将发布的版本。通常，每次发布公开版本时，都应该将自己设为一个分支。

于 2011-02-09T20:59:01.840 回答
1

如果您想保留当前拥有的内容，但将执行您想要继续使用的重大更改，我建议为您当前的项目创建一个分支并将您的新更改放入主干。例如 (/svn/project/branches/mvc2) 可以保存您当前的项目，并且 (/svn/project/trunk) 可以是 MVC3 向前发展。

于 2011-02-09T21:00:09.290 回答
1

这在很大程度上取决于您希望使用 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).

于 2011-02-09T21:10:56.837 回答