Mercurial workflow for ~15 developers - Should we use named branches?

My team's just starting out with Mercurial and a central repository. We have Hudson building the tip of the "default" branch - which is basically our mainline. We had a check-in policy with our old VCS that code reviews, testing, etc. must be done before you check-in to the mainline.

So, let's say you are working on feature X. You work on some stuff, basing it off of "default", and then you commit a partial feature as a checkpoint. Locally your "default" is now broken -- you haven't shared it with anyone yet, but if you were to do a push, well now you've got broken code in mainline.

Even if you wait to push until you've got it all sorted out, it seems like there are situations (e.g. working on two things at开发者_开发技巧 once) where you'd need to push some changes but not all.

Additionally, if you check in all your checkpoint changes, then there will be some revisions in mainline that build, and others in mainline that don't build.

We have started using named branches - but the more reading I do the more I think we're mis-using named branches.

Any suggestions on how to setup a good workflow that allows us to run Hudson and keep our mainline policy?

First, I highly recommend A Guide to Branching in Mercurial

Next, you could push just the current branch: Nudge - A Gentler Version of Push

And maybe you could decide to allow only a head per branch: 32. Prevent a push that would create multiple heads

Other SO questions related to named branches:

• Mercurial: Named Branches vs Multiple Repositories
• Mercurial repository layout for multiple branches

You might consider at least two repositories. The "mainline" repository has your tested and reviewed code. Code is only pushed to this repository after Hudson has tested it and after whatever reviews you do have been completed. The "testing" repository would be a clone of the mainline. This is the repository that Hudson monitors, so that whenever a changeset is pushed to the testing repository, Hudson tests is. You can probably set up a Hudson build step that pushes changes from the testing repository to your mainline if the tests pass.

Developers always push to the testing repository, but only pull from the mainline, so they only ever pull in tested code. If they need to share untested changesets, they could push/pull directly between each other's local repositories. Maybe it is possible to configure Hg to so that the mainline only accepts pushes from the testing repository, so that developers can't accidentally push to mainline instead of testing.

It might be good to have a review repository as well. So developers push to testing, Hudson pushes tested code to review, and then reviewed code is pushed to mainline.

Disclaimer: I have only used Hg on trivial projects and in trivial ways.

What we do in my company is use named branch to distinguish the stable version (on which we only commit bug fixes) and the next version on which the development happens and we backport fixes from stable to default on a regular basis (with hg merge stable on the default branch).

For code review we use the mq extension to enable the developers to submit clean patches. And developers can pull from each others repositories, without polluting the reference repository.

Disclaimer : we don't use Hudson.

It's a question of mindset. The distributed VCSes don't require you to keep a single central repository.

Rather than having mainline open to all to check into, set it up with limited write access. Only changesets which have been approved (tested, signed off, whatever makes sense for you) are incorporated into mainline.

How you manage getting changes into mainline is then a wide open question with many possible answers. Here are two off the top of my head:

• Developers could push freely to a central "testing" repo, from which changes are reviewed.
• Have developers publish changesets on their own workstations (remember, branches are cheap) and have the mainline review process pick them up directly from there.

You could also consider using the Bookmarks extension instead of named branches.

If you're familiar with git, bookmarks behave like git-branches instead of mercurial branches.