我正在考虑使用Netbeans处理Subversion，并想知道维护不同版本（分支）的代码有多容易。
我们目前有一个Sourcesafe，它有一个在Netbeans中维护的代码版本。现在我们有更多的客户，因此我们需要维护不同版本的软件。
正如我在Subversion中所理解的，您有一个trunk文件夹，它是代码的主要/工作分支。然后，由于需要不同的版本，您可以在分支下对代码进行分支。因此，考虑到未来的情况，可以使用以下层次结构：
producttrunk
productbranchesversion 1.0.0.0
productbranchesversion 1.0.0.1
productbranchesversion 1.0.0.2
producttags
在trunk和每个版本（即版本1.0.0.0、版本1.0.0.1和版本1.0.0.2）下，您都有Netbeans项目的相同文件夹层次结构，即：
src
lib
test
其中lib包含项目使用的JAR文件，这些文件可能由第三方开发。src将包含应用程序使用的数十、数百、数千个源代码类。测试有望包含等效源代码类的测试类。
nbproject是Netbeans专门用来存储各种项目设置的文件夹。Netbeans通常在编译应用程序时创建一个dist文件夹，该应用程序是一个已编译的JAR文件，以及它在lib文件夹中引用的JAR文件。
我有几个问题：
- 是否有理由不将nbproject、lib和dist文件夹添加到版本控制中
在Netbeans中维护不同版本的代码时，是否必须为每个版本的源代码创建一个单独的Netbeans项目？因此，本质上，你会在Netbeans的项目视图中：
- 产品主干
- 产品版本1.0.0.0
- 产品版本1.0.0.1
- 产品版本1.0.0.2
- 。。。等等
- 产品版本X.X.X.X
据我所见，Subversion具有比Sourcesafe更好的合并功能和许多其他更好的功能。它还与Netbeans集成，这是另一大优势。我已经创建了一个带有trunk和单个分支版本的测试存储库，在该存储库中，我将分支版本中的文件合并回trunk，并且在同一文件中存在许多冲突。
通常避免在目录和文件名中使用空格，因为这提高了编写脚本的能力。虽然脚本编写不是一个直接的问题，但你不想关闭这样一个有用工具的大门（如果你将来需要的话）。
所以试试这个
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等进行任何更新。否则，您将无法获得发布内容的有效快照。
这只是一种做事的方式，也是一种很受欢迎的方式。也就是说，有很多变体，你可能会找到更适合你需求的改进。
票据
- 目录的树布局和名称只是有条件的协议，即您可以使用mainline/vesions/releases f.e而不是trunk/branches/标签（合并/复制将适用于任何URL）
- 分支通常会为WIP使用一些（长）时间，因此，并不是每次构建都为分离分支，大多数时候（我看到）都是"每个次要分支"策略
几个答案
- nbproject文件夹-我不知道其中存储了哪些数据，对三方开发人员来说有多少可用数据，但SCM的常见规则是"仅对数据进行版本控制，这是从任何新的地方开始处理项目的必须"。如果nbproject仅包含特定于您的设置或特定于此工作区的设置，则它可以而且必须从存储库保存中排除
- 你可以，它只是更可用（因为nbproject的设置可能因版本而异，并且你不会在repo中为每个版本/分支存储设置？/），但"品味可能不同"-你必须测试和检测
- 未询问，但已回答-dist文件夹也必须从版本控制中排除-根据源代码管理，构建的工件没有任何历史价值（并且总是可以很容易地为任何重新编码的修订重新创建-请参阅关于"通用规则"的答案N1）