项目配置文件的Subversion管理
使用 Subversion (SVN) 管理需要单个配置文件（该文件具有针对不同环境的多个并发版本）的项目的最佳实践是什么。
即
- 项目 ABC 用于三个不同的环境，它们使用相同的代码，除了配置文件略有修改之外。 AND
- 项目 ABC 也是由多个开发人员开发的，每个开发人员使用稍微修改的配置文件。
我知道可以使用配置文件模板和 svn:ignore，但想知道是否有人可以描述这种方法的最佳实践，和/或任何其他合适的替代方案。
提前致谢！
M。
What is best practice for using subversion (SVN) for managing a project that requires a single configuration file that has multiple concurrent versions for different environments.
I.e.
- Project ABC is used for three different environments, that use the same code, except for a slightly modified configuration file. AND
- Project ABC is also developed by multiple developers, using a slightly modified configuration file for each developer.
I am aware that a configuration file template and svn:ignore could be used, but was wondering if anyone could describe best practice for this approach, and/or any other suitable alternatives.
Thanks in advance!
M.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不知道这是否是“最佳实践”，但这就是我处理这个问题的方式，而且效果很好。我有几个应用程序，每个应用程序都有一个单独的配置文件用于其生产、登台和开发环境。这些配置名为 web.config、stage.config 和 dev.config。所有这三个都受到版本控制。该应用程序期望并使用 web.config 来检索配置设置。作为巡航控制调用的 NANT 构建和部署脚本的一部分，根据部署到的环境，适当的配置将重命名为 web.config 并进行部署。
希望这有帮助。
I don't know if this is a "best practice" but this is how I handle this and it works very well. I have several apps and they each have a separate config file for their production, staging and dev environments. The configs are named web.config, stage.config and dev.config. All three are kept under version control. The app expects and uses web.config to retrive configuration settings. As part of our NANT build and deployment scripts called by cruise control, depending on the environment being deployed to, the appropriate config is renamed to web.config and deployed.
Hope this helps.
将多个文件保存在源代码管理中可能很棘手。我们使用 homebrew 配置工具来读取系统环境变量，并从中读取匹配的配置文件，然后修改共享配置文件。我不能说这是一个很好的解决方案，但它确实有效。
Keeping multiple files in source control can be tricky. We use a home brew configuration tool that reads a system environment variable and from that reads a matching config file and then modifies a shared configuration file. I can't say it's a great solution, but it works.
多年来，在许多不同的成功项目中，我只是不对系统或开发人员特定的配置文件进行版本控制。有时它只是数据库访问信息，或者一些重要的路径等等。将范围缩小到尽可能少。不要因为没有对该信息进行版本控制而感到难过。这已经在多个项目中由 2 到 5 名开发人员完成，并且从未在现实项目中引起混乱、问题或争论。
For years, and many different, successful projects, I just don't version the system or developer specific config file. Sometimes it is just database access info, or a few vital paths or whatever. Narrow it down to as little as possible. Don't feel bad about not versioning that info. This has been done with every number between 2 and 5 developers on several projects and it has never caused confusion, problems or debate on real world projects.
在我看来，将所有配置文件置于版本控制之下是没有用的。在我的一个项目中，我们有使用 cmake 为多个平台创建的配置文件（来自同一模板）。我们团队中的每个开发人员都有自己定制的附加脚本来创建所需的配置。
In my opinion it is no use in keeping all configuartion files under version control. In one of my projects we had configuration files that were created with cmake for several platforms (from the same template). Every dev on our team had its own customized additional script to create the configs needed.