项目配置文件的颠覆管理答案

【问题标题】：Subversion management of project configuration files项目配置文件的颠覆管理
【发布时间】：2010-12-02 12:29:27
【问题描述】：

使用 subversion (SVN) 管理需要单个配置文件的项目的最佳实践是什么，该配置文件具有针对不同环境的多个并发版本。

即

Project ABC 用于三种不同的环境，它们使用相同的代码，只是稍微修改了配置文件。和
Project ABC 也由多个开发人员开发，为每个开发人员使用稍微修改的配置文件。

我知道可以使用配置文件模板和 svn:ignore，但想知道是否有人可以描述这种方法的最佳实践和/或任何其他合适的替代方案。

提前致谢！

【问题讨论】：

标签： svn version-control configuration configuration-files configuration-management

【解决方案1】：

我不知道这是否是“最佳实践”，但这就是我处理这个问题的方式，而且效果很好。我有几个应用程序，每个应用程序都有一个用于生产、登台和开发环境的单独配置文件。这些配置被命名为 web.config、stage.config 和 dev.config。这三个都受版本控制。该应用程序需要并使用 web.config 来检索配置设置。作为巡航控制调用的 NANT 构建和部署脚本的一部分，根据部署到的环境，适当的配置被重命名为 web.config 并进行部署。

希望这会有所帮助。

【讨论】：

我支持这个。此外，如果配置文件（即几个 SQL 语句和几个应用程序设置）之间几乎没有差异，则可以使用该方法的轻微排列，将更改存储在构建脚本本身中，并使用 NAnt 的 xmlpoke 来更新到正确的连接字符串。然后，您可以在自己的存储库中构建脚本，并将生产密码与您的代码库分开。

【解决方案2】：

在源代码管理中保存多个文件可能很棘手。我们使用自制配置工具读取系统环境变量并从中读取匹配的配置文件，然后修改共享配置文件。我不能说这是一个很好的解决方案，但它确实有效。

【讨论】：

【解决方案3】：

多年来，以及许多不同的成功项目，我只是不对系统或开发人员特定的配置文件进行版本控制。有时它只是数据库访问信息，或者一些重要的路径或其他什么。将其缩小到尽可能少。不要因为不对这些信息进行版本控制而感到难过。在多个项目中，每 2 到 5 名开发人员都曾这样做过，并且从未对现实世界的项目造成混淆、问题或争论。

【讨论】：

【解决方案4】：

在我看来，将所有配置文件置于版本控制之下是没有用的。在我的一个项目中，我们有使用 cmake 为多个平台（来自同一个模板）创建的配置文件。我们团队中的每个开发人员都有自己定制的附加脚本来创建所需的配置。

【讨论】：

但是如果你从来没有在版本控制下提交任何配置文件，你如何同意哪个是默认的？你至少不需要一个默认的模板吗？