对开发代码的多个实例进行版本控制
我在工程实验室工作，而不是计算机科学实验室。因此，我们的内部软件不是可交付的产品。相反，我们使用内部软件来分析工程问题，然后交付结果。
这使得版本控制成为一个活生生的地狱。或者也许我应该说标准的“主干和分支”版本控制树结构似乎并不适用。我希望有人能提出更好的做事方法。
例如，每个工程项目都需要添加特定于案例的输入文件、运行时文件和后处理文件。这些文件都不属于主干，因为它们不通用，但每个新项目都需要这些文件。我们尝试将模板放入主干中，但对于何时应合并模板没有明确的最佳实践。
同样，随着我们添加新功能，内部代码总是在不断发展。其中许多应该合并到主干中，以便它们可供将来的应用程序使用。然而，还有很多特定情况下的 hack 是 trunk 不需要看到的。
我们该如何整理这个烂摊子呢？显然，越简单越好。
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们确实尝试让我们的项目保持独立：
分支用于开发工作和那些“输入文件、运行时文件和后处理文件”将按照自己的节奏发展。
对于这种类型的文件，我们在 VCS 中管理的是：
这些值来自另一个引用，例如数据库，团队（或环境管理员）可以随意更新它们，而无需担心签出/签入/合并。
如果需要，该数据库可以在自己的 VCS 中进行版本控制（请参阅此 SO 问题 例如，或者作为替代，那个）
We really try for our projects to keep separate:
Branches are for development effort and those "input files, run-time files, and post-processing files" will evolve at their own pace.
For that kind of file, what we managed in a VCS are:
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)
在工程中，版本控制经常被低估，而恢复给定设置以重复实验至关重要。对于易于使用的普遍采用（主要是面向 GUI 的）来说，工具有很大帮助。
利用版本控制和问题跟踪将问题与代码提交相关联，可以极大地提高生产力。
关于存储库结构，至少在颠覆方面，只有约定，但工具没有强加严格的规则。拥有一棵名为“主干”的树怎么样，其中管理所有“通用代码”。
对于每项工程任务都会创建一个分支。这只不过是带有版本控制的“项目文件夹”。与其他项目相关的源代码将被合并回主干。
In engineering version control is often underestimated whereas it is essential to restore given settings in order to repeat experiments. For general adoption easy to use, mostly GUI oriented, tools help a lot.
Leveraging version control with issue tracking that relates issues to code commits increases productivity tremendously.
Concerning repository structure, at least looking at subversion, there are just conventions but no strict rules imposed by the tool. What about having a tree called 'trunk' where all 'common code' is managed.
For every engineering task there is a branch created. Which is nothing else than a 'project folder' with version control. Source code relevant to other projects will be merged back to trunk.