Keeping ignored files when unloading/loading workspace
In our project, we have some xml configuration files that differ between each developer's environment. The problem with having these in source control is that when a developer modifies these files, the changes will show up in the pending changes view and the developer might deliver them by accident. To avoid this, we use a config.xml.sample file in our source and ignore config.xml at the parent folder level. Once the code is checked out for the first time, the developer can copy that file to config.xml and modify the settings. Changes would longer be visible in the pending changes view.
This was a good approach when we still used subversion, as the source rarely gets deleted. User can switch between branches and subversion would apply the differences between those branches. However, in RTC when switching between workspaces (unload/load), the source files get deleted. Therefore, the developer has to reconfigure the system each time. Any solutions for this issue? |
4 answers
Ralph Schoon (63.1k●3●36●46)
| answered Apr 07 '10, 11:46 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel,
you can keep a workspace loaded when switching to another workspace. You should only make sure that the sandbox location for the loaded repository workspace is unique for each workspace. I do that for demos on a regular basis. I would suggest to make the sandbox the workspace direcory (advanced settings and should be default). When opening a workspace RTC reconnects to the loaded repository workspace. Ralph Thanks Ralph and Anthony, |
|
Thanks Ralph and Anthony,
We already thought of switching between workspaces to overcome this issue, but I was hoping for a better solution. By the way, is there any way to switch between workspace without reloading the entire workspace? Kinda like an 'svn switch' that just applies the differences between the two sets. |
|
Ralph Schoon (63.1k●3●36●46)
| answered Apr 07 '10, 10:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel, Anthony,
I have heard about a similar use case from another customer. I think it is really valid especially when special XML configuration files are required to control environments. I was wondering if someone would have a suggestion how to solve this. This is similar to view private files you might be able to use in Clear Case. One idea would be if it would be possible to isolate those files in one component to maybe have a private copy of such a component and just not deliver changes. I doubt however, that these files could be isolated. Any ideas or suggestions are welcome on how to do this in a controlled way, not depending on "not deleting a workspace" sheer luck if possible. Daniel if there is no solution to this feel free to submit a work item. In our project, we have some xml configuration files that differ between each developer's environment. The problem with having these in source control is that when a developer modifies these files, the changes will show up in the pending changes view and the developer might deliver them by accident. To avoid this, we use a config.xml.sample file in our source and ignore config.xml at the parent folder level. Once the code is checked out for the first time, the developer can copy that file to config.xml and modify the settings. Changes would longer be visible in the pending changes view. |
In our project, we have some xml configuration files that differ between each developer's environment. The problem with having these in source control is that when a developer modifies these files, the changes will show up in the pending changes view and the developer might deliver them by accident. To avoid this, we use a config.xml.sample file in our source and ignore config.xml at the parent folder level. Once the code is checked out for the first time, the developer can copy that file to config.xml and modify the settings. Changes would longer be visible in the pending changes view. Hi Daniel Would you be able to use separate Eclipse workspaces (File->Switch Workspace) to manage the changes to different workspaces. It might even be quicker to work this way as you would no longer be having to load/unload. anthony |
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.