Reputation: 26402
I work on maintaining the same e-commerce web-app for multiple customers.
Originally there was a standard set of pages from which all the rest of the customers customizations were derived in the past.
Recently the place where I work decided to use Mercurial for version control. They've also decided to re-work the standard set of pages for our e-commerce and make them a main-line/base-line of development.
That being said there are existing customizations for each of our customers that were made before the base-line set of pages, which have not been entered into version control (hg) yet.
What is the best way to merge the changes from the base-line of development into a separate line of development for each of our customers while we keep the existing customizations for each customer?
Upvotes: 0
Views: 204
Reputation: 13972
I would - and have - have a common repository and clone that for a new customer. When you have a patch that should go into the common repository -- or a set of patches that need to be applied from the common to a customer's repo -- you could use hg transplant.
Upvotes: 0
Reputation: 19257
What is the best way to merge the changes from the base-line of development into a separate line of development for each of our customers while we keep the existing customizations for each customer?
just like in any other branching scenario. e. g.:
alice ~/wc/cust-XYZ % hg pull -u $xyz
alice ~/wc/cust-XYZ % hg ci
alice ~/wc/cust-XYZ % hg ci
alice ~/wc/cust-XYZ % hg ci
alice ~/wc/cust-XYZ % hg pull $mainline
alice ~/wc/cust-XYZ % hg merge
alice ~/wc/cust-XYZ % hg ci
alice ~/wc/cust-XYZ % hg push $xyz
Upvotes: 1
Reputation: 41817
Depending on how custom you need each project to be, the easiest way may be to have a separate tree of templates for each customer that takes precedence to the base set. As in
base/template1.html
customer/template1.html
For any page, the customer's directory gets searched first. You shouldn't need a lot of version control magic for this, but subrepositories might be convenient.
You may be able to keep track of each customer's changes as a patchset using mq
(Mercurial queues). It can be a bit tricky to merge patchsets.
You could do the same thing with rebase
, potentially more elegant than mq
, but I'm not sure how to share rebase sets.
Or you could simply keep a base repository and separate repositories from each customer that are never pulled back into the base.
In each case, your life (merging) will be much easier if you organize your project so the per-customer customizations are confined so they are less likely to conflict with changes to the core product.
Upvotes: 0