版本控制和个人配置文件

我们的项目使用特定于用户的配置文件。该文件当前不在版本控制中，因为每个用户都不同。问题是，每当开发人员添加需要配置的新模块或更改现有模块的名称时，其他开发人员都会因未更新其私有配置文件而出错。

为了解决该问题，我们考虑使用两个配置文件：一个默认/全局配置文件，该文件将在版本控制中，并由添加新模块的每个开发人员定期更新；一个私有配置文件将被排除在外版本控制，将仅包含用户特定的更改。

但是，这似乎仍然是临时解决方案。

您可以提出更好的解决方案吗？

专业人士做什么？

尽管您已经在这里得到了一些很好的答案，但是其中大多数都遗漏了问题的根本原因：您的用户配置文件似乎不仅包含特定于用户的信息，还包含（可能是多余的）信息，这些信息在其他地方受到版本控制，可能在不同的文件中，例如模块名称。

我可以在这里想到两种可能的解决方案：

• 尝试严格分离该信息。例如，请勿在用户配置中使用任何模块名称。使用ID号（例如GUID）来引用模块，并让这些ID号在分配给模块后再也不会改变。当然，这可能有一个缺点，即用户配置文件失去了它们现在可能拥有的一些简单性。您可能需要创建一个GUI工具来编辑配置文件，而不是使用纯文本编辑器。

• 给您的配置文件格式一个版本号，每当更改模块名称之类的内容时，就为其分配一个新的版本号。然后，您可以提供一个检查版本号的升级脚本，如果配置文件不是最新的，它将更改在文件中找到的所有模块名称，然后增加版本号。这可以是自动化的，因此升级过程不会干扰您的团队成员的日常工作。

编辑：再次阅读您的文章后，我认为您假定的解决方案是合理的，只要添加了新模块但未重命名即可。上面我写的内容将允许以后更改模块名称或现有模块的配置结构。但是，如果您不需要这样做，我会坚持最简单的解决方案。

这是一个合理的解决方案。

您需要一种指定任何新配置元素的初始值的方法。这些文件必须存储在某个地方，并且显而易见的是全局的只读配置文件。

然后，当每个用户更改其个人配置时，您会将这些更改写入其本地副本。

您的代码将需要首先读取全局配置，并且需要用户特定的配置来覆盖所有更改的值。这比读取本地文件然后尝试找出尚未设置的文件要简单得多，因此需要从全局设置文件中读取文件。

如果您使用类似XML的存储方式，则不必担心删除设置的情况。不会从用户的文件副本中请求它们，如果您在保存时重新创建文件，则在更改后第一次使用该应用程序时，它们将被删除。

我们有一个有趣的解决方案，我们主要是PHP开发人员，因此我们使用Phing允许您创建用PHP编写的自动化任务，因此，我们进行了“ phing更新”，而不是进行常规的svn更新，该更新称为svn更新，然后将我们的配置替换为适当的变量，例如config：

$db_user = "${test.db_user}";

因此，所有配置文件都使用该有趣的语法进行了版本控制，然后为我的特定实例生成了一个即席的，未版本化的配置文件，该文件用未版本化的ini文件中指定的未版本化的设置替换了这些“变量”。这样，我们可以修改任何用户特定的文件，并使更改填充到其他所有工作副本中。

当在配置文件中找不到该值时，程序应在代码中具有默认设置。这样一来，添加新事物就不会中断，您的升级路径将更加顺畅，并且当用户弄乱配置文件时，他们也会遇到后备问题。

另一个更复杂的示例是在程序启动或其他关键点上，使用初始化模块打开配置文件并添加所有缺少的默认值，但这似乎很繁琐。

将版本号放入个人配置文件中（配置文件格式的版本号）。

使处理个人配置文件的代码检查版本号，如果它已过期，请执行更新过程。因此，基本上，任何进行更改都会破坏现有配置文件的人都需要更改配置文件格式的版本号，并编写一个过程来更新先前版本的配置文件（重新命名部分等）并重新保存。他们。

无论如何，您可能最终都希望这样的过程供最终用户使用，因此您最好使用它来简化开发人员的生活。

通常，我所看到的是将配置文件的默认值签入存储库。例如，这些可以是测试服务器上所需的值。然后，当开发人员签出文件时，他们将拥有所有值。如果添加了新字段或删除了字段，则会在合并中处理。开发人员将为目标服务器签入所需的值，而不签入针对其个人开发环境的字段的任何其他更改。

注意确保合并正确完成，但是对我来说似乎很安全。

我们在这里所做的是创建设置块。可以像这样在Zend中完成：

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

这意味着测试将继承生产并使用key3对其进行扩展。然后，每个开发人员所需要做的就是设置环境（在这种情况下为测试或生产）

基于以下内容，这是一个有用的解决方案：在源代码管理中保留密码

总之，策略是“在源代码管理中保留配置文件的加密版本，然后提供一种用户可以通过其加密和解密数据的方式”。

1. 创建一个虚拟comfig文件，并对其进行.gitignore。
2. 创建一个可以加密和解密配置文件的makefile
3. 将makefile和加密的配置文件存储在存储库中
4. 生成文件要求输入密码，以及如何与作者联系以获取密码。
5. 生成项目时，如果makefile尚未运行，请向用户提供console.error（“缺少配置文件[conf / settings.json]！您忘记运行了make decrypt_conf吗？”）；
6. 描述了一项检查，以确保配置文件是最新的。

我们构建了一个名为Config的工具，用于处理此类配置问题。您将要做的是创建（或导入）1个主配置文件。然后创建一个名为Local的环境。在本地环境中，创建多个实例，每个用户1个实例。如果您需要进行全面的更改，例如添加新的配置条目或修改模块名称，只需进行更改，即可将其应用于整个版本。如果要更改实例/用户，请将该配置值设置为变量，然后更改该变量。此更改将仅应用于您的实例/用户。所有这些都在版本控制下。您可以通过推或拉部署配置文件。pull选项类似于git pull，但针对该特定实例/用户。

Config提供了其他功能，例如比较用户之间的配置，搜索，标记，验证和工作流。这是SaaS，因此不是真正针对尚未准备好使用云的用户，但是我们确实有一个本地计划。