Workflow with per-customer branches/patches

[Mads Kiilerich]

Mike Noordermeer wrote, On 05/14/2010 10:10 PM:
> Hi,
>
> I'm trying to find the correct workflow to use for a Java web project 
> (jsp & servlets).
>
> We have one codebase, but multiple customers who all need their own 
> configuration and styling (html/CSS/images etc.). For that it seems 
> appropriate to have one main/dev repository, and a repository(/branch) 
> per customer.
> This way we are able to develop in the main repository and push the 
> changes to the customer repositories. Customer specific changes can be 
> developed in the customer repositories.
>
> My main problem arises when a customer wants to submit a patch (using 
> hg push to their repo). We then need to merge this in the main branch, 
> but we don't want the customer specific changesets. Current idea is to 
> use hg transplant to pick the specific changesets we want, but doesn't 
> this cause problems when we transplant from repo2 to repo1, and then 
> push from repo1 to repo2 again?
>
> Any ideas on a good workflow for this situation? Seems to me more 
> people should have the same problem (per customer configuration and 
> styling of a generic application)

It seems like you don't have release branches - and the situation is 
thus different from what I was rambling about in 
http://selenic.com/pipermail/mercurial/2010-May/032074.html.

It is more like you have a stable mainline which continually improves, 
and occasionally you want to propagate all changes from the mainline 
down to customer-specific branches? You do however not want to propagate 
all changes from the customer-specific branches to the mainline?

Like you suggest I would propose that you pull/push/merge from the 
mainline to the customer branches ... if and whenever that is what you 
really want to do.

You should however never pull/push from customer branches to the 
mainline. You can carefully transplant changesets from customer branches 
to the mainline - or simply use plain export/import. The merge back 
again will be trivial in most cases when premerge is enabled, but as 
with all merges there might be real hard conflicts.

I think that the main challenge with a workflow like the one you 
describe is that you have two dimensions: Stable releases from the 
mainline (I assume) and the customers specific changes that have proven 
their correctness (in the old context). From one point of view it could 
be nice to incorporate all customer changes in the mainline somehow and 
have traditional release branches. That might not be feasible and leaves 
you with a different and slightly less elegant workflow. In my opinion.

/Mads