项目配置文件的Subversion管理

Question

使用Subversion（SVN）管理需要多个并发版本的单个配置文件的项目的最佳实践是什么？

例如：

- 项目ABC用于三个不同的环境，使用相同的代码，除了略微修改的配置文件。 - 项目ABC还由多个开发人员开发，每个开发人员使用略微修改的配置文件。

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

谢谢！

- Morgan

Answer 1

我不知道这是否是一种“最佳实践”，但这是我处理此问题的方式，而且它非常有效。我有几个应用程序，它们各自都有一个单独的配置文件，用于生产、暂存和开发环境。这些配置文件分别命名为web.config、stage.config和dev.config，并全部保存在版本控制下。应用程序希望并使用web.config来检索配置设置。作为我们由Cruise Control调用的NANT构建和部署脚本的一部分，根据要部署到的环境，适当的配置文件将被重命名为web.config并进行部署。

希望这可以帮助你。

- Matt Wrock

---

我赞同这个观点。此外，如果配置文件之间的差异非常小（即几个SQL语句和几个应用程序设置），则可以对该方法进行轻微的排列，并将更改存储在构建脚本中，使用NAnt的xmlpoke更新到正确的连接字符串。然后，您可以将构建脚本保留在其自己的存储库中，并将生产密码与代码库分开。 - Michael La Voie

Answer 2

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

- csharptest.net

Answer 3

多年来，在许多不同的成功项目中，我只是不对系统或开发人员特定的配置文件进行版本控制。有时只是数据库访问信息，或一些关键路径或其他内容。将其尽可能地缩小。不要因为不对该信息进行版本控制而感到难受。这在几个项目中的2到5个开发人员之间都已经做过了，并且从未在现实世界的项目中引起混乱、问题或争议。

- Palo Verde

Answer 4

在我看来，将所有的配置文件都放入版本控制是没有意义的。在我们的某个项目中，我们有一些使用 cmake 在多个平台上创建的配置文件（源自同一个模板）。我们团队中的每位开发者都拥有自己定制的附加脚本来创建所需的配置。

- fmuecke

---

但是，如果您从未在版本控制下提交任何配置文件，那么您如何确定哪个是默认文件？难道您不需要一个默认文件作为模板吗？ - sivabudh