Simulating dynamic inheritance in Plastic SCM 4 (or almost so)

Simulating dynamic inheritance in Plastic SCM 4 (or almost so)

Tuesday, June 26, 2012 Ma Nu branching 1 Comments

As you know, the old dynamic inheritance is not available in Plastic SCM 4. It was a Plastic SCM 3 feature that was cool, but hard to understand, so it was overlooked by a large number of development teams.

How it worked

The child branches created with dynamic inheritance didn't have a static branch base; the base was always changing as soon as its parent branch was.

Plastic SCM 3 dynamic inheritance

This was very useful when, for example, the core system code was modified in the main branch. Then all the child branches had the change introduced automatically with only performing an update operation.

Inside Plastic SCM 4, the same behavior can be easily achieved by merging the last main changeset into the task branches, but we have to admit that this is a manual operation and in a huge environment with a lot of developers the periodical merge operation can be easily forgotten.

That being said, it seems that the dynamic inheritance was a really powerful feature. Indeed it was, but let's see the not-so-pretty side too.

Dynamic inheritance weak points

It was slow. The workspace resolution was an expensive operation.
Very complicated to use and understand for a regular user.
It was really easy to end up with completely wrong or broken code.
You were never able to be 100% sure of a changeset configuration. It was "selector-depending".
The distributed scenarios were complete madness.

Simulating the strongest part

Having the "core" code changes automatically applied in the working branch was great, now using the new "merge-to" feature we can get it back.

The "merge-to" feature is able to perform merge operation on the fly, without having to change the current working branch and merge it manually. We are able to use the Branch Explorer and say, "Merge this branch with this other branch," and the merge is done in the server. Obviously the merge operation must be automatic, both contributors merges are not allowed. This restriction was also present in the Plastic SCM 3 dynamic inheritance system.

After check-in trigger

I'm going to simulate the dynamic inheritance system using a c# trigger. This trigger will be monitoring the check-in operations affecting our desired branch -- in this case the /main branch. Every time we have a new changeset in the /main branch the changes will be merged-to the target child branches. We will use an after-check-in trigger.

Trigger workflow

This is how the main method of the trigger code looks:

        static int Main(string[] args)
        {
            try
            {
                TriggerParams parameters = GetExecParams(args);
                ArrayList childBranches = GetChildBranches(parameters);
                MergeToBranches(childBranches, parameters);
            }
            catch (Exception e)
            {
                Console.WriteLine("Error executing trigger : " + e.Message);
            }

            return 0;
        }

These are the parameters we need to run the trigger:

1. The branch name we want to track for new changes.
2. A workspace path to issue the Plastic SCM operations.
3. A file where the trigger output is going to be written.
4. A mapping file for email notifications (optional).

The last one is optional, but very interesting, since it will allow us to specify a list of branches that we want to set as the destination of the merge-to operation. We can also add emails to notify developers that the branch can't be auto "merge-to" and a manual merge is needed, the file format is "branchName#email". Here is an example: 

...
/main/scm003#iamamaddeveloper@gmail.com
/main/scm004#mlucio@codicesoftware.com
/main/scm005
/main/scm006#theCrazyDev@codicesoftware.com
...

If the merge-to can't be accomplished, an email will be sent if there's any specified for the branch. If no custom branches file is provided, the merge to operation will be applied for all the child branches of the tracked branch.

Results

Here you can see how the automatic merges are done by the trigger:

Branches auto-updated with /main branch changes

And if something can't be merged in an automatic way the developer will receive an email warning about the situation:

E-mail sent by the trigger warning the develop to merge manually the main branch changes

Download

HERE you can download the code. Enjoy it!

Manuel Lucio

I'm in charge of the Customer Support area.
I deal with complex setups, policies and working methodologies on a daily basis.
Prior to taking full responsibility of support, I worked as software engineer. I have been in charge of load testing for quite some time, so if you want to know how well Plastic compares to SVN or P4 under a really heavy load, I'm your guy.
I like to play with Arduino GPS devices, mountain biking and playing tennis.
You can find me hooked to my iPhone, skate-boarding or learning Korean... and also here @mrcatacroquer.