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 回答