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