mercurial team repository / picking and choosing

I have a small team and I would like to do the following:

I have my trunk, I'll just call it TRUNK

Now, TRUNK is a project that's already in production and runnin开发者_Go百科g. Now, the inevitable defects come in, but into bugzilla and are assigned to users.

Each user clones TRUNK to their local repositories and makes changes and pushes them to a directory TRUNK/projects (projects is not a clone of TRUNK, just a regular directory)

Now, the day comes where I want to create a new build called RELEASE and I want to merge some of the bug fixes (not all, just some) into RELEASE.

Notice, I am not committed to the idea of having TRUNK/projects/[bugfixes list], but that's what I currently have now and am more than open to any / all suggestions.

What are some ideas? Is there something I can do / should do differently? Again, I am open to any / all suggestions, including completely changing the above procedure (except for using Mercurial as that's what the company makes us use)

There are two ways to do this and they diverge not at release time, but when you do the bug fixes depending on what parent you give the bugfix changesets. The "good" way uses only push, pull, and merge. The less good way (it's not entirely bad, but it's certainly sub-optimal) is called cherry picking and it has drawbacks. The tricky part is that whether or not you're going to be able to move bugfixes into RELEASE via merge without moving everything from TRUNK into RELEASE is something you have to decide before you make that change.

Here's a really complete answer for a similar question that explains what's going on: Some help with merging legacy branch in Mercurial

The key concept though, is that you can merge a changeset into any branch you want but it brings with it all of its ancestor changesets. So you want your bug fixed to have minimal ancestry. That means fixing a bug not in a new changeset in TRUNK that happens to be the latest feature you added, but instead, first, hg updateing to a changeset that already exists in both your TRUNK and your RELEASE, and there are two great candidates for that. Either:

• the changeset where RELEASE and TRUNK diverged

or

• the changeset where the bug was introduced

My preference is for the later. If a bug was introduced in changeset 666 then every clone, branch, and build that has changeset 666 will want your fix. So when fixing it just do:

  hg update 666
  .. fix the bug ..
  hg commit -m "fixed bug 55" # creats changeset 999 which a new head

Then you can do this:

hg update TRUNK
hg merge 999

and you'll know you're only pulling in a single changeset. Later when you're ready to release you can do:

hg update RELEASE
hg merge 999

and you're again only getting the single changeset you want.

The advantage of this mode of working over cherrypicking (using export/import or transplant) is that your fix exists only once in your repo. If you have 99 different vendor branches for various finicky customers and you want to see if they have the fix for bug 55 you can just do:

hg log -r 'descendants(999) and heads(FUSSYCUSTOMERBRANCHNAME)'

and if there are no results then that customer doesn't have 999 and thus doesn't have the fix for bug 55 in changeset 666. When you re-do the same work with multiple changesets (which is the result of export/import and transplant) that's harder to verify.

Common practice is to create topic branches.

Each new issue/ticket/enhancement is commited into separate branch.

Anytime maintainer wants to make new release he can merge all (or only some) that branches into "default" or even new branch called e.g. "release_1_x".

To be more precise. Developer working on code can still clone repository, then create local branch and finally, after one or more commits to that branch, pushes local changes to one centralized clone (from which every other developer in team can pull/clone again).