Pushing to the development and maintenance branches

With the release of OpenSAF 4.1, the repository and branching mechanism changed a bit. Separate repositories won't be created for each maintenance release anymore. Instead,  named branch will be created on the main repository (opensaf-staging). This will simplify the release management and changesets transplanting to keep each branch in sync.

This page explains the various use cases for using Mercurial from now on when pushing new changes.

Pushing a new feature

This use case didn't change. When you clone 'opensaf-staging' the 'default' branch is the active one, this is where all new feature development occurs.

The only new thing to watch is to make sure that you are really on the 'default' branch when committing you new features:

$ hg branch
default

The 'hg branch' command without parameter will show the current branch name.

The 'hg branches' command will list the repository's named branches:

$ hg branches
opensaf-4.1.x               1941:b21de4b9dfff
default                     1940:7e0233028a5d (inactive)

A branch is considered active if it contains repository heads. If 'default' is labeled as 'inactive' it could be a sign that something was pushed to named branches, and not propagated to 'default' which shouldn't occur if developers are properly transplanting maintenance changesets to 'default'.

If you are not on the appropriate 'default' branch, to switch branch use the 'hg update' command:

$ hg update default
$ hg branch
default

Pushing a changeset for maintenance

Until all external maintenance repositories (e.g. opensaf-4.0-bugfix-staging) are no longer maintained, two use cases will exist to push for maintenance.

This is no longer true, since 'opensaf-4.0-bugfix-staging' has been transplanted to a named branch (opensaf-4.0.x) on 'opensaf-staging'. If you need to fix things in 4.0.x, simply pull the latest 'opensaf-staging' and switch branch:

$ hg update opensaf-4.0.x
$ hg branch
opensaf-4.0.x

Work on your 4.0.x bugfix from here and stop using http://devel.opensaf.org/hg/opensaf-4.0-bugfix-staging which is now read-only.

Pushing to maintenance named branches

Starting with OpenSAF 4.1, the maintenance fixes will be pushed to a named branch within the 'opensaf-staging' repository. Before committing/transplanting make sure that you are on the proper maintenance named branch:

$ hg update opensaf-4.1.x
$ hg branch
opensaf-4.1.x

From here, commit, review, push as usual. Don't forget to switch back to the proper named branch for other work if needed.

Transplanting maintenance changesets

When working on a defect, several things require to be handled more carefully from now on. The first thing to consider is 'where' this defect could also easily occur? Defect report shouldn't be parsed like a robot, taking the values in Version/Milestone? as the only truth. Given the nature of 4.0.x, 4.1 and now 4.1.x, an IMM or AMF defect (as an example) could in fact be present in all those releases since they are relatively similar. Use common sense and good judgment here.

Defect must be resolved on the lowest common denominator first and then  transplanted 'above'.

For example, I'm fixing an AMF issue found during development of 4.2.BX, assuming this defect is totally legit on 4.0.x and 4.1.x too, I will be fixing it on the 'opensaf-4.0.x' branch first and then transplanting to 'opensaf-4.1.x', and of course always to 'default' branch.

A good indication that a patch should be considered for propagation or not is that no major hunk failure occurs (or with simple merge cleanup).

Here's a potential workflow step by step:

$ cd opensaf-staging
$ hg pull
$ hg update opensaf-4.0.x
$ vi some_bad.c
$ hg commit -m "fix some bad code"
$ hg push ssh://someone@devel.opensaf.org//var/www/hg/opensaf-staging

Let's assume the commit above created the changeset '1000'. Now I want to propagate this changeset to branches 'opensaf-4.1.x' and 'default', by starting with 4.1.x:

$ hg update opensaf-4.1.x
$ hg transplant 1000
searching for changes
applying aaaaaaaaaaa1
aaaaaaaaaaa1 transplanted to bbbbbbbbbbb2
$ hg push ssh://someone@devel.opensaf.org//var/www/hg/opensaf-staging

Note that it is possible to get some minor merge conflicts when transplanting, clean the hunk failures and then resume with 'hg transplant —continue'. Now that this fix has been propagated to a similar branch, it will be a freebie to transplant on 'default':

When '1000' was transplanted from 'opensaf-4.0.x' it received a new changeset id within 'opensaf-staging', let's assume it was changeset '1001'. Changesets id are unique across all named branches in the same repository, so the transplant operation doesn't need a source branch:

$ hg update default
$ hg transplant 1001
searching for changes
applying bbbbbbbbbbb2
bbbbbbbbbbb2 transplanted to ccccccccccc3
$ hg push ssh://someone@devel.opensaf.org//var/www/hg/opensaf-staging

You now have propagated an important fix to 3 different branches without much efforts.