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