How to manage multiple versions of a product with Mercurial?

Question

My company's product is module-based, meaning we ship with five base modules and users can purchase additional ones. We're using Mercurial, to which we are relatively new, for our source control, and since we've released 1.0 of our product, managing the separate module development has been a nightmare.

We want to be able to release minor bugfix updates without having to wait for particular module development to be complete, so one repo for everything doesn't work very well. I read about branching but the Definitive Guide seems to suggest that branching is temporary, and that merging with it is difficult.

Ideally, we'd have a base repo that is the product and then different repos (or branches) with the extra modules, so that QA could build the main product and the main+addons separately, while the developers working on ModuleA don't impact the developers working on BugfixB. I tried this with multiple subrepos but it ended up corrupting my repositories.

Should I be looking at using named branches? Or bookmarks?

I'm looking for suggestions on best practices on how we can take advantage of Mercurial's features to make this process easier.

Thanks!

Answer 1

I am new to Mercurial as well, but I think that your problem is not specific to it. You need to think about the process of releasing code and the parties involved, and map this model to a branch layout that can support it. Mercurial is nice because it can support developers well, by allowing them to maintain their own development "branches" without affecting a continuous build or other downstream processes (QA, installers, etc).

                            [Rel]

                               ^

                             [RC]
                               ^

            [QA]----[QA]------[QA]
              ^       ^        ^

[Dev]---------------------------------------------------------

       ^          ^          ^
      [Jen]      [Paul]    [Ken]

this is a possible scheme, where developers merge to Dev, and somebody merges regularly to the [QA] branch, and when that it baked nice goes to [RC] etc. Every release stays isolated from other activity.

Good Luck!

Answer 2

There is a good tutorial about branching at http://nvie.com/git-model. The main point is to have

• a release branch which contains only merges from completed release/bugfix branches
• development branches for bug fixes or features
  • own branches for long-term features

Also there is a reference about the technical differences in mercurial branches at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 3

Branching is your solution. I consider named branches to be a Good Thing. However, you should be aware that named branches require a certain level of forethought and discipline in use.

I would suggest that each bug-fix gets its own branch. Developers will fork off that branch, do the bugfix, merge back into the feature-branch.

I would consider splitting your modules into separate repositories, one for each product. Possibly that's not very useful; you'll have to go over different use cases there and determine how the workflow/compile-flow would go.

Answer 4

I don't see why you'd consider having different subrepos for this when the file history is virtually the same throughout - this is a prime job for branches. The only complication is being able to cherry-pick patches for each branch - that may require you to export a patch (or set of patches) and apply them individually to each branch. It's a bit more awkward than it should be, but it's no harder than doing the same across different repositories.

Answer 5

I think the question blurs two different issues:

1. You have a modular product
2. You have separate development cycles for each module

For handling the modular product you should use different repositories for each module and bring them together using subrepos as appropriate for each customer configuration. It appears you're already doing this but are having corruption issues. This is certainly the correct way to go so you need to bottom-out whether the corruption is coming from a Mercurial bug or user error.

For handling separate development cycles then personally I'd go for module clones but named branches would also be fine.

Hope this helps.