Differences between revisions 19 and 20
Revision 19 as of 2011-01-23 22:27:50
Size: 5944
Editor: ArneBab
Comment: Added approval management, Auditing and QA workflow.
Revision 20 as of 2011-01-23 22:31:58
Size: 6006
Editor: ArneBab
Comment: Added a Table of Contents and made the structure more flexible (Flow instead of local flow and sharing flow)
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This site serves as node for gathering useful workflows.  This site serves as node for gathering useful workflows.
Line 3: Line 3:
If you use a workflow which isn't yet listed here, please add it.  If you use a workflow which isn't yet listed here, please add it.
Line 5: Line 5:
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.  <<TableOfContents(3)>>

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.
Line 11: Line 13:
With Mercurial you can use a multitude of different workflows. This page shows some of them, including their use cases.  With Mercurial you can use a multitude of different workflows. This page shows some of them, including their use cases.
Line 13: Line 15:
It is intended to make it easier for you to create your own workflow.  It is intended to make it easier for you to create your own workflow.
Line 15: Line 17:
We begin with standard workflows and then go on to more complex examples.  We begin with standard workflows and then go on to more complex examples.
Line 17: Line 19:
The initial workflows come from the [[http://bitbucket.org/segv/hg-website/wiki/Workflows|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 initial workflows come from the [[http://bitbucket.org/segv/hg-website/wiki/Workflows|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'').
Line 25: Line 27:
 * What do you need? -> Which resources and extensions? 
 * Single Developer workflow -> What do you do?
 * Sharing changes -> How does your team interact?
 * What do you need? -> Which resources and extensions?
 * Flow -> How to use this practically. Optionally split into
 
* Single Developer workflow -> What do you do?
  * Sharing changes -> How does your team interact?
Line 32: Line 35:
 * Complex workflows, including collaborative patch development and similar. 
 * Smoothing workflows with extensions -> i.e. shelve before merging. 
 * Complex workflows, including collaborative patch development and similar.
 * Smoothing workflows with extensions -> i.e. shelve before merging.
Line 38: Line 41:
General:  General:
Line 45: Line 48:
Collaborating on features:  Collaborating on features:
Line 50: Line 53:
Dependency tracking:  Dependency tracking:
Line 60: Line 63:
Working with other vcs:  Working with other vcs:
Line 63: Line 66:
Neat tricks for smoothing workflows:  Neat tricks for smoothing workflows:
Line 74: Line 77:
If you just want to submit a short patch to a project, this workflow is right for you.  If you just want to submit a short patch to a project, this workflow is right for you.
Line 78: Line 81:
You need just Mercurial (command line) and an email address to which you can send the patch.  You need just Mercurial (command line) and an email address to which you can send the patch.
Line 103: Line 106:
Note: "tip" is the most current revision in your repository. ''hg export'' exports all selected revisions as ''one change''.  Note: "tip" is the most current revision in your repository. ''hg export'' exports all selected revisions as ''one change''.
Line 107: Line 110:
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.  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.
Line 109: Line 112:
The developer will then import and test it:  The developer will then import and test it:
Line 116: Line 119:
Now he has the revision in his local repository. He can test and push it.  Now he has the revision in his local repository. He can test and push it.
Line 118: Line 121:
Note: You can also use ''hg import'' on a maildir file. It will automatically select and import the patch.  Note: You can also use ''hg import'' on a maildir file. It will automatically select and import the patch.
Line 122: Line 125:
You can also upload the patch, for example to a bugtracker. It's just a simple file after all.  You can also upload the patch, for example to a bugtracker. It's just a simple file after all.
Line 128: Line 131:
For people who want to work as in CVS, but with added Mercurial benefits.  For people who want to work as in CVS, but with added Mercurial benefits.
Line 146: Line 149:
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]].  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]].
Line 150: Line 153:
This workflow uses the default branch for development, as well as a QA named branch and a release branch.  This workflow uses the default branch for development, as well as a QA named branch and a release branch.
Line 152: Line 155:
The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.  The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.
Line 154: Line 157:
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.  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.
Line 186: Line 189:
If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.  If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.

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?

  • Flow -> How to use this practically. Optionally split into

    • 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

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.

Workflows (last edited 2020-01-16 06:21:28 by aayjaychan)