views:

82

answers:

2

Hi, I'm in a team of 15 developers currently using Allfusion Harvest. We're not happy with it and looking around we've decided to switch to Mercurial due to the available frontends TortoiseHg and MercurialEclipse.

We're currently using a twelve year old release of Harvest and I find our current workflow hard to translate to Mercurial. I have previous experience with ClearCase where we used a model similar to:

A  A  A
|  |  |
B  C  |
| /|  |
C  |  E
|  | /  
D  E
| /
E

Where the left trunk is unstable, middle is test and right is stable. Now I have no problem recreating this branching model in Mercurial (in one central repository). The idea is that the developers then clone this repository, branch out from unstable, do their work and then merge with unstable. Reading on the web I've yet to see a Mercurial work flow aimed at teams larger than three developers so I'm unsure if this is a good workflow.

So two questions:

Is this a good working model?

How do you work with Mercurial and how many are there in your team?

A: 
  • Insofar as I know, your workflow is quite fine.
Paul Nathan
+2  A: 

Here at Fog Creek, we use a similar workflow, with one major difference. Because there aren't really lightweight branches in Mercurial (named branches keep their name, even after being merged) we tend to use multiple repositories for our branches. I've found that this makes it easier to know which branch you're working on, and also makes it harder to accidentally merge between branches, since each of your branches could have ad-hoc branches of its own.

Instead, we have Stable, QA, and Devel repos that we work with. Feature work goes into Devel and merges up to QA and Stable, while bug fixes go into Stable and QA, and are merged back into Devel.

A lot of our devs also keep their own branch repos for longer running projects, or anything that they're working on that might break someone else's code.

Some of our devs have each branch in a different directory, so they are explicitly switching from one to another. Others prefer to pull all three into one repo, using the remote-branches extension to manage the various heads.

This did give us a bit of trouble when we were using the basic hg serve to host our repos, since creating a new devel repo or renaming repos required a sysadmin. That's part of why we made it so anyone can create branch repos in Kiln.

It would be nice if Mercurial had a better branching model, and there is some work going on to help with that, but this is what works for us.

tghw
So does your QA department check out the tip of the QA repo, and build their own binaries to test?
mos
Depends on the product, but yeah, testing builds are cut from the QA repo.
tghw
Thanks, I'm trying out the workflow and notices that Mercurial forces me to perform a forced push since the recipient repository will get multiple heads using the above workflow. It feels like there's something wrong with the workflow when I get a warning? Unstable, Stable and Test each has a head now...
MdaG