|
|
|
Reflections
Terminology
Operating on Files
Operating on Productions
Please read this symbol legend before continuing.
Terminology
Source control systems generally use the term "branching" in a general way to refer to any branch-style operation. Because of the potentially multiple meanings of this, we use some slightly different terminology than what you might be used to.
Share - The simplest of the relationships. Objects in Evolution are not tied to a path of any sort. Objects simply link or refer to each other. In the case of a share, more than a single container object is linking to the object. There is no physical data replication in sharing.
Clone - Cloning creates an exact duplicate of the object being cloned, including version history. After the cloning operation the two objects are completely unrelated and not kept in synch in any way. Physical data is replicated in this case as the clones are different objects.
Reflect - A reflection is a unidirectional relationship. You create a reflection of an archetype, after which any change made to the archetype is propagated into the reflection. Any change made to the reflection breaks the relationship, at which point data replication occurs.
|
In Evolution there are two types of objects: files and Productions. All three of the above operations can be performed on either of these objects.
Operating on Files
Creating a clone of a file copies the entire revision history, including physical data, from the archetype to the clone. From that point, there is no relationship maintained by the server between the two separate objects; they only happen to share precisely the same revision history up until the point of cloning.
A reflection relationship for files is sometimes called "branch on change". The relationship between the archetype and reflection can be viewed as a simple share. Any changes made to the archetype are propagated into the reflection.
A "change" is defined as a versioning operation. When a new version is created for the archetype, the same version operation occurs in the reflection. The revision histories for both will always be the same until a version is directly created for the reflection. Then then reflection is broken and it effectively becomes a clone. The reflection will have a new version created, the archetype will remain unchanged, and the server will no longer maintain the link between the two.
Operating on Productions
When a Production is cloned, every object beneath the archetype is cloned and linked in the same hierarchy. Cloned files beneath the Production are described above. The cloning process of the actual Production is analogous. The revision history of the Production is copied, and there is no longer a link between the archetype and the clone.
Production reflections are also analogous. The difference is the definition of "change". While a change in a file occurs when a new version is created, a change in a Production is a structural change. For instance, sharing a file into the archetype will propagate the share into any reflections of the Production. Sharing a file into the reflection is changing the structure of the Production; and therefore, the reflection is broken. The share will occur in the reflection, but not in the archetype, and any subsequent changes in the archetype are not propagated to this particular reflection of it (note the relationship between the archetype and its other reflections are not affected).
There are six changes that can occur in a Production that are either propagated to its reflections or cause a break to its archetype.
 |
[Production]
|
r:[Production]
|
| Creating an {Object} in
|
Also creates r:{Object} in r:[Production].
|
br:[Production], then creates {Object} in b:[Production].
|
| Sharing an {Object} into
|
Also creates r:{Object} in r:[Production].
Note, it does NOT share {Object} into both [Production] and r:[Production], but rather creates a reflection of the shared {Object} in r:[Production].
|
br:[Production], then shares {Object} into b:[Production].
|
| Removing an {Object} from
|
Also removes r:{Object} from r:[Production]
|
br:[Production], then removes {Object} from b:[Production].
|
| Cloning an {Object} into
|
First creates c:{Object} in [Production], then creates r:c:{Object} in r:[Production]
|
br:[Production], then creates c:{Object} in b:[Production].
|
| Unsharing an {Object} in
|
Removes {Object} from [Production], then creates c:{Object} in [Production]. See above "Removing" and "Cloning", Unshare is a combination of these 2 operations.
|
Removes {Object} from r:[Production], then creates c:{Object} into b:[Production].
|
| Reflecting an {Object} into
|
Creates r:{Object} in [Production], then r:r:{Object} in r:[Production]
|
br:[Production], then creates r:{Object} in b:[Production].
|
|
*Reflections only apply to tip revisions of Productions, not numbered, historical versions.
Note that versioning a file is not one of the operations that propagates into or breaks a Production reflection.
|
|
|
People are talking...
"Evolution has already made quite an impact on timescales, with a great reduction in accidental overwrites and deletions from previous projects."
Mark Docherty
Lead Developer
d2 Digital
Read what Nick Ni, ionForge's Director of Technology, has to say in
Software Test & Performance MagazineBuild Management
Best Practices
|
|
