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

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.

1 Thanks, the first link was pretty helpful - hadn't seen that before. The author mentions some of the same concerns I have, but seems to see the benefits in named branches. Perhaps I can make that work with the stable/unstable idea.

– Joe Schneider Mar 1 '10 at 10:38.

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.

1 I think this strategy could work even within a single repo, but just using a stable and unstable branch. Developers only commit to unstable, and once the tests pass it is merged to stable. Have to think that through a little more... but this is the idea I keep coming back to.

– Joe Schneider Mar 1 '10 at 10:41.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.