CODEWITHSUNDEEP
mercurial
storm
storm

Reputation: 151

mercurial repo with multiple customer branches

My question is similar to: Mercurial branches with different codebase

But the solution given there was to do all the work on the one customer branch and merge it to default. I don't see how that is workable in my case.

I have a project that gets distributed to 4 customers. I've setup a named branch for each customer. What is an effective way of merging changes to common code, while leaving alone some customer specific data and/or requirements?

Edit:

I have customers a,b,c. Machines M,N. and parts 1,2,3,4,5.

Right now I have subrepos a,b,c,M,N,1,2,3,4,5 and repos aM1,aM2,bM1,bN1,... . I am considering having subrepo customer (branches a,b,c). machine (branches M,N). parts (1,2,3,4,5)

Are there techniques for making change propagation easy, but also keeping some differences permanent. Maybe something like this: TipsAndTricks.

Upvotes: 2

Views: 75

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97365

I see at least two possible ways:

  • Customer-specific changes are always in separate changesets, and you move common changes from customer-specific branch into mainline not with merges, but using hg graft, cherry-picking only needed changesets
  • Using MQ extension, you can have customer-specific changes in MQ-patches (patch per customer), applied|unapplied individually on demand and just merge branches

In the last case separate named branches may be not needed at all (you have default and different patch applied for each customer) - at least I moved to this workflow, when I had to maintain a set of clones with only slightly different configurations and merging from default to each branch become boring

Upvotes: 0

elixenide
elixenide

Reputation: 44851

Based on your question and clarifying comment, what you want is both impossible and not really what hg is supposed to do.

Everything I am about to say, I say as someone who has made exactly the kind of mistake you are about to make and who has lived to regret it (and slowly, painfully, try to undo it).

As I said in the comments, this seems like a faulty design. If you want something to be part of a code base only for some purposes, then that's a good indicator that what you really need is one of the following:

  • more configurability to turn features on or off,
  • a custom build script to assemble various versions of the project, or
  • a core code base and several customer- or purpose-specific code bases for plugins and add-ons.

You probably don't want customer-specific functionality---and definitely don't want customer-specific data---in your main project's source tree. Anytime you are about to commit a change that includes either customer configurations or code that only one customer will ever use, you need to step back and ask (1) why it should be in your core project instead of a plugin and (2) what the implications would be if another customer or third party ever got access to it by mistake.

Upvotes: 3

Related Questions