I want to use workspaces, but the problem I have is that one workspace can't be a child of another unfrozen workspace. There can be multiple sibling workspaces off the same base/root, but not parent/child/grandchild, etc. structure for unforzen workspaces.
I have no reason for siblings.
I want to support our releases as they go into production. So, right now, I have release 6 in production, release 7 will go into production in a few weeks and release 8 is in analysis and design. The release 7 database may have changes to it, while release 8 glossary, LDM, PDM and process models are being developed. But Release 8 needs to see any changes made to release 7, so I can't freeze release 7 at this point in time.
With the new merge capabilities in 184.108.40.206, where you can select which changes can be merged into the production encyclopedia, that maybe I should just have a production root encyclopedia and a development workspace. All the currently changing releases go into the development workspace. Then, when a release goes into production, the selective merge can be used to move those changes into production.
This would work, as long as the same diagram or definition isn't changed in different active releases. If this happened, I lose what is applicable to the earlier release.
Any ideas how to solve this problem?
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
1 reply Latest Post - 2013-03-15T05:02:44Z by SystemAdmin
Pinned topic Need Ideas for Using Workspaces - Long
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-03-15T05:02:44Z at 2013-03-15T05:02:44Z by SystemAdmin
SystemAdmin 110000D4XK1061 PostsACCEPTED ANSWER
Re: Need Ideas for Using Workspaces - Long2013-03-15T05:02:44Z in response to TerryMoriartyThat's a great post Terry. I understand your pain brother.
I wish I could offer an answer. I think your idea of using the merge function is probably the answer. The only suggestion I have, and I haven't actually tried this, is to create a definition type with a listof (or hetero-listof) property that might point to all the definitions to change in project and use that to drive your merge?