用于开发代码的多个实例的版本控制 [英] Version control for multiple instances of a developing code

问题描述

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

I work in an engineering lab, not a computer science lab. As such, our in-house software is not the deliverable product. Instead, the in-house software is used to analyze engineering problems, and we deliver the results.

这使版本控制变成了一个活生生的地狱.也许我应该说标准的"trunk and branch"版本控制树结构似乎并不适用.我希望有人可以建议一种更好的做事方式.

This makes version control a living hell. Or perhaps I should just say that the standard "trunk and branch" version control tree structure doesn't seem to apply. I'm hoping someone can suggest a better way of doing things.

例如，每个工程项目都需要添加案例专用的输入文件，运行时文件和后处理文件.这些都不是真正属于主干的，因为它们不是通用的，但是每个新项目都需要这些文件.我们尝试将模板放到主干中，但是对于何时应该合并模板，尚无明确的最佳实践.

For example, each engineering project requires adding case specific input files, run-time files, and post-processing files. None of these really belong in trunk, because they aren't general, but each new project needs these files. We tried putting templates in trunk but there was no clear best practice as to when templates should be merged up.

类似地，随着我们添加新功能，内部代码始终在不断发展.其中许多应该合并到主干中，以便将来应用程序使用.但是，树干上也不需要看到很多针对特定案例的骇客.

Similarly, the in-house code is always evolving as we add new capabilities. Many of these should be merged into trunk so they will be available for future applications. However, there are also quite a few case-specific hacks which the trunk doesn't need to see.

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

How should we organize this mess? Obviously, the simpler the better.

推荐答案

我们真的试图使我们的项目保持独立:

We really try for our projects to keep separate:

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

分支用于开发工作，那些输入文件，运行时文件和后处理文件"将按照自己的步调发展.

Branches are for development effort and those "input files, run-time files, and post-processing files" will evolve at their own pace.

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

For that kind of file, what we managed in a VCS are:

• 模板
• 脚本能够获取该模板并生成其中包含正确值的(私有，如未版本控制)配置文件.
  这些值来自另一个参考，例如数据库，团队(或环境管理员)可以在其中随意更新它们，而不必担心结帐/签入/合并.
  然后，可以根据需要在自己的VCS中对该数据库进行版本控制(请参阅那个)

• templates
• scripts able to take that template and generate the (private, as in not versioned) config file with the right values in it.
  The values come from another referential, like a database, where the teams (or environment administrators) can update them at will, without any concern about checkout/check-in/merge.
  That database can then be versioned in its own VCS if needed (see this SO question for instance, or, as an alternative, that one)

这篇关于用于开发代码的多个实例的版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！