---

Concurrent development allows two or more developers to work on a different version of an object in separate locations. The following diagram demonstrates how concurrent development is managed in VC/m:

1. The object version CLS.MyClass/App.6 exists in the library.
2. Developer1 checks the object out to the Development Area, creating the new object version CLS.MyClass/App.7.
3. Developer2 then checks the same object out to the Bug-fix Area, creating the new object version CLS.MyClass/App.8.
4. Developer2 then checks the object back in to the Library.
5. Developer1 attempts to check the object back in to the library too, but the action is not allowed. This is because the latest version of the object that exists in the library - CLS.MyClass/App.8 - is not an ancestor of Developer1's version of the object.
6. In order to check the object in, the two objects must be merged. This begins with a manual merge, where the developer diffs the two different versions using Beyond Compare and makes the relevant adjustments to ensure that CLS.MyClass/App.7 (the version currently checked out) contains the changes made in CLS.MyClass/App.8.
7. The developer then performs a Merge in VC/m (see below), which creates a new version of the object - CLS.MyClass/App.9 - in the location to which CLS.MyClass/App.7 was checked out.
8. CLS.MyClass/App.9 can now be checked in and the changes that both Developer1 and Developer2 have made can be incorporated back into the library.

While the diagram only constitutes a simple example, the same basic principles still apply with more complex concurrent development.

Branching

---

When the same object version is checked out multiple times, each check-out creates a branch. A branch is essentially a record of lineage. As such, VC/m is able to keep a track of how the same object has been developed in different ways.

In the diagram, two branches form. One has IE01/1.7 at the tip of the branch, and the other has IE01/1.8 at its tip.

An object version on one branch can never over-write one on another branch. VC/m enforces this by checking ancestry whenever a user tries to transfer an object between locations. If the latest version of the object in that location is not an ancestor of the one that the user tried to transfer, the transfer will not be allowed.

Merging

---

It usually becomes necessary to merge two branches together at some point in order to integrate the changes that have developed along each branch.

Note: VC/m does not integrate the changes to the objects' components. Rather, merging creates a new object version that constitutes a shared descendent of two branches. As such, before performing a merge, you must integrate the content of the latest object versions on each branch using an appropriate editing tool.

---

See Also: Object Versions, Physical Storage, The Library, Comparing Two Object Versions