将站点导入 SVN 存储库时应如何处理网站配置文件？
我开始对我们所有的网站使用 SVN 存储库，并想知道关于网站配置文件的最佳实践是什么。
它们应该存储在存储库中吗？问题是工作副本的网站配置需要与实时网站的配置不同。如果我编辑工作副本的配置文件，以便在提交回存储库时可以在我的计算机上进行测试，配置文件也将在那里更新，然后可能会上传到实时站点。
人们通常如何处理配置文件，有没有办法告诉 SVN 在执行提交等时跳过配置文件？
I'm starting to use SVN repositories for all of our websites and wanted to know what the best practise was regarding website config files.
Should they be stored in the repository? The problem is the configuration of the websites need to be different for the working copies than that of the live sites. If I edit the config file for a working copy so that I can test on my machine when I commit back to the repository the config file will be updated there too and could then potentially get uploaded to the live site.
What do people generally do with config files, is there a way to tell SVN to skip config files when performing commits etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一般来说，如果配置文件存储重要信息，最好将其放入版本控制中。
如果您在这里谈论 ASP.NET 站点，我肯定会将配置文件放在 SVN 中。您可以使用
inheritInChildApplications和allowOverride在 ASP.NET 配置文件中发挥一些技巧（请参阅如何：锁定 ASP.NET 配置设置），这可能允许您强制本地调试版本使用与最终生产版本不同的设置，尽管使用相同的配置文件：只需将网站安装为本地调试 IIS 中的子目录并锁定您想要覆盖的一些部分。当然，您可以只包含两个配置键来处理特别棘手的位，并签入要加载的代码。一般来说，最好的做法是让从 SVN 部署任何东西的过程涉及尽可能少的手动步骤。这使得您更有可能在时间压力下正确执行此操作，并且使灾难恢复更容易启动（例如，当您的数据中心发生泄漏并且您想要将网站安装在某个临时机器上，直到您获得这些备份已排序）。理想情况下，svn 签出或导出最多进行一次编译就足以让网站启动并运行。我什至直接在 svn 中包含二进制 dll 依赖项（例如 javascript 压缩器之类的东西），因此它无需在服务器上安装一堆自定义库即可运行，并且只需使用 msbuild 在开发计算机上进行编译。
对于PHP来说，原理是一样的。但是，您将需要不同的技巧。例如，您可以编写配置文件，以便它检查某些全局系统环境变量，然后覆盖选定的设置（如果它是开发机器）。例如，我有一个与此类似的设置，用于检查 IP 地址；所有开发机器都位于特定的 IP 块中；除非机器位于该 IP 块中，否则它被视为生产机器（不启用各种跟踪等选项）。您还可以检查主机名，或者只是所有开发人员同意在其开发计算机上设置的任何旧环境变量。
Generally, it's best to put config files into version control if they store significant information.
If you're talking ASP.NET sites here, I'd definitely place the config file in SVN. You can play a few tricks in ASP.NET config files using
inheritInChildApplicationsandallowOverride(see How to: Lock ASP.NET Configuration Settings) which may allow you to force a local debug version to use different settings from the final production version despite using the same config file: just mount the website as a sub-directory in the local debug IIS and lock a few sections you wish to override. And of course, you could just include two config keys for particularly tricky bits and check in code which to load.In general, it's good practice to make deploying anything from SVN a process involving as few manual steps as possible. That makes it more likely you'll do it correctly under time-pressure, and it makes disaster recovery easier to boot (say, when your datacenter springs a leak and you want to install the web site on some temporary box until you've got those backups sorted). Ideally, an svn checkout or export with at most a compile should suffice to get the web site up and running. I include even binary dll-dependencies directly in svn (stuff like javascript compressors and whatnot) so it'll run without requiring a bunch of custom library installs on the server, and compile on a dev machine with just msbuild.
For PHP, the principle is the same. However, you'll need different tricks. For instance, you might write the config file such that it checks some global system environment variable, and then overrides selected settings if it's a dev-machine. For instance, I've a setup similar to this where I check the IP address; all dev-machines are in a particular IP-block; unless a machine is in that IP block, it's considered a production machine (which doesn't enable various tracing etc. options). You could also check the host name, or simply any old environment variable which all developers agree to set on their development machines.
我认为最好将配置文件保存在 SVN 中。关于暂存/生产环境的设置，我们所做的是为每个环境提供单独的配置文件，然后在构建过程中交换它们（使用 Ant 和 MSBuild）。即我们可以触发“生产构建”，它将复制生产 web.config 文件。
I think its best to keep config files in SVN. Regarding settings for staging/production environment, what we do is to have seperate config files for each environment, and then swap them out as part of our build process (using Ant and MSBuild). I.e. we can trigger a "production build", which will copy the production web.config file.
我绝对会将该文件置于版本控制中，因为它通常对于网站的功能至关重要。要阻止它加载并运行，您可以查看构建脚本（例如 Web 部署项目），这会将您的配置的开发版本替换为“实时”版本。
抱歉，忽略该链接，刚刚看到您关于这是一个 PHP 网站的评论 - 但原理是相同的。
I would have the file in version control, absolutely, as it's generally pivotal to the function of the site. To stop it getting loaded to live, you could look at a build script (e.g. Web Deployment Project), which would switch out your development versions of the configuration with a 'live' version.
Sorry, ignore the link, just saw your comment about this being a PHP site - principle is the same however.
如果您的开发/实时环境之间的变量仅限于 connecionstrings 和 appsettings，那么您可以将 web.config 拆分为单独的文件，并为每个环境加载不同的文件。这样，您就可以将所有内容检查到 SVN 中，并根据您要部署到的环境更新 webconfig 中的文件名引用。
http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx
编辑：刚刚看到你正在谈论 PHP。
If the variables between your dev/live environments are limited to just connecionstrings and appsettings, then you can split your web.config into seperate files, and have a different file loaded in for each environment. That way, you can check everything into SVN and just update the filename reference in your webconfig depending on which environment you are deploying to.
http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx
Edit: Just seen you're talking about PHP.
一般来说，最佳实践是将所有自定义配置文件存储在版本控制下。您可能希望为生产和开发版本保留单独的配置文件。
如果可能，尝试将依赖于部署环境（连接字符串、路径等）的所有配置部分提取到单独的文件中。然后从主（通用）配置文件链接到它们，这样当您将环境从开发更改为生产时，只需更新参考即可。
In general the best-practice is to store all the custom configuration files under version control. You may want to keep a separate config file for the production and development versions.
If possible, try to extract all the config sections that depend on the deployment environment (connection strings, paths, etc) into separate files. Then link to them from the main (common) config file, so that it will be just a matter of updating the reference when you change your environment from development to production.