0

This question is an exact duplicate of:

We have a very large code base in mercurial. We have about a 6 month release cadence with 2 week sprints. For each release we have about 10 feature branches and maybe 5 or so people working per branch.

Now whether or not feature branches are a good idea is a question for another day.

Currently we do merge-downs/copy-ups from feature branches into the main QA line twice during that 6 months - once about 1/2 way through and once a few weeks before the end of the release. (specifically, merge-down from qa, then feature branch copies up).

The reason seems not to keep in sync with each other, but to enable some testing about half-way through the release.

This has caused a lot of angst about looming merges and a few nasty merge conflicts, but not as many as one might expect.

So I guess my questions are:

-Would having more frequent merges just for the sole purpose of keeping things in sync and preventing surprises create more churn or less churn?

-If so, what would be a good schedule? I've thought about this a bit - more frequent merges would require teams to have their code in good shape more often, which might not be a bad thing. Too often though might spread bugs around to all feature branches before they get a chance to be fixed.

We're using Hg, but I'm adding git as a tag because I think the issues are pretty much the same.

merged by ChrisF Apr 16 '15 at 20:50

This question was merged with What is a good frequency for merging up feature branches to a main line? because it is an exact duplicate of that question.