Question

我已经阅读了SVN红豆书，并研究人们如何布置他们的SVN回购，我们正在考虑将SVN用于我们的产品，所以想要关于回购布局的建议。

该产品是一个桌面应用程序，由许多.exe，图形等组成。当前的源代码布局如下：

Program 1
Program 2
Program 3
Common Code
Graphics

值得注意的是，有时程序1也可能使用程序2中的源文件。所有程序都使用通用代码和图形。

主要问题是，如果我们的所有用户当前都使用该产品的版本2009，并且我们需要维护它，发布服务包等，并同时开始开发版本2010，则trunk应包含更改对于2009年发布，还是2010年发布？

trunk (where 2010 development happens)
  Program 1
  Program 2
  Program 3
  Common Code
  Graphics  
branches
  v2009
    Program 1
    Program 2
    Program 3
    Common Code
    Graphics 
tags
  2009 (read only)
  2009 SP1 (read only)
  2009 SP2 (read only)

以上是推荐的布局吗？或者主干应该包含2009年开发，以及2010年开发的某种测试分支？

上述布局确实意味着如果开发人员希望在计划1上工作，他们仍然需要签出整个项目，包括计划2，计划3。

编辑，更多问题

感谢对远方的回应。还有一个问题：

在开发过程中，将有4至6个月的版本，用户仍在使用2009版本，需要维护，而2010年的开发正在进行中。在此期间，将更改应用于2009年和2010年的最佳方式是什么？如果这些变化应该在2009年的分支机构完成，那么它们会移至2010年，反之亦然？

Answer 1

我喜欢你的布局。我认为随着岁月的流逝，行李箱应始终只是当年的发展。在每个新的一年的开始，你为前一年的持续开发创建一个分支，只是你认为合适的名称标签。

Answer 2

对于我在Subversion管理的每个项目，后备箱都拥有“开发”分支。每个版本都会获得一个标记（或分支，如果它最终得到进一步维护）。任何与devel分支相关的分支的更改都会根据需要合并。

Answer 3

最简单和最常见的方法是在后备箱中进行持续的新开发（2010），并在后备箱中进行维护（2009）。一旦你释放了主干，立即分支（2010分支）并在下一个版本（2011）开始工作。

在实践中，通常不那么简单。例如，您可能会在2010年甚至完成之前开始工作。还可能出现许多更复杂的情况。我建议将这本书Software Configuration Management Patterns作为管理分支机构的不同方法的一个很好的概述。

至于在哪里修补东西，我想你会发现其他人会为你决定（管理），但最简单的做法是将所有错误修复都放在发布分支中，然后合并到主干。这是因为与主干中的内容相比，错误修复可能相对较小。

无论如何，一旦你决定使用什么方案，记录它并与每个人分享知识。根据我的经验，由于工具的灵活性或缺乏经验，很多人很容易对分支策略感到困惑。你不希望别人对哪个分支工作感到困惑。

Answer 4

这对我有用。开发（新功能，错误修复）在主干中继续。当主要版本准备就绪时，会创建一个发布分支（例如v2009）。在发布分支中找到的错误首先被提交到发布分支，合并到第二个中继，并且最后合并到任何其他发布分支。

如果您发现已发布软件中的任何错误，那么发布分支的重点是有一个稳定的地方来应用错误修复。应始终可以使用发布分支来删除新版本。

因此，bug首先在它们被发现的任何版本分支中得到修复，然后在其他地方应用。这是基于客户发现错误的假设，并且尽快满足该客户至关重要。如果不是这种情况，我会考虑在提供最大收益的分支中进行修复。请记住，分支之间的合并并不总是微不足道的。可以进行主要的代码更改以消除错误，或者需要手动合并。

有时，在开发大型功能或重新设计大型基础架构时，我将从主干创建一个开发分支。任何合并到主干的东西都必须合并到开发分支。这使得最终合并更容易回到主干。

Answer 5

Trunk始终包含最新版本，但是您必须只有一个主干。我发现有用的布局是为每个应用程序设置不同的目录，然后在每个应用程序中使用主干/标签/分支。这样，您的版本控制具有更高的粒度，代价是必须更加小心代码之间的依赖关系。

Answer 6

如果您的开发主线是在2010年，那么后备箱似乎是适合它的地方。如果你计划从2010年的主干到2009年的分支机构合并，那么它似乎也很好。

假设您使用svn：externals用于公共代码和图形，养成将外部设置为特定修订版号的习惯，开始时要多做一些工作，但从中长期来看不那么痛苦。

Answer 7

您还可以使用trunk作为当前生产版本的参考。所有的开发都可以在特定的分支机构完成。

然后，您可以获得有关操作维护的源代码的始终可访问的参考。

另外，我建议如果您在发行版中有稳定的公共代码，请使用带有以下布局的svn：externals：

CommonCode:
  trunk
  branches
  tags

MyProduct
  trunk
    Dependencies -> CommonCode/trunk[rev. x]
  ...

您还可以考虑使用“发布”分支进行集成。

Answer 8

对于你在GIT上做得更好的事情，每个主要版本都要做一个分支。这样，如果主要版本中出现任何错误，您可以切换回分支，然后将您的GIT存储库中的不同提交映射到您的发布分支。

为我的项目推荐好的SVN布局

8 个答案: