![]() |
![]() |
Software organizations use branches to isolate changes made to codebase in order to support concurrent software development. Commonly seen types of branches are release, development and private branches.
As the number of branches grows, so does the amount of work needed to merge changes. Usually, a fix for a bug found in a release or a development branch has to be merged to all active release and development branches. So, the amount of work to merge changes grows linearly with the number of active branches.
Example: A development process for a software product with a six-month release cycle produces two branches a year. With a product life time of five years, the number of active branches is ten for this release model.
Growing number of branches leads to significant degradation of performance of a software organization because the organization has to spend increasing time merging instead of delivering new functionality and bug fixes.
The natural solution to this problem is automating the merging activity. A daemon would detect new changes to a branch, merge changes and submit the result to a version control system (VCS). Merge conflicts are reported to a change owner for review and manual merge. Such an automatic merge daemon can be scripted within a day.

Yet, a more detailed analysis of this approach shows that it doesn't solve the problem but rather makes it worse. The core of the problem is that a successful, conflict-less merge in general may produce a semantically incorrect results. Such changes will break the build or tests if submitted to the VCS. The simple automatic merge may severely damage product code base over a short period of time:

Viewtier Systems solves the problem of the growing number of branches by offering Automerge, industry's first, ground-breaking technology that delivers verified automatic merges.
Unlike the simple automatic merging, Automerge does not have the problem of semantically incorrect merges. Automerge performs merging by using a new approach developed by Viewtier that we call "verified automatic merge". Built on top of Parabuild, it works as described below.
The essence of Automerge is using the last known clean state of the target codebase and a build configuration associated with it to run a validation build before submitting results of the merge to VCS. Only merge changes that produced a successful validation build are submitted to VCS. Automerge may or may not use the known clean state of the source code base to select changes to merge. In detail, automerge:

As of this writing, automatic integration is available for Perforce SCM. Support for other VCSs is under development.
Automerge has a Web UI that shows what is merged and what is not, also known as integration report, and status of the automatic merge queue.
All Automerge configuration is done through the Web user interface as well.
Engineers and CM managers can control what to merge by using automatic merge markers in the change submission messages, by setting Automerge to merge all changes, or by using nag messaged instead to notify owners of changes that they have to do their merges manually.
Automerge technology is a part of Parabuild. It is available through the Early Access Program For Parabuild 3.2.
Check this technical note to get started with Automerge.