CODEWITHSUNDEEP
mercurialbranching-and-merging
BlaM
BlaM

Reputation: 28858

Mercurial: How to work with two "main branches"

I have a Mercurial repository for a project that has to split to two branches that will share main functionality, but will have differences in some of their functionality:

            ---- B
           /
---source-+----- A

Now I'm wondering how I work with that. 

                          ----- new feature -------
                         /                         \
            ---- B1 ----+ B2 --- B3 ----- bugfix ---+- MERGE ---
           /
---source-+----- A1 ---- A2 ------------------------------------

Let's assume A1, B1, B2, ... and so on are simple changes that are only supposed to appear in the specific branches (update logo, change texts, ...). However I want to have both the "new feature" and the "bugfix" in both branches.

Obviously I can't just merge branch B into A or I would end up with ALL the changes that I made in B in A (but I don't want the updated logo).

So: How do I do that? Do I really have to use a third branch as suggested in this question? That would force me to adapt a completely new workflow.

Another related question suggests transplant and graft. Is that the way to go?

Upvotes: 2

Views: 99

Answers (1)

planetmaker
planetmaker

Reputation: 6044

Either of the two ways you outline yourself is fine - it's more a matter of what you like most:

a) have three branches, one mainline which has everything needed by every project / customer - and two customer-branches with specific changes relative to the mainline which change logos or texts. Mainline receives bug fixes and new features and is regularily merged into the customer-branches. That way they don't "contaminate" eachother.

b) keep it at two branches, one for each customer and graft the changes relevant to both to the other branch.

Choosing a) or b) is a matter of taste and in my opinion more a question of whether you will have more changesets which is shared by both (then 3 branches, less grafting), or whether you have more changesets specific to one branch or the other - then grafting is less work. Probably I'd nearly always choose a), though; it feels "cleaner".

There actually is an option c): merge the two branches into eachother and pay attention when merging that you don't merge the things specific to the other branch. But that's probably very tedious, at least in the long run; mostly it depends on the complexity of the differences and where they are with respect to general changes. If specifics are in their own files, merging and skipping the "wrong" changes during a merge is relatively easy.

Upvotes: 2

Related Questions