开发中代码的多个实例的版本控制

Question

我在工程实验室工作，不是计算机科学实验室。因此，我们的内部软件不是可交付的产品。相反，内部软件用于分析工程问题，我们提供结果。

这使得版本控制成了一个人间地狱。或者我应该说，标准的“主干和分支”版本控制树结构似乎并不适用。我希望有人能提出一种更好的做事方法。

例如，每个工程项目都需要添加特定于案例的输入文件、运行时文件和后处理文件。这些文件都不属于主干，因为它们不是通用的，但每个新项目都需要这些文件。我们尝试将模板放在主干中，但没有明确的最佳实践来确定何时应该合并模板。

类似地，内部代码总是随着我们添加新功能而不断发展。其中许多应该合并到主干中，以便将来的应用程序可以使用。然而，也有相当多的特定于案例的黑客攻击，而主干不需要看到这些。

我们应该如何组织这种混乱？显然，越简单越好。

Answer 1

我们真的努力让我们的项目保持独立：

• 源文件(在您选择的任何VCS中进行管理，如SVN)
• configuration文件(特定于团队或环境)

分支是用于开发工作的，这些“输入文件、运行时文件和后处理文件”将按照自己的步调发展。

对于这种类型的文件，我们在VCS中管理的是：

• templates
• scripts能够获取该模板并生成(私有的，因为在未版本化的情况下)配置文件，其中包含正确的值。

这些值来自另一个引用，比如数据库，团队(或环境管理员)可以随意更新它们，而不需要关心签出/签入/合并。

然后，如果需要，可以在其自己的VCS中对该数据库进行版本控制(例如，请参阅此SO question，或者，作为替代方法，请参阅VCS

Answer 2

在工程中，版本控制经常被低估，而为了重复实验，恢复给定的设置是必不可少的。对于普遍采用，易于使用，主要是面向GUI的工具，帮助很大。

通过将问题与代码提交相关联的问题跟踪来利用版本控制，可以极大地提高生产力。

关于存储库结构，至少在subversion方面，只有约定，但没有工具强加的严格规则。如果有一个名为“主干”的树，其中所有的“公共代码”都是托管的。

对于每个工程任务，都会创建一个分支。它只不过是一个带有版本控制的“项目文件夹”。与其他项目相关的源代码将合并回主干。