views:

83

answers:

3

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.

Overview

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?

A: 

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.

joeforker
...still looking at your answer, it has several options.
leeand00
It sounds like your initial problem may be merging the customers' repositories with the base repository and manually picking out which bits are newer. In that case you can add all the base files to one repository, add all the customer's files to another, then pull these together and 'hg merge'. It's tedious but with a graphical merge tool you should be able to fairly quickly pick out which bits you think are newer from each side.When you are done, the diff between the base revision and the merge revision should contain all the changes specific to that customer.
joeforker
+1  A: 

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
just somebody
What is the $xyz? Is that an environment variable?
leeand00
yes (to be precise, a shell variable). it's used in the example to abstract away the url or path to the canonical repository for the customer-xyz branch; similarly for `$mainline`. alice's `~/wc/cust-XYZ` is cloned from the repository at `$xyz`.
just somebody
A: 

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.

RyanWilcox