我正在开发一个组合的网络/客户端应用程序，该应用程序具有用于生产、测试和开发的分支。我正在使用 svn post commit hooks 将更新部署到生产和测试服务器。客户端应用程序需要根据生产、测试或开发指向不同的 url。我如何使用颠覆来管理这个？我想到的选项是：
选项 1
保留一个包含分支特定详细信息的文件，该文件永远不会在分支之间合并。
从构建管理的角度来看，此选项更容易，但容易出错，因为我必须记住每次执行合并时都忽略该更改。
选项 2
无论是哪个分支，都可以创建客户端的生产、测试和开发版本，并依靠 svn 挂钩来拉取正确的二进制文件。
你如何处理这个问题？有更好的想法吗？
【问题讨论】：
标签： svn version-control branch configuration-management
我的偏好是不将项目特定的配置文件签入源代码管理，而是将环境变量和其他配置方面的内容保存在一个公共文件夹中（在源代码管理中）。然后根据给定项目、解决方案、环境在给定时间可能需要什么，生成配置文件作为本地构建、构建自动化或部署脚本的一部分。这可以通过简单的文本文件、xml 模板或更复杂的东西（如 spark 视图引擎）来完成，具体取决于您的需要。如果模板比您需要的更复杂（通常是这样），您也可以按照惯例执行此操作。这样，无论您在哪里部署代码，您都可以定义特定于环境的配置。
按照惯例的一个示例是在您的主要配置文件（Web 配置、应用程序配置等）中定义自定义配置部分。然后，您可以存储连接字符串-development.config、连接字符串-integration.config、连接字符串-testing.config、连接字符串-pre-production.config 和连接字符串-生产。在您的主要来源（或公用文件夹）中配置。然后，构建过程将删除适当的连接字符串配置文件，将其重命名为简单的 connection-strings.config。
通过模板生成，您还可以使用具有相同环境特定配置文件的自定义配置部分，但无需在部署时重命名，您只需使用适当的配置文件名直接重写基本配置文件的一部分。
保持您的配置文件按环境分块为您提供了很大的灵活性，尤其是当您开始管理许多使用相同或相似配置风格的站点时。无论如何，您的配置应该由您的自动化环境的某些方面决定！
【讨论】：
我们的应用程序为每个部署的环境保留一个单独的目录，其中包含配置文件。当构建服务器运行任务以针对特定环境进行部署时，它知道从哪个目录中提取配置文件。指向正确目录的指针是构建服务器（在我们的例子中是 Pulse）的构建定义的一部分。为那个 Pulse 任务构建代码的分支也是任务规范的一部分。这使得部署服务器的决策独立于分支，因此当我们发布新版本时，服务器和数据库可以重新调整用途。
+ dev-server
+---jdbc.properties
+---build.properties
+ test-server
+----jdbc.properties
+---build.properties
配置文件不与应用程序的其余部分（主干、分支等的同级）分支。它们在 svn 树中有自己的位置，并以 Subversion external definition 的形式被拉入每个分支。
我们这样做是因为每个分支都可能部署了许多服务器（开发、测试、构建、自动化等）。
【讨论】：