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

Question

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

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

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

同样，随着我们添加新功能，内部代码也在不断发展。其中许多应该合并到主干中，以便它们可用于将来的应用程序。但是，还有一些特定于案例的黑客行为，主干不需要看。

我们应该如何组织这个烂摊子？显然，越简单越好。

Answer 1

我们真的试图将我们的项目分开：

• 源文件（在您选择的任何VCS中管理，如SVN）
• 配置文件（特定于团队或环境）

分支用于开发工作，那些“输入文件，运行时文件和后处理文件”将按照自己的进度发展。

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

• 的模板
• 脚本能够获取该模板并生成（私有的，非版本化的）配置文件，其中包含正确的值。
  这些值来自另一个参考，如数据库，团队（或环境管理员）可以随意更新它们，而不用担心结帐/签入/合并。
  然后，如果需要，可以在自己的VCS中对该数据库进行版本控制（例如，请参阅此SO question，或者作为替代，that one）

Answer 2

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

利用版本控制和问题与代码提交相关联的问题跟踪极大地提高了工作效率。

关于存储库结构，至少在查看subversion时，只有约定，但工具没有严格的规则。如果有一棵名为“trunk”的树，管理所有“公共代码”呢？

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