How to manage concurrent development with mercurial?

Question

This is a best practice question, and I expect the answer to be \"it depends\". I just hope to learn more real world scenarios and workflows.

First of all, I\'m talk

Answer 1

It seems like there's no more or better choices than the ones I listed in the question. So here they are again.

1. Use one clone per project.
   • Pros: total separation, thus no rebuild when switching projects.
   • Cons: toolchain needs to switch between two clones.
2. Use anonymous or named branches, or bookmarks, in the same repository.
   • Pros: standard hg (or any DVCS) practice; clean and clear.
   • Cons: must commit before switching and rebuild after.
3. Use MQ with one patch (or multiple consecutive patches) per project.
   • Pros: simple and easy.
   • Cons: must qrefresh before switching and rebuild after; tricky and risky if projects are not orthogonal.
4. Use one MQ branch (or qqueue in 1.6+) per project.
   • Pros: ultra flexible and scalable (for the number of concurrent projects)
   • Cons: must qrefresh and qcommit before switching and rebuild after; feels complicated.

Like always, there's no silver bullet, so pick and choose the one right for the job.

---

(UPDATE) For anyone who's in love with MQ, using MQ on top of regular branches (#2 + #3) is probably the most common and preferable practice.

If you have two concurrent projects with baseline on two branches (for example next release and current release), it's trivial to hop between them like this:

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r 
hg qimport -r ; {repeat}

For the last step, qimport should add a -a option to import a line of changesets at once. I hope Meister Geisler notices this :)