Merge Branches

In most development projects, there exists a critical need to reduce cost, effort, and time-to market of developed products. However, at the same time, customers are requesting more and more quality products tailored to their individual needs.

A typical approach followed in industry is to base new projects on the results of a previous project. This kind of ad-hoc reuse is inherent to human problem solving: if there are known existing solutions they are used, otherwise similar solutions are considered and adapted, where reasonable. Only if there are no similar solutions available is the product is developed anew. Obviously this saves time and effort during the initial development of the solutions.

However, the typical problems that arise during the "clone & own" development of several, possibly similar, products are well known:

• The same functionality is developed several times for different products or customers.
• The same changes must be repeated for different products.
• Identical features behave differently depending on the particular product.

The first option (depending on the number of projects/products) is to clone the projects, but still be able to merge changes and define the common platform. But this doesn't tend to scale well.

The solution that scales, that enables organizations to create, exploit, and develop a family of related products at lower cost, reduced time to market, and better quality is called Product Line Engineering. It partially eliminates the need to merge changes through an approach where the variant specifications are generated fully from the aggregate of all specifications (sometimes called 150% specifications).
[Learn more]

Many organizations, however, follow a balanced approach where common aspects (shared by 100% of products) as well as shared parts (shared by some products) are supported in the product line library, but single product-specific requirements are managed in variant branches. In this case, you need to be able to merge changes to the library (if another product needs them) or merge the changes from the master specification (as you cannot regenerate the full document).

Feature: Merge Changes

The scope of this new 2016 feature is to enable users to merge changes easily with a handly visual interface. You can:

• Merge a branch-specific changes into a master specification.
• Selectively distribute (merge) changes from a master specification to branched specifications.

After researching many customer environments, we designed the branching of specifications to be different from the branching of source code.

Why are specifications (requirements, design, test) different from code?

• Items contains metadata: safety categorization, priority, ownership, etc. Each of the attributes might need to be unique per branch, even if the specification (i.e. requirement definition) has to be in sync.
• Items, unlike code, keep a unique identification. The related artefacts (e.g. test cases or design items) are linked globally, not contextually -  in other words, branching should not affect the traceability of the artefacts.

Branching

The Branching feature was introduced back in  2012.

Branching (a.k.a. "LiveBranch") lets you manage variant versions of your requirements and test specification Documents.

• A branched Document contains the requirements specific to your variant and references common requirements contained in the "master" specification.
  
• Refernces can be to the head revision of a requirement, or to any historical revision.
  
  As a result, you can...
  
• Save time managing isolated copies of your documents - no copy/paste on every change of your common specification.
• Control requirements reuse and how granular changes are propagated to your variants... automatically ("live") or on demand.

Compare Branches

In the Polarion 2016 release we have redesigned the concept of comparing documents. The compare view analyzes the “branched from” relationships. What does it mean?

When you compare Documents, if a requirement A is branched into requirement B, you see the item as changed so you can fully understand the changes as if the two requirements were a single unique item.
 

This new view alone boosts the efficiency of change review and change propagation, as you understand the actual changes much better, especially when comparing Document branches.

Merge Branches

In reality, we had to redesign the Compare interface in order to provide you with a stronger tool to help you merge changes selectively from master to branch, or across branches.

The feature scope exceeded everyone's initial thoughts. It had to cover all the possible scenarios, from simple ones such as:

1. You added an item to a master and you want to push a reference to a branch
   
   
   
2. You have overwritten an item in a branch (that is, you branched an individual item) and you want to merge the changes (attributes) back to the master item, and possibly replace the branched item with a reference to the updated master (to limit the number of different items as much as possible).
   
   
   
   
   Merge also needs to handle process conditions such as:
   
   
3. Correct Reference Direction: When you add an item to a branched Document, you do not want to put a reference to the new item in the master Document, as references should always point from branched to master, not vice versa.
   
   
4. Cross-project Branching: When you add an item to a branch in another project, you can copy the item to a master, keeping the items linked, but you cannot move the item, as the ID would change.

You see that we have to consider many user scenarios. Our goal is to support 80% of all the options for the 2016 (GA) release. We need your feedback to help us identify the remaining 20% of cases, as we see that the expectations for how changes should be merged vary vastly customer to customer.