半可编辑文件（例如配置文件）和版本控制 - 最佳实践？
因此，我今天通过签入配置文件来终止构建。 它知道服务器在哪里（想想 SQL 服务器等），并且我一直在针对在我的机器上运行的服务器进行工作。 通常，或者更确切地说，在其他情况下，我们会针对中央服务器运行。 当然，日常构建没有找到“我的”服务器，因此出现了损坏。 话又说回来，在签入之前编辑配置文件以指向“正常”服务器，并在签入之后再次编辑它是很容易的。
我一直想让 VC 忽略配置文件，这样它就不会被意外签入。 另一方面，存储库应该包含文件的干净、可用的版本。 我现在不可能忽略它并同时将其签入，可以吗？
所以，我正在寻找一种方法来获得一个文件，该文件会签出，但从不签入。至少在最常见的情况下 - 如果配置文件发生重大变化，需要一些特殊的过程来获取将新版本放入存储库是可行的。
如果你们以前遇到过这个问题，我会对你们找到的任何解决方案感兴趣。 只要他们不破坏构建，那就是；）
So, I killed the build today by checking in a config file. It knows where the server is (think SQL server or the like), and I've been working against the server which runs on my box. Normally, or rather, under other circumstances, we'd run against the central server. The daily build, of course, didn't find 'my' server, hence the breakage. Then again, editing the config file to point to the 'normal' server before the checkin, and editing it again after checkin is tendious.
I've been tempted to have VC just ignore the config file, so that it doesn't get checked in accidentally. On the other hand, the repository should contain a clean, usable version of the file. I can't possibly ignore it and have it checked in at the same time, now, could I?
So, what I'm looking for would be a way to have a file which, errr, which checks out, but never checks in. At least in the most common case - should the config file change significantly, some special procedure to get the new version into the repository would be doable.
If You folks have come across this problem before, I'd be interested about any solutions You have found. As long as they don't break the build, that is ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您可以做的是拥有一个保持不变的默认配置文件，除非添加了一些新配置。 然后你就有了一个不同的文件来覆盖默认文件的配置。
只有 config.Default.xml 受源代码控制。 config.User.xml 仅包含与您不同的配置。 因此，假设您正在本地 SQL 服务器上进行测试，您只将连接字符串放在那里，它将覆盖 config.Default 连接字符串。
看一下 .Net Framwork 应用程序配置，它会为您完成大部分（如果不是全部）工作。
What you can do is have a default config file that stays unchanged, unless some new config is added. Then you have a different file that overrides the default file's configs.
Only config.Default.xml is source controlled. config.User.xml contains only the configurations that are different for you. So, say you are testing on a local SQL server, you put only the connection string in there and it will override the config.Default connection string.
Take a look at .Net Framwork Application Configuration, it does most (if not all) of the work for you.
我使用的一种方法是拥有两个版本的配置文件，并让安装程序脚本提取正确的版本。
两个文件都包含相同的键，但一个包含“dev”值，另一个包含我们希望在现场部署和编辑的值。
One method I've used is to have two versions of the config file, and have the installer script pull the correct version.
Both files contain the same keys, but one contains 'dev' values and the other contains the values we expect to deploy and be edited in the field.
我们有
Hudson 删除初始文件并为正确的环境部署正确的文件（当前只有证书）。
这使得开发人员能够独立记录和开发生产、证书和开发级别的配置文件，并在 SVN 中单独对它们进行版本控制。
We have
Hudson deletes the initial file and deploys the correct file for the correct environment (currently only cert).
This allows developers to document and develop production, cert and development level config files independently and have them versioned separately in SVN.
我们将这些类型的文件存储在源代码控制系统中，并为我们正在构建的环境提供不同的文件夹。
所以我们有：
这些下有用于其他环境特定文件的子文件夹。
We store these sort of files in our source control system, and have different folders for the environment we're building for.
So we have:
There are subfolders under these for other environment specific files.
我认为接受的答案很好，但根据您的要求，它可能有局限性。
我们使用以下方法。 请注意，我们是使用 VS 的 .NET 商店，并使用 MSBuild（内置、社区和自定义）任务。
项目的 BeforeBuild 任务会查找 App.config 是否存在，如果未找到，则将 App.default.config 复制到 App.config。 此外，如果 App.config 存在于 CI 构建中，构建服务器始终会删除它（确保干净的配置）。 然后，我们还使用 MSBuild Community FileUpdate 任务根据构建项目的内容将令牌替换为适当的值。
例如，新的开发人员结账可以为本地数据库设置数据库连接字符串，夜间构建可以为夜间数据库设置，等等。
I think the accepted answer is good, but depending on your requirements, it may have limitations.
We use the following approach. Note that we are .NET shop using VS and make use of MSBuild (inbuilt, community and custom) tasks.
A project's BeforeBuild task looks for existance of App.config and if not found copies App.default.config to App.config. Also, the build server always deletes App.config if it exists on a CI build (ensures clean config). We also then use the MSBuild Community FileUpdate task to replace the tokens with the appropriate values based on whatever is building the project.
For example, a fresh developer checkout can setup db connection strings for a local database, a nightly build can setup for the nightly db, etc.
如果我工作的话，我们有单独的配置文件用于部署。 因此，我们解决方案中的配置文件是开发版本，人们可以根据自己的喜好更改它们。 这些配置文件永远不会部署在任何地方。
部署的配置文件存储在我们的源代码控制提供程序中的单独位置。 如果有人需要进行将要部署的配置更改，他们必须修改此版本。
Were I work we have separate config files for deploys. So the config files in our solutions are the development versions and people can change them to their heart's content. These config files are never deployed anywhere.
The config files that are deployed are stored in a separate location in our source control provider. If someone needs to make a config change that will be deployed they have to modify this version instead.
接受的答案很好。 然而，如果您的版本控制系统具有变更列表的概念，则可以做您想做的事情（4 年前），并且只维护一个检出但从不检入的配置文件。 我在 Perforce 中完成了此操作：
查看配置文件并将其保留在自己的更改列表中。 当您提交时，仅提交其他变更列表； 如果您将配置文件更改列表命名为“DO NOT COMMIT”之类的名称，那么这很容易记住。
该系统的一个优点是，如果其他人更改了配置文件的生产版本（即服务器上存在的版本，并且每个人都维护其修改后的本地版本），那么您将收到可能发生冲突的通知您从服务器获取配置文件。 使用已接受的答案中建议的解决方案，您可能会继续使用本地设置默默地覆盖新的生产设置，这可能会破坏您的本地构建或导致您在下次提交时破坏构建。
The accepted answer is good. However, it is possible to do what you wanted to (4 years ago), and maintain just a single config file which checks out and never checks in -- if your version control system has the concept of changelists. I have done this in Perforce:
Check out the config file and keep it in its own changelist. When you commit, commit only the other changelists; this is easy to remember if you name your config file changelist something like "DO NOT COMMIT".
An advantage of this system is that if someone else changes the production version of the config file -- i.e. the one which exists on the server, and which everyone is maintaining a modified local version of -- then you will be notified of possible conflicts when you get the config file from the server. With a solution like that suggested in the accepted answer, you might keep silently overriding the new production settings with your local settings, which could break your local build or cause you to break the build when you next commit.
对于每个配置文件 x，创建一个名为 x.dist 的文件并进行签入，这是默认的分布式配置。 开发人员签出后，有一个脚本将每个 x.dist 文件复制到 x，他们可以在其中根据需要自定义 x。 可以在重大更改后重新运行此脚本以更新文件，或者开发人员可以手动合并其更改。
对于部署，您可以签入实时部署文件并让启动脚本明确引用它们（例如 --config x.product）。
例如，此方法用于 Wordpress 的分发方式（您必须复制模板 wp-config.php 文件）或使用 autoconf 的开发项目（其中签入了configure.ac，但配置文件必须由每个开发人员生成；构建了一个特殊的配置文件，以便在发布时以 tarball 形式分发）。
For each configuration file x, create a file that you do check-in called x.dist, which is the default distributed configuration. After the developers check out, have a script that copies each x.dist file to x, where they can customize x as much as necessary. This script can be re-run to update the files following major changes, or developers can manually merge in their changes.
For deployment, you can check in your live deployment files and have your start-up scripts refer to them explicitly (e.g. --config x.production).
This approach is used, for example, in how Wordpress is distributed (you must copy a template wp-config.php file) or in development projects that use autoconf (where the configure.ac is checked in but the configure file must be generated by each developer; a special configure file is built for distribution in tarballs at release time).