logo标签列表

半可编辑文件（例如配置文件）和版本控制 - 最佳实践？

svnversion-controlcvs
5
所以，今天我通过提交一个配置文件来破坏了构建。它知道服务器在哪里（类似于SQL服务器等），而我一直在我的电脑上运行的服务器上进行开发。通常情况下，或者说在其他情况下，我们会针对中央服务器运行。当然，日常构建没有找到“我的”服务器，因此出现了故障。但是，在提交之前将编辑配置文件指向“正常”的服务器，并在提交后再次编辑它非常乏味。
我一直想让VC忽略配置文件，以免意外检查它。另一方面，存储库应该包含一个干净、可用的文件版本。我不可能忽视它并同时将其检查进去，对吧？
因此，我正在寻找一种方式来拥有一个文件，即，它可以被签出，但永远不会被签入。至少在最常见的情况下是这样-如果配置文件发生重大变化，则某些特殊程序可将新版本放入存储库中。
如果您们遇到过这个问题，我会对您发现的任何解决方案感兴趣。只要它们不破坏构建就好了;)
8个回答
12
你可以创建一个默认的配置文件，除非添加了新的配置，否则保持不变。然后你可以创建一个不同的文件来覆盖默认文件的配置。
config.Default.xml
config.User.xml

只有config.Default.xml受源代码控制。config.User.xml仅包含您不同的配置。例如，如果您正在本地SQL服务器上进行测试，则只需在其中放置连接字符串即可覆盖config.Default连接字符串。

查看一下.NET Framework应用程序配置，它可以为您完成大部分（如果不是全部）工作。

我赞同这个观点。我们有两个文件（称之为Default.xml和Custom.xml）。这两个文件都可以包含相同的设置，但应用程序始终首先检查Custom.xml中的任何设置，然后再使用Default.xml作为默认值）然后我们的构建只包含Default.xml，并且您将Custom.xml保留在本地。 - Mike Marshall
很想将这标记为“最佳答案”，因为覆盖的东西很棒。并不是其他答案不好，相反地很好。 - doppelfish
3

我使用的一个方法是拥有两个版本的配置文件，并让安装脚本拉取正确的版本。

  • settings.xml
  • settings.xml-Release

这两个文件包含相同的键，但一个包含“dev”值，另一个包含我们预计部署和在现场编辑的值。

当然，这仍然存在一个问题，即某些东西可以与一个文件一起工作，但不能与另一个文件一起工作。 - Joe Soul-bringer
我们已经在多个实例中使其工作，但我承认我更喜欢Coincoin的答案。 ;) - JMD
2
我们有以下文件：
  • *.(config | xml)
  • *.(config | xml).cert
  • *.(config | xml).production
Hudson会删除初始文件并将正确的文件部署到正确的环境中（目前只有证书）。这样，开发人员就可以独立地记录和开发生产、证书和开发级别的配置文件，并在SVN中单独进行版本控制。
1

我们将这些类型的文件存储在源代码控制系统中，并为我们正在构建的环境设置不同的文件夹。

因此，我们有：

Dev
Test
Live

这些文件夹下还有其他环境特定的文件。

1

我认为这个被接受的答案很好，但根据您的要求，它可能有一些限制。

我们采用以下方法。请注意，我们是一个使用VS的.NET商店，并利用MSBuild（内置的、社区和自定义）任务。

  • App.config被版本控制忽略，但包含在项目中。
  • App.default.config被版本控制包含在项目中。我们使用标记代替硬编码的东西，例如数据库连接字符串等可能会改变的内容。

项目的BeforeBuild任务查找App.config是否存在，如果不存在，则将App.default.config复制到App.config。此外，构建服务器总是在CI构建时删除App.config（确保清洁配置）。然后，我们还使用MSBuild Community FileUpdate任务根据构建项目的内容替换标记为适当的值。

例如，新开发人员的检出可以为本地数据库设置db连接字符串，夜间构建可以为夜间db设置，等等。

0
接受的答案很好。然而，如果你的版本控制系统有更改列表的概念，那么可以实现你想要的（四年前）并仅保留一个检出但从不提交的配置文件。我在Perforce中已经这样做了：
检出配置文件并将其保留在自己的更改列表中。当您提交时，只提交其他更改列表；如果您将配置文件更改列表命名为“不提交”，则很容易记住。
这个系统的一个优点是，如果其他人更改了配置文件的生产版本（即存在于服务器上，每个人都在维护修改后的本地版本），那么当您从服务器获取配置文件时，您将收到可能冲突的通知。使用接受答案中建议的解决方案，您可能会保持用本地设置默默覆盖新的生产设置，这可能会破坏您的本地构建，或者导致您在下次提交时破坏构建。
0
在我工作的地方，我们为部署使用单独的配置文件。因此，我们解决方案中的配置文件是开发版本，人们可以随心所欲地更改它们。这些配置文件永远不会被部署到任何地方。
部署的配置文件存储在我们源代码控制提供程序的另一个位置。如果有人需要进行将要部署的配置更改，则必须修改此版本。
-1
对于每个配置文件x，创建一个名为x.dist的文件进行签入，这是默认的分布式配置。在开发人员签出后，有一个脚本将每个x.dist文件复制到x中，他们可以根据需要自定义x。此脚本可重新运行以在重大更改后更新文件，或者开发人员可以手动合并其更改。
对于部署，您可以签入您的实时部署文件，并使您的启动脚本明确引用它们（例如--config x.production）。
例如，在WordPress的分发中使用了这种方法（必须复制模板wp-config.php文件），或者在使用autoconf的开发项目中（其中configure.ac已签入，但configure文件必须由每个开发人员生成；特殊的configure文件在发布时构建为tarballs）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接