How to reference a specific configuration of a workspace
![]()
Hi,
I couldn't find a solution to this question, so I hope someone can help me here. I want to "remember" a specific configuration of a workspace without having to create a new baseline. The setting can be described as follows: I introduced a new Versionable Type, say myItemType that inherits from versionable. To be able to edit elements of this type, I want to persist (export) them to the local file system, edit the elements and then import them back into the Jazz SCM.. Since the external representation that gets persisted on the local file system does not include state informations of the exported items, I have to store the exact configuration of the workspace the items were exported from. This configuration has to include information about all items (i.e. their itemID) and their states, and has not be changed after its creation. For this purpose, my storage model incldues a class CheckInContext. It referes to the source workspace and the the component that contained the exported elements. The missing thing is an attribute (or reference) that specifies the workspace's configuration at the time the model was exported. What's the best way to do it? Can I simply add a reference to com.ibm.team.scm.common.internal.Configuration ? This might get a bit hacky, since it's not visible to other components by default. Is this information accessible via the workspace's stateID? If so, would it be sufficient to remember this stateID together with the source workspace? How would I access the workspace with a given state? Many thanks for your help! --Tim |
6 answers
![]()
WRT SCM API : Each component entry in a workspace has a configuration
time which can be used to quickly determine whether or not the component's configuration has changed out from underneath you. See IFlowNodeConnection#getComponentInfo() to get a structure on the client which contains the configuration time. I am still confused as to what exactly you are trying to do. We do not have API (in the SCM component) which allows you to atomically fetch an entire configuration at once, and a workspace or stream's configuration may change out from underneath you while you are reading it in pieces. What do you mean by "edit the elements, then import them back into Jazz SCM"? JohnC SCM Server Tim Schumann wrote: Hi, |
![]()
Hi John,
thanks for you response, let's try to be more concrete. I want to enable Jazz to support concurrent development of models. Therefore we defined an internal meta-model independent representation of models, whose elements are instances of InformationItem which is inheritetd from Versionable. Since we want to focus on model management, the models are assumed to be created and edited in external applications. Thus, we need to provide import and export mechanisms to import (edited) models into the Jazz SCM and to export them for external editing. To export the model, I simply fetch all elements (instances of InformationItem) of the component holding the model and persist them in an external representation on the local file system. At this point, I know the stateID of every exported model element and do not have to worry about simultaneous changes by others (at least, I can assume this in my current setting). When we import a model element X (instance of InformationItem) into a workspace WS, we have to know its state S by the time we exported it to be able to (1) determine if the model element X has been changed by others, i.e. if the current state of X in workspace WS is different from S. (2) if (1) applies, to compute a merged version of this element X that incorporates both, the internal and the external changes. (3) determine if the model element X was externally changed at all. This is especially needed to perform a merge described in (2) .... So, the question is, what's the easiest way to get such a mapping: "item --> item state". One possibility was to store this information on my own, but if this information is already provided by Jazz, I could reuse it. Basically, two things came into my mind, namely to get the workspaces Configuration at the time the model was exported, or to remember the workspaces stateID. Do you see an option that works for me? Many thanks for your help! "John Camelon" <jcamelon@ca.ibm.com.no.spam> wrote in message news:fsg60b$r2g$1@localhost.localdomain... WRT SCM API : Each component entry in a workspace has a configuration time |
![]()
The SCM data model is not structured in such a way that the workspace
contains all of the sub artifacts (ChangeHistory and Configurations). The workspace's state id only changes when the workspace itself gets updated ... Configuration & ChangeHistory can change independent of the workspace, so tracking the workspace's state id will not help you. What I would suggest may be a little unelegant, but it is the way that a lot of things currently need to work: consider the following psuedo-code: IWorkspaceConnection w = ...; IComponentHandle comp = ...; for( int i = 0; i < NUMBER_OF_ATTEMPTS; ++i ) { IConfiguration config = w.configuration(comp); ISyncTime before = w.getComponentInfo(comp).configurationTime(); // walk the configuration to gather all the information you need // use config.childEntriesForRoot() to get children of root // use config.childEntries() for all children which are folders // loop until there are no more folders to ask for children of ISyncTime after = w.getComponentInfo(comp).configurationTime(); if( before.equals(after) ) break; // clear your data store and retry } You can also check the opposite condition while you walk the configuration with child-entries ... ISyncTime after = w.getComponentInfo(comp).configurationTime(); if( !before.equals(after) ) { // clear your data store and retry continue; } You will have more success if you do not do anything other than walk the configuration w/child entries in this loop: do not bother fetching the versionable states then, as these states are immutable and can be fetched later once you have retrieved the entire item -> state handle mapping. Hope this gives you what you need, JohnC SCM Server Tim Schumann wrote: Hi John, |
![]()
Hi John,
thanks for your response. Just to make sure, I understood your suggestion correctly. To tackle the issue how to handle a mapping "item --> item state", you suggest to manage this mapping on my own. I have to persist this mapping, since it could take a long time until an exported model gets checked-in back. What would be the most convenient way to realize this in my storage model. Consider the storage model entity "CheckInContext". Would a many-valued reference to a helper "MyStateSelection" suffice, where MyStateSelection has a reference to a Versionable (of this case: InformationItem) and an UUID attribute holding its state? Many thanks and best regards, --Tim "John Camelon" <jcamelon@ca.ibm.com.no.spam> wrote in message news:fsg9tr$su2$1@localhost.localdomain... The SCM data model is not structured in such a way that the workspace |
![]()
Tim Schumann wrote:
Hi John, We have put in a significant amount of work in the RTC client to perform this type of work in maintaining the copy file area (content, hashcodes, timestamps, etc.) ... unfortunately, this is not something that other Versionables can participate in (easily) or reuse in another context at this time. Since a configuration can be arbitarily large, we like to use the configuration time as an indicator as to whether or not things have changed to short-circuit operations whenever possible. What would be the most convenient way to realize this in my storage model. A set of Versionables basically represents a configuration. The Versionable contains the state-id, so MyStateSelection just wraps IVersionable. Cheers, JohnC SCM Server Many thanks and best regards, |
![]()
Hi John,
thank you so much for clarifying these issues. That's great! --Tim "John Camelon" <jcamelon@ca.ibm.com.no.spam> wrote in message news:fshpnt$hka$1@localhost.localdomain... Tim Schumann wrote: |
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.