Subversion是更新服务器上Web应用程序的好方法。通过一个简单的svn update，所有更改过的文件都会得到...好了，更改了。

除了无处不在的配置文件(例如config.php)，其中包含数据库访问配置，服务器路径等，因此在我的本地开发系统和远程服务器上是不同的。

使用update命令，在服务器上修改的文件不会被覆盖，但是如果我在本地更改文件并提交，服务器将获得错误的配置文件。

但是我也不想设置svn：ignore属性，因为配置文件属于项目。

是否有Subversion机制可以让我轻松处理此类文件？还是解决此问题的唯一方法是在配置文件中进行系统切换，该文件将确定正在执行的系统并相应地设置配置？

解决方案

为该文件创建一个模板(例如config.php-default)，然后让用户复制该模板。她还可以进行比较以查看版本之间的更改，以将这些更改合并到文件的本地部署版本中。

在我目前正在从事的项目中，我们有2个属性文件用于数据库模式信息，一个用于生产环境，一个用于开发。我们有一个类，它为正在执行的模块加载所有属性，并具有确定要加载哪个文件的逻辑。

由于我们的开发环境在本地是Windows文件系统，生产服务器在UNIX文件系统上运行，因此我们的解决方案是确定主机的操作系统并加载正确的文件。

我们将这些直接保存在源代码控制中，以便保留所做任何更改的历史记录。我认为我们从(内部)客户指责中学到了有关频率要求异常变化的经验教训，因为我们需要能够捍卫文件的过去更改。

对于我们的情况，这可能是唯一的，但是我发现这非常有帮助，尤其是当我尝试从先前的版本复制测试运行时。

一些可能的解决方案：

如果我们使用的是J2EE应用服务器，则可以通过JNDI查找属性，有一些工具可以轻松地在服务器上进行设置和查看。

我们可以在Subversion服务器中拥有一个默认的属性文件，但是要在服务器上的其他位置(签入svn的项目部分之外)查找真实属性文件，但是通常我们会获得与OS相关的路径，并且必须记住在svn文件中添加新属性时，请手动更新实际属性文件。

我们可以在构建过程中的属性文件中设置属性，然后将参数传递给build命令以告诉它要针对哪个服务器环境进行构建。这可能会有点round回，我们必须记住要使用新属性更新构建脚本。但是，如果我们设置了Continuous Integration服务器，它可以很好地工作，它可以为所有不同的环境构建并为我们测试捆绑软件。然后，我们知道已经准备好进行一些部署。

我发现最简单的方法是打开计算机的主机名。我有一个.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'，来自原始的"通用"组。

"生产"，"测试"和"开发"可以是计算机主机名，也可以是它们的别名，这些别名是通过配置控制脚本中的其他机制设置的。

我们可能要考虑这样一个事实，开发人员将(也可能不应该)访问生产计算机的用户名/密码。

为了解决此问题，应将此类配置视为"部署详细信息"，而不是整体应用程序配置。
即使我们在概念上有所区别，我们仍然需要处理不同的部署环境，但是，由于我们似乎在处理PHP，因此我无法评论具体情况。

正如Lars所提到的，一种可能的J2EE解决方案是将这些详细信息存储在JNDI下，从而使完全相同的应用程序二进制文件可以部署在任何环境中，而DBA / Admins可以为每台机器设置用户名/密码。

我们还可以使配置文件域依赖。这样，我们可以为本地计算机和生产服务器创建配置。我们确实需要构建逻辑来处理此问题。

如果我们运行apache网络服务器，则可以轻松地将其配置为让每个开发人员在其本地机器上使用他们自己的(子)域，而不仅仅是使用本地主机。这样，每个开发人员都可以使用自己的配置。