Some clarification about SCM terms

On Fri, 18 Jan 2008 14:07:46 +0000, tim.schumann wrote:

1) What does the term "era" exactly define? (This term is mentioned
quite often, for example in the JavaDoc comment of
IFlowNodeConnection.discardChangeSets()).

Era is a synonym same as ChangeHistory.

This concerns the SCM ecore model (scm.ecore). 2a) It's not obvious to
me, what roles ChangeHistory and ChangeHistoryEntry exactly play.

A ChangeHistory is made up of an ordered list of ChangeHistoryEntries.

2b) Why does a ChangeHistory object has the "previous" relationship
with other ChangeHistory objects? Shouldn't this order be defined on
ChangeHistoryEntry objects?

ChangeHistoryEntry is just a single entry in a ChangeHistory. The entire
history of your workspace is made up of linked ChangeHistories.

- Dmitry

On Mon, 21 Jan 2008 10:49:23 +0100, Tim Schumann wrote:

Okay, let's see if I understood it correctly: So, each ComponentEntry
has exactly one era (ChangeHistory) which is considered to be its own.
The history that is represented is defined by an ordered set of
ChangeHistory elements and each of those defines one step in the
history. At a specific step in the history, multiple changeHistoryEntry
elements (each containing one changeset) may be present. Is this correct
this far?

Yes.

1) How is it determined, which changeSet elements belong to the same
changeHistoryEntry?

What do you mean? A ChangeHistoryEntry references a particular ChangeSet.
That changeset doesn't "belong" to it, in that other ChangeHistoryEntries
in other ChangeHistories may reference the same ChangeSet.

2) Am I right with the assumption, that each changeSet that was applied
to a workspace is associated to this workspace via Workspace -
ComponentEntry -> changeHistory -> ChangeHistoryEntry -> ChangeSet ?

Yes.

3) Where is a particular ChangeSet stored? Does it belong to exactly one
Workspace, or does it exist indepently in the repository?

It exists independently of any workspace in the repository. Multiple
ChangeHistories may reference it or it may not even be referenced at all.

- Dmitry

Hi,

thanks for your fast response.
Things are getting clearer to me now.

"Dmitry Karasik" <dkarasik@ca.ibm.com> wrote in message
news:fmqce1$ghq$1@localhost.localdomain...

On Fri, 18 Jan 2008 14:07:46 +0000, tim.schumann wrote:

1) What does the term "era" exactly define? (This term is mentioned
quite often, for example in the JavaDoc comment of
IFlowNodeConnection.discardChangeSets()).

Era is a synonym same as ChangeHistory.
Okay, let's see if I understood it correctly:

So, each ComponentEntry has exactly one era (ChangeHistory) which is
considered to be its own.
The history that is represented is defined by an ordered set of
ChangeHistory elements and each of those defines one step in the history.
At a specific step in the history, multiple changeHistoryEntry elements
(each containing one changeset) may be present.
Is this correct this far?
Two question come to my mind:
1) How is it determined, which changeSet elements belong to the same
changeHistoryEntry?
2) Am I right with the assumption, that each changeSet that was applied to a
workspace is associated to this workspace via Workspace -> ComponentEntry ->
changeHistory -> ChangeHistoryEntry -> ChangeSet ?
3) Where is a particular ChangeSet stored? Does it belong to exactly one
Workspace, or does it exist indepently in the repository?

Many thanks for your great support !

--Tim

On Mon, 21 Jan 2008 15:17:01 +0100, Tim Schumann wrote:

1) How is it determined, which changeSets are referenced by the _same
ChangeHistory element_ (via its ChangeHistoryEntrys)? Is there a
chronological order defined on those changeSets referenced by the same
ChangeHistory element?

The ChangeHistory contains a List of ChangeHistoryEntries, oldest first.

- Dmitry

Thanks for your great post, Dmitry!

Just let me clarify one of my last questions :

1) How is it determined, which changeSet elements belong to the same
changeHistoryEntry?

What do you mean? A ChangeHistoryEntry references a particular ChangeSet.
That changeset doesn't "belong" to it, in that other ChangeHistoryEntries
in other ChangeHistories may reference the same ChangeSet.
So the question should be:

1) How is it determined, which changeSets are referenced by the _same
ChangeHistory element_ (via its ChangeHistoryEntrys)? Is there a
chronological order defined on those changeSets referenced by the same
ChangeHistory element?

I hope there's a chance to understand this question ;-)

Many thanks,

--Tim

Hi,

@Dmitry: Many thanks for your great help, but I guess, I still didn't get it
completely.
Thank you for being that patient ;-)

From your response:

Era is a synonym same as ChangeHistory.

A ChangeHistory is made up of an ordered list of ChangeHistoryEntries.

ChangeHistoryEntry is just a single entry in a ChangeHistory. The entire
history of your workspace is made up of linked ChangeHistories.

1)Why do we need multiple ChangeHistories (i.e. multiple eras) to define the
history of my workspace?

2)How is the "start" and "end" of a ChangeHistory (i.e. era) defined (this
refers to my question on how it is determined, to which era a changeSet
belongs)?

3) Is the following correct? If not, please correct me.
A ComponentEntry's changeHistory is the current era of the referenced
Component in my Workspace. All the eras that can be reached using
changeHistory.previous() describe a (past) configuration of this component
in my Workspace.

4) Is the following correct? If not, please correct me.

If I'm interested in the components past configurations that have not been
in my Workspace, I follow the ComponentEntry's reference "basis" to the
Baseline that was used to initialize this Component in my Workspace.
Following the Baseline's "history" reference, I have access to all preceding
eras of this component.


Many thanks,

--Tim

"Dmitry Karasik" <dkarasik@ca.ibm.com> wrote in message
news:fmqce1$ghq$1@localhost.localdomain...

On Fri, 18 Jan 2008 14:07:46 +0000, tim.schumann wrote:

1) What does the term "era" exactly define? (This term is mentioned
quite often, for example in the JavaDoc comment of
IFlowNodeConnection.discardChangeSets()).



This concerns the SCM ecore model (scm.ecore). 2a) It's not obvious to
me, what roles ChangeHistory and ChangeHistoryEntry exactly play.



2b) Why does a ChangeHistory object has the "previous" relationship
with other ChangeHistory objects? Shouldn't this order be defined on
ChangeHistoryEntry objects?


- Dmitry

Answers inline.

JohnC
SCM Server Team

Tim Schumann wrote:

Hi,

@Dmitry: Many thanks for your great help, but I guess, I still didn't get it
completely.
Thank you for being that patient ;-)

From your response:
Era is a synonym same as ChangeHistory.

A ChangeHistory is made up of an ordered list of ChangeHistoryEntries.

ChangeHistoryEntry is just a single entry in a ChangeHistory. The entire
history of your workspace is made up of linked ChangeHistories.

1)Why do we need multiple ChangeHistories (i.e. multiple eras) to define the
history of my workspace?

We chunk history up into separate eras for performance reasons, and also
to allow for reuse amongst different streams and workspaces.

2)How is the "start" and "end" of a ChangeHistory (i.e. era) defined (this
refers to my question on how it is determined, to which era a changeSet
belongs)?

Any era is defined by its ordered list of change history entries and a
pointer to the previous era. The "start" is the first change history
entry in the list and the "end" is the last change history entry in the
list.

3) Is the following correct? If not, please correct me.
A ComponentEntry's changeHistory is the current era of the referenced
Component in my Workspace. All the eras that can be reached using
changeHistory.previous() describe a (past) configuration of this component
in my Workspace.

They describe past configurations of the team, perhaps, but not
necessarily past configurations of this particular workspace. The accept
and replaceComponent operations may end up restructuring change-history
significantly. Change histories track sequences of changes, and do not
equate to representing a pure audit trail at this time. ( The
description as to what exactly these operations do is a little involved
.... please let me know if you require this. )

4) Is the following correct? If not, please correct me.

If I'm interested in the components past configurations that have not been
in my Workspace, I follow the ComponentEntry's reference "basis" to the
Baseline that was used to initialize this Component in my Workspace.
Following the Baseline's "history" reference, I have access to all preceding
eras of this component.

Baselines refer to eras, and era's are structured in a tree formation
(no cycles). Following the history pointer, you will get one branch of
that global tree. Everything else that is not part of that branch are
configurations that you may never have seen.

Many thanks,

--Tim

Hi John,

thanks for your great answers.
Please see my comments below.

"John Camelon" <jcamelon@ca.ibm.com.no.spam> wrote in message
news:fn4qs2$kbf$1@localhost.localdomain...

3) Is the following correct? If not, please correct me.
A ComponentEntry's changeHistory is the current era of the referenced
Component in my Workspace. All the eras that can be reached using
changeHistory.previous() describe a (past) configuration of this
component in my Workspace.

They describe past configurations of the team, perhaps, but not
necessarily past configurations of this particular workspace. The accept
and replaceComponent operations may end up restructuring change-history
significantly. Change histories track sequences of changes, and do not
equate to representing a pure audit trail at this time. ( The description
as to what exactly these operations do is a little involved ... please let
me know if you require this. )

It would be great if you could explain these operations in more detail.

4) Is the following correct? If not, please correct me.

If I'm interested in the components past configurations that have not
been in my Workspace, I follow the ComponentEntry's reference "basis" to
the Baseline that was used to initialize this Component in my Workspace.
Following the Baseline's "history" reference, I have access to all
preceding eras of this component.

Baselines refer to eras, and era's are structured in a tree formation (no
cycles). Following the history pointer, you will get one branch of that
global tree. Everything else that is not part of that branch are
configurations that you may never have seen.

Got that. Thanks for this clarification.

Many thanks,

--Tim

Tim Schumann wrote:

Hi John,

They describe past configurations of the team, perhaps, but not
necessarily past configurations of this particular workspace. The accept
and replaceComponent operations may end up restructuring change-history
significantly. Change histories track sequences of changes, and do not
equate to representing a pure audit trail at this time. ( The description
as to what exactly these operations do is a little involved ... please let
me know if you require this. )

It would be great if you could explain these operations in more detail.

I am going to describe the theme of how these operations work rather
than their implementation, so that I still have some wiggle-room as we
evolve things. ;-)

The ChangeHistory that a ComponentEntry refers to is considered to be a
"live" era. Live eras always have a previous era, and that era cannot
be live : we call these eras frozen eras.

Certain operations will perform a type of era surgery where the live
era's previous pointer will be replaced with a different frozen era,
thus potentially replacing a large subset of the era structure, and
perhaps adding or removing a number of change-sets from the total sum
of history.

Applications which process change history are not to make assumptions
about how the structure of change history may change with a particular
operation, although we are looking into a more formalized way to
describe these type of transformations of era structure.

Hope that helps,
JohnC
SCM Server