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