Some clarification about SCM terms
Hi,
I'm currently working on my diploma thesis which is about implementing a model repository. We decided to built on top of the Jazz SCM. When I had a look on the data models and JavaDoc of the repository and SCM component, some questions arose. To keep the threads shorter, I'll ask some of the questions in a separate thread. Concerning changes and histories: 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? Many thanks for your support, --Tim |
9 answers
On Fri, 18 Jan 2008 14:07:46 +0000, tim.schumann wrote:
1) What does the term "era" exactly define? (This term is mentioned 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. - 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 Yes. 1) How is it determined, which changeSet elements belong to the same 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 Yes. 3) Where is a particular ChangeSet stored? Does it belong to exactly one 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: 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 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 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. 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: |
Answers inline.
JohnC SCM Server Team Tim Schumann wrote: Hi, 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 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. 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. 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, |
|
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. It would be great if you could explain these operations in more detail. 4) Is the following correct? If not, please correct me. Got that. Thanks for this clarification. Many thanks, --Tim |
|
Tim Schumann wrote:
Hi John, 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 |
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.