Work with individual functions using Mercurial

Question

We have a team of 10 developers who work in parallel for different functions, sometimes these functions use common code once there. And now we are changing our process to industry-by-function, and it seems that the use of mercury is more acceptable for such developments.

I see this process as follows: 1. create a default release (rb) branch (trunk) 2. create a default function (fb) branch (trunk)

When a developer believes that his function is complete, he can combine fb into rb. When the time comes to switch to QA, we can combine all the ready-made fb into rb and create an issue for our QA.

Questions:

• When the QA discovers that the error developer must change its fb and merge it with rb again. Does this mean that the developer simply switches to his fb and starts fixing the error, and then again simplifies the merging of fb with rb?

• When the release is passed to QA, it goes to PROD - how can we freeze the change? "hg tag" is a good choice, but someone can update the tag if they really want it.

thanks

Answer 1

If you intend to merge into separate release branches, your function branches should be forked from the release branch, and not from the trunk. It is easier to merge with the parent branch than with the child branch.

1) If you really want to use function branches, each error will have its own branch. This will help keep bug fixes separate from new features. In the end, it does not require branching for each developer.

2) I use the Hg tag. You are right that someone changes the tag if they really want it, but the tags are versioned, and you can set interceptors on the main hg repository to trigger warnings if the tag moves. I really would not worry about moving tags if you cannot trust your developers, in which case you are screwed.

Answer 2

The answer to your first question is yes.

The best way to freeze an issue is to have a separate version clone that only the release manager can push / pull a set of changes. Just because you use branches does not mean that multiple clones do not have a place in your workflow. Have a clone that QA does the final pre-flight testing, which developers cannot push changes to, makes a large firewall.

Also, consider using bookmarks for your branches. Since, as I am sure, you know, the names of the named Mercurial branches never disappear, git bookmarks are like sketches like functions and errors.