Diff for "Workflows"

This site serves as node for gathering useful workflows.

If you use a workflow which isn't yet listed here, please add it.

And if you use a workflow very similar to one of the workflows here, but with distinct changes, please add a note to the modifications section of the existing workflow.

But if you search for quick hints to some issues, please have a look at the Tips and tricks page and at the list of extensions. Also there is a page with hints for working practices.

Intro

With Mercurial you can use a multitude of different workflows. This page shows some of them, including their use cases.

It is intended to make it easier for you to create your own workflow.

We begin with standard workflows and then go on to more complex examples.

The initial workflows come from the workflow collection in the wiki for http://mercurial-scm.org - would you like to help us convert one of the remaining ones to this page? (please delete this line, as soon as all workflows are transferred).

The workflows on this page are rather terse to give you a good overview. You can find a longer introduction which shows basic Mercurial usage compatible with these workflows in learning Mercurial in workflows.

Structure or a workflow

• For whom? -> Why and what does it gain you?

• What do you need? -> Which resources and extensions?

• Single Developer workflow -> What do you do?

• Sharing changes -> How does your team interact?

Sorting of the entries

• Simple workflows without extensions.
• Complex workflows, including collaborative patch development and similar.

• Smoothing workflows with extensions -> i.e. shelve before merging.

Overview and plan

General:

• One-off patch submission
• Lone Developer + laptop + publish
• Simple shared push repository for small trusted teams
• Several pull repositories with integrators for security and large teams
• Personal incoming, outgoing and feature clones

Collaborating on features:

• Shared repo + named branches and bugzilla for feature development
• centralized with attic
• patch branches (pbranch)

Dependency tracking:

• Dependency tracking
• Snapshots

Special usages:

• Working with big binary files
• Tiered web development
• Offsite working on dynamic websites
• automatic trusted group of committers for optionally anonymous repositories

Working with other vcs:

• Dealing with CVS

Neat tricks for smoothing workflows:

• bundle incoming
• shelve before merging

Workflows

One-off patch submission

For whom?

If you just want to submit a short patch to a project, this workflow is right for you.

Requirements

You need just Mercurial (command line) and an email address to which you can send the patch.

Local Flow

First get the repository

$ hg clone http://hg-scm.org/hello

Now edit the files and commit your changes

$ cd hello
$ (edit files)
$ hg add (new files)
$ hg commit -m 'short description of the changes'

Export your patch

$ hg export tip > patch.diff

Note: "tip" is the most current revision in your repository. hg export exports all selected revisions as one change.

Sharing changes

To share your changes, just send the file patch.diff to the developers email address, ideally with a description what your patch does and why it's important.

The developer will then import and test it:

$ cd hello
$ hg import patch.diff

Now he has the revision in his local repository. He can test and push it.

Note: You can also use hg import on a maildir file. It will automatically select and import the patch.

Modifications

You can also upload the patch, for example to a bugtracker. It's just a simple file after all.

CVS-like Workflow

For whom?

For people who want to work as in CVS, but with added Mercurial benefits.

Requirements

Only Mercurial.

Workflow

• CvsLikePractice

Approval Management: Auditing and QA

For whom?

If you need explicitely approved code history with a full track record using a team of developers and a seperate QA team, this workflow might be right for you.

Requirements

You need just Mercurial (command line), a shared repository for exchanging data (a simple SSH-server suffices, as does a single private bitbucket repository) and the GPGExtension.

Flow

This workflow uses the default branch for development, as well as a QA named branch and a release branch.

The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.

When QA finishes applying their changes, they first of all merge back into default (so that developers work on the QA version) and then merge into release, GPG signing the merge commit.

Developer

hg pull # get the latest changes
hg update
hg commit -m "<what I did>"
hg update -C QA
hg merge default
hg commit -m "merged default branch for QA"
hg sign
hg push

QA

hg pull
hg update QA
hg commit -m "QA fixes"
hg update -C default
hg merge QA
hg ci -m "merged QA fixes back into the development branch"
hg update -C release
hg merge QA
hg commit -m "merged finished QA into release"
hg sign

Modifications

If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.