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:
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.

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.
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?

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,

--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
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,

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!

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
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,

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!

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
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,

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