blocks|key|320906|text|我使用的一种方法是有两个版本的配置文件，并让安装程序脚本提取正确的版本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|320907|320908|settings.xml|unordered-list-item|320909|settings.xml-Release|320910|320911|这两个文件包含相同的密钥，但一个包含'dev‘值，另一个包含我们期望在字段中部署和编辑的值。|320912|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

One method I've used is to have two versions of the config file, and have the installer script pull the correct version.

<ul>
<li>settings.xml</li>
<li>settings.xml-Release</li>
</ul>

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.

blocks|key|321034|text|在我工作的时候，我们有单独的配置文件用于部署。因此，我们解决方案中的配置文件是开发版本，人们可以根据自己的需要对其进行更改。这些配置文件永远不会部署到任何地方。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|321035|部署的配置文件存储在源代码管理提供程序中的单独位置。如果有人需要对将要部署的配置进行更改，他们必须改为修改此版本。|321036|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1023291|text|我们将这些类型的文件存储在我们的源代码控制系统中，并且对于我们要构建的环境有不同的文件夹。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1023292|所以我们有：|1023293|Dev
Test
Live|code-block|syntax|javascript|1023294|在这些文件夹下有其他特定于环境的文件的子文件夹。|1023295|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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:

<pre><code>Dev
Test
Live
</code></pre>

There are subfolders under these for other environment specific files.

blocks|key|1023327|text|我们有|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1023328|1023329|*.(config+%7C+xml)|unordered-list-item|1023330|*.(config+%7C+xml).cert|1023331|*.(config+%7C+xml).production|1023332|1023333|Hudson删除初始文件，并为正确的环境部署正确的文件(当前仅有cert)。|1023334|这允许开发人员独立地记录和开发生产、证书和开发级配置文件，并在SVN中分别对它们进行版本控制。|1023335|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|U|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

We have 

<ul>
<li>*.(config | xml)</li>
<li>*.(config | xml).cert</li>
<li>*.(config | xml).production</li>
</ul>

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.

blocks|key|321193|text|您可以做的是有一个默认的配置文件，它保持不变，除非添加一些新的配置。然后您有一个不同的文件，它覆盖了默认文件的配置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|321194|config.Default.xml
config.User.xml|code-block|syntax|javascript|321195|只有config.Default.xml是受源代码控制的。config.User.xml只包含与您不同的配置。因此，假设您在本地SQL+server上进行测试，您只需将连接字符串放入其中，它将覆盖config.Default连接字符串。|321196|看一看.Net框架应用程序配置，它为您完成了大部分(如果不是全部)工作。|321197|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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.

<pre><code>config.Default.xml
config.User.xml
</code></pre>

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.

blocks|key|1023385|text|对于每个配置文件x，创建一个名为x.dist的签入文件，这是默认的分布式配置。在开发人员签出之后，有一个脚本可以将每个x.dist文件复制到x，在那里他们可以根据需要自定义x。此脚本可以重新运行以在主要更改后更新文件，或者开发人员可以手动合并他们的更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1023386|对于部署，您可以签入您的实时部署文件，并让您的启动脚本显式引用它们(例如--config+x.production)。|1023387|例如，在如何分发Wordpress+(您必须复制模板wp-config.php文件)或使用autoconf的开发项目(在这种情况下，configure.ac是签入的，但配置文件必须由每个开发人员生成；为在发布时在tarball中分发而构建的特殊配置文件)中使用了这种方法。|offset|length|1023388|entityMap|0|LINK|mutability|MUTABLE|url|http://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Install^0|0|0|8|9|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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 <a href="http://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Install" rel="nofollow noreferrer">Wordpress</a> 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).

blocks|key|321289|text|我认为公认的答案是好的，但根据您的要求，它可能会有局限性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|321290|我们使用以下方法。请注意，我们正在使用VS并利用MSBuild+(内置、社区和自定义)任务进行.NET。|321291|版本控制忽略了|321292|App.config，但它包含在project.|unordered-list-item|321293|App.default.config中，受版本控制，也包含在项目中。我们使用令牌，而不是硬编码可以更改的内容，例如数据库连接字符串。|321294|321295|项目的BeforeBuild任务查找是否存在App.config，如果没有找到，则将App.default.config复制到App.config。此外，如果App.config存在于CI构建中，构建服务器将始终删除它(确保干净的配置)。然后，我们还使用MSBuild社区FileUpdate任务根据构建项目的内容将令牌替换为适当的值。|321296|例如，新的开发人员结帐可以为本地数据库设置数据库连接字符串，可以为夜间数据库设置夜间构建，等等。|321297|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|V|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

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.

<ul>
<li>App.config is ignored by version control but included in the project.</li>
<li>App.default.config is under version control and also included in the project. Instead of hard-coding things that can change, e.g. db connection strings, we use tokens instead.</li>
</ul>

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.

blocks|key|3539263|text|公认的答案是好的。但是，如果您的版本控制系统具有变更列表的概念，则可以做您想要做的事情(4年前)，并且只维护一个签出而从不签入的配置文件。我在Perforce中做到了这一点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3539264|检出配置文件，并将其保存在其自己的更改列表中。提交时，只提交其他更改列表；如果您将配置文件更改列表命名为类似于"DO+NOT+COMMIT“的名称，则很容易记住这一点。|3539265|此系统的一个优点是，如果其他人更改了配置文件的生产版本--即存在于服务器上的配置文件，并且每个人都在维护其修改后的本地版本--那么当您从服务器获取配置文件时，您将收到可能发生冲突的通知。使用类似于公认答案中建议的解决方案，您可能会继续使用本地设置悄悄覆盖新的生产设置，这可能会破坏您的本地构建，或者导致您在下次提交时破坏构建。|3539266|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

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 ;)

Semi-editable Files (eg config files) and version control - best practices?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

所以，我今天通过签入一个配置文件终止了构建。它知道服务器在哪里(比如SQL server或类似的服务器)，而我一直在使用在我的机器上运行的服务器。通常，或者更确切地说，在其他情况下，我们会与中央服务器运行。当然，每日构建没有找到‘我的’服务器，因此出现了损坏。然后，在签入之前编辑配置文件以指向“正常”服务器，并在签入之...

问半可编辑文件(如配置文件)和版本控制-最佳实践？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问半可编辑文件(如配置文件)和版本控制-最佳实践？EN