Workflow question, advice...

[Douglas Philips]

I'm starting to prepare some materials to show my group the  
advantages of moving off of CVS and on to Mercurial.

Our current workflow is very parallel and it works because developers  
are off on their own little independent pieces of the world writing  
tests;  the tests are all properly independent of each other.

When I look at what seems to be the natural Mercurial version of that  
work flow, it seems that almost half of our changesets will be  
merges, and those seem to be pretty gratuitous from the old (CVS)  
point of view. (i.e. not a good selling point for hg.)

Let's say I have 5 developers, all working on different tests. 95% of  
the time their changes are confined to their own small part of the  
tree. 5% of the time they are changing the testing support  
infrastructure or making adaptations to product changes.
But, 95% of the time, their changes are orthogonal.

In the CVS workflow, they could commit without interference.
In the Mercurial workflow, if they all work in parallel, then only  
the first pusher avoids making a new head in the stable tree.
Everyone else has to pull the new stable head, merge and re-push.
Not only does this almost double (or more) the number of changesets,  
but it gives a very unscalable process, as more developers are added,  
the higher the chance for any given push-attempt that another  
developer has pulled, merged and pushed and you have to do that -- 
again--.

What am I missing, how should I structure the workflow to avoid this  
increase of changesets and the re-re-remerging problems?

Thanks,
	--Doug

P.S. Back when I used darcs this problem was a no-op because  
independent changes commuted and no merging events were needed, but I  
gave up darcs a year ago because of the unpredictable exponential  
problem. I've since come to like Mercurial and TortoiseHG and all the  
other nice things they can do that darcs still can't.