Managing config files using .NET RTC Client
Hello...
Anyone have a better solution for handling web.config and app.config files? We would like to retain a master copy in source control, so we don't want to ignore these file types. However, everyone has their own local environment, so config settings need to be managed on each developer's local machine. We currently check all our config files into a changeset, and call it something like "Config files - DON'T DELIVER THIS CHANGESET". Invariably someone delivers their config files by mistake--usually by right clicking the Outgoing folder and choosing Deliver. The stream is polluted with someone's local config file. Would be nice to have a "require confirmation" attribute on a changeset, which would be off by default, but a developer could set it with a certain warning, which would be displayed if the user did a deliver on that changeset...either directly (by right clicking the individual changeset and delivering) or indirectly (by right clicking outgoing and clicking deliver). eg: I make changes to my config files, and check them into a new changeset, which I intend never to deliver. I mark this changeset "Require Confirmation" and it asks me for a reason "Changeset contains config files". If I later try to deliver it, it displays "Warning: . Are you sure you want to deliver?" |
2 answers
Can't you just ignore the files? Something like:
1. Set the config files to their preferred in-stream state. 2. Deliver the files. 3. Ignore the files in the config directory (triggering the creation of a .jazzignore file) 4. Deliver the ignore file. Now you have the config files in the stream in their preferred form, and the files are ignored. When you want to modify them again: 1. Modify the .jazzignore file so that it doesn't include the config files 2. Change the config files 3. Selective commit the changes to the config files. Deliver that change set. 4. Undo the change to the .jazzignore file. e |
|
Yes, we could ignore the config files, but ofttimes we need to maintain a "master" config file. For example, Microsoft MVC requires settings in the web.config file, and we all need to know when settings like those are added or changed. Also, if someone adds a new application specific setting that the rest of the developers need to have, it needs to be delivered along with the code that uses the new setting(s).
For example, the stream should contain settings like
and the developer who owns a repository workspace might need it to be
and another developer might need to deliver a new setting so that the stream would end up containing
When this changeset is delivered, along with code that depends on settingNumberTwo, the first developer could merge settingNumberTwo into his config file, which he is currently managing locally, without ever desiring to deliver his local changes. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.