使用 Netbeans 进行 Subversion 和多个版本的良好实践

Question

我正在考虑使用 Netbeans 使用 Subversion，并想知道维护不同版本（分支）的代码是多么容易。

我们目前有 Sourcesafe，其代码的单一版本在 Netbeans 中维护。现在我们有更多的客户，因此我们需要维护不同版本的软件。

据我在 Subversion 中了解，您有一个主干文件夹，它是代码的主要/工作分支。然后，由于需要不同的版本，您将代码分支到分支下。因此，考虑未来的情况可能会使用以下层次结构：

product\trunk
product\branches\version 1.0.0.0
product\branches\version 1.0.0.1
product\branches\version 1.0.0.2
product\tags

在主干和每个版本（即版本 1.0.0.0、版本 1.0.0.1 和版本 1.0.0.2）下，您具有 Netbeans 项目的相同文件夹层次结构，即：

src
lib
test

其中 lib 包含项目使用的可能由第三方开发的 JAR 文件。 src 将包含应用程序使用的数十、数百、数千个源代码类。 test 有望包含等效源代码类的测试类。

nbproject 是 Netbeans 专门用于存储各种项目设置的文件夹。 当您编译应用程序时，Netbeans 通常会创建一个 dist 文件夹，该文件夹是一个已编译的 JAR 文件，并且它在 lib 文件夹中引用它所引用的 JAR 文件。

我有几个问题：

1. 是否有任何理由不将 nbproject、lib 和 dist 文件夹添加到版本控制中？

2. 在 Netbeans 中维护不同版本的代码时，是否必须为每个版本的源代码创建单独的 Netbeans 项目？所以基本上你会在 Netbeans 的项目视图中看到：

   • 产品后备箱
   • 产品版本 1.0.0.0
   • 产品版本 1.0.0.1
   • 产品版本 1.0.0.2
   • ...等等...
   • 产品版本 X.X.X.X

据我所见，Subversion 具有比 Sourcesafe 更好的合并功能以及许多其他更好的功能。它还与 Netbeans 集成，这是另一大优势。我已经创建了一个带有主干和单个分支版本的测试存储库，其中我将分支版本中的文件合并回主干，在同一文件中存在许多冲突。

Answer 1

通常避免在目录和文件名中使用空格，因为它提高了编写脚本的能力。虽然脚本不是一个直接的问题，但您不想关闭这样一个有用工具的大门（如果您将来需要它）。

所以试试这个

product/
product/trunk
product/branches/1.0.0
product/tags/1.0.0.1
product/tags/1.0.0.2
product/tags/1.0.0.3

通过从主干复制“创建” 1.0.0 分支。在稳定 1.0.0 分支的同时，为 1.0.1、1.1 或 2.0 工作可以在主干中继续，而不会破坏 1.0.0 分支

现在，当您准备好“发布”1.0.0 分支的副本时，您可以将其复制到“发布”编号不断增加的“标签”目录中。将其复制到“标签”后，您应该重新配置服务器以不允许对 1.0.0.1、1.0.0.2 等进行任何更新。否则您将无法获得所发布内容的有效快照。

这只是一种做事方式，也是一种非常流行的方式。也就是说，有很多变体，您可能会找到更适合您需求的改进。

Answer 2

备注

• 目录树布局和名称只是有条件的协议，即您可以使用 mainline/vesions/releases f.e 而不是trunk/branches/tags（合并/复制将适用于任何 URL）李>
• 分支通常在 WIP 中使用一些（长时间）时间，因此 - 为 每个构建 分离分支不是，大多数时候（我看到）“每个次要分支”策略

几个答案

1. nbproject 文件夹 - 我不知道其中存储了哪些数据，它对 3 方开发人员有多大用处，但 SCM 的常见规则是“仅对数据进行版本控制，这是必须在任何新地方从头开始工作”。如果 nbproject 仅包含您的特定设置或此工作场所特定的设置，它可以并且必须从存储库保存中排除
2. 可以，它只是更有用（因为 nbproject 的设置可能因版本而异，而且您不会在 repo 中存储每个版本 /branch?/ 的设置），但“味道可能不同” - 您必须测试并检测你的方式
3. 未询问，但已回答 - dist 文件夹也必须从版本控制中排除 - 根据源代码管理，构建的工件没有任何历史价值（并且可以对于任何重新编码的修订，总是很容易重新创建 - 请参阅关于“通用规则”的答案 N1）