发布版本时使用svn的最佳“工作实践”

时间:2012-05-19 15:28:25

标签: svn tags dependencies branch

我正在使用svn在我的工作中实施更好的“工作实践”。我们已经使用了svn几年了,但我们只是使用它,我认为它的容量是20%;我们将它用于源代码版本控制,但我们不使用标签或分支概念。

对于未来,我们希望能够在每次修订或发布后借助标记保留应用程序代码的快照。 Here is the article that helps me finding an orientation for the best strategyThis one also gives me some understanding但是给我留下了更多问题。

这是我想要遵循的模式:

  • 团队一直致力于Trunk。
  • 主干在每个版本以及每个版本都被标记,以便可以获得任何版本的快照。
  • 标记后,团队继续在主干上工作。
  • 如果团队想要尝试任何东西,他们会分支代码并在完成后将更改合并回主干。

问题是我们还有一个应用依赖的自制框架。在我们的上下文中,标记的帮助是能够纠正现有版本中的小错误,而无需将最新版本发送到客户端;主干中的版本。可以想象,框架与应用程序不在同一组文件夹中,因此,我认为创建与应用程序发布链接的框架代码的标签会非常难过。考虑到框架本身也可以在没有特定应用要求的情况下进行更改。

出于这个原因,我不知道哪个是创建标记的最佳策略,如果在应用程序的先前版本中发现框架中的错误,则减少了痛苦。目前,应用程序引用框架库,该框架位于每个应用程序解决方案的libs文件夹中。在这种情况下你会做什么?哦,我必须表明该框架有40万行代码。复制和过去的解决方案将被拒绝。 :)

如果我必须修复以前版本中的错误,我该如何使用标签?我知道每次我想要在标签结构中办理登机手续时,Subversion都会通知我。我必须创建一个带有标签的分支,更正错误,然后将修改合并/签入回标签文件夹,即使Subversion通知我了吗?

我的应用程序中也有依赖项,如DataDynamics.ActiveReportsMindscape.LightSpeed,它们也是Visual Studio中的依赖项,因为这些应用程序集成在IDE中。如果我必须更正使用以前版本的这些IDE插件的先前版本中的错误,我该如何处理?

最后,如果您能向我发送可帮助我对所有这些问题进行更深入解释的书籍或文章,我们将非常感激。

非常感谢你的时间。

1 个答案:

答案 0 :(得分:1)

嗯,框架是一个软件产品,框架的客户端是使用它的应用程序。所以框架应遵循与应用程序本身相同的规则。

所以这是场景。您发布了应用程序的A3.0版本。此版本使用框架的F2.4版本。框架的SVN存储库具有F2.4版本的标记。 SVN存储库具有A3.0版本的标记。

您的应用程序的客户端发现版本A3.0中的错误。您创建一个名为A3.0.1的新分支,您将在其中修复该错误。 framewok已经注意到了这个bug。因此,您在此分支中修复应用程序的代码,将修复程序合并到适用的主干,并在准备好后,进行发布并创建名为A3.0.1的标记。在分支和标记中,您仍然使用框架的版本F2.4。

客户端发现A3.0.1中的另一个错误。因此,您创建一个名为A3.0.2的新分支来修复此错误。经过调查,您意识到这是针对框架的。因此,您要求框架团队修复此错误,并为您提供版本F2.4.1。在框架团队中,他们创建了一个分支F2.4.1来修复bug。准备好后,他们会发布F2.4.1并为此版本创建一个标签。您在分支A3.0.2中包含F2.4.1,确保错误已修复(可能还需要在应用程序代码中进行一些更改),并在准备好后,释放版本A3.0.2并为其创建标记它。您的版本A3.0.2现在取决于框架F2.4.1。

关于VS插件,如果它们不向后兼容,我看不到任何其他解决方案而不是保留旧版本。但我不会依赖IDE,更不用说IDE的特定插件了,以创建和构建软件。 IDE应该是可以互换的,至少应该有一种独立于IDE的方法来构建软件。