Subversion 是在我们的服务器上更新我们的网络应用程序的好方法。使用简单的svn update，所有更改的文件都会...好吧，更改了。
除了诸如config.php 之类的无所不在的配置文件，它包含数据库访问配置、服务器路径等。因此在我的本地开发系统和远程服务器上是不同的。
使用update 命令，在服务器上修改的文件不会被覆盖，但是如果我在本地更改文件并提交它，服务器会得到错误的配置文件。
但我也不想设置svn:ignore 属性，因为配置文件属于项目。
是否有一个 Subversion 机制可以让我轻松处理这些文件？或者是解决这个问题的唯一方法是在配置文件中进行系统切换，这将确定执行系统并相应地设置配置？
【问题讨论】：
标签： svn version-control configuration
您还可以使您的配置文件域依赖。通过这种方式，您可以为本地机器和生产服务器创建配置。当然，您确实需要构建逻辑来处理这个问题。
如果您运行 apache 网络服务器，您可以轻松地将其配置为让每个开发人员在他们的本地机器上使用他们自己的（子）域，而不仅仅是使用 localhost。这样，每个开发人员都可以使用自己的配置。
【讨论】：
您可能需要考虑这样一个事实，即开发人员不会（也可能不应该）访问生产机器的用户名/密码。
为了解决这个问题，应将此类配置视为“部署细节”，而不是整体应用程序配置。 即使您做出这种概念上的区别，您仍然需要处理不同的部署环境，但是，由于您似乎正在处理 PHP，因此我无法评论您的具体情况。
正如 Lars 所述，一种可能的 J2EE 解决方案是将此类详细信息存储在 JNDI 下，使完全相同的应用程序二进制文件可部署在任何环境中，让 DBA/管理员为每台机器设置用户名/密码。
【讨论】：
我发现最简单的方法是打开机器的主机名。我有一个 .ini 文件，其中包含一个通用部分，该部分也覆盖了生产、测试和开发系统。
[general]
info=misc
db.password=secret
db.host=localhost
[production : general]
info=only on production system
db.password=secret1
[testing : general]
info=only on test system
db.password=secret2
[dev : general]
info=only on dev system
db.password=secret3
所以 dev:db.password == 'secret3'，但 dev:db.host == 'localhost'，来自原来的 'general' 组。
“production”、“testing”和“dev”可以是机器主机名，或者它们是配置控制脚本中其他机制设置的别名。
【讨论】：
一些可能的解决方案：
如果您使用的是 J2EE 应用服务器，您可以通过 JNDI 查找属性，有一些工具可以在服务器上轻松设置和查看它们。
你可以在你的 subversion 服务器中有一个默认的属性文件，但是在服务器上的其他地方（在项目中签入 svn 的部分之外）寻找真正的属性文件，但是你通常会得到依赖于操作系统的路径并且有当您在 svn 文件中添加新属性时，请记住手动更新真实属性文件。
您可以将属性文件中的属性设置为构建的一部分，并将参数传递给构建命令以告诉它要为哪个服务器环境构建。这可能会让人觉得有点迂回，您必须记住使用新属性更新构建脚本。但它可以很好地工作——如果你设置了一个持续集成服务器，它可以为所有不同的环境构建并为你测试包。然后你就知道你已经准备好部署了。
【讨论】：
在我目前从事的项目中，我们有 2 个用于数据库架构信息的属性文件 - 一个用于生产环境，一个用于开发。我们有一个类，它为正在执行的模块加载所有属性，并带有确定要加载哪个文件的逻辑。
由于我们本地的开发环境是 Windows 文件系统，而生产服务器在 UNIX 文件系统上运行，我们的解决方案是确定主机的操作系统并加载正确的文件。
我们将这些内容直接保存在我们的源代码管理中，以便保留所做更改的历史记录。我认为我们从（内部）客户对非常频繁的需求更改的指责中吸取了教训，因为我们需要能够保护过去对文件的任何更改。
这对于我们的情况可能是独一无二的，但我发现这非常有帮助，尤其是当我尝试从以前的版本复制测试运行时。
【讨论】：
为文件创建一个模板（例如 config.php-default）并让用户复制模板。她还可以进行比较，以查看版本之间发生了什么变化，以将这些变化合并到本地部署的文件版本中。
【讨论】：