annotate text/workflows.txt @ 118:a5c7422e4e4c

workflows, polishing.

= Learning Mercurial in Workflows =

== 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. 

To write this page we gathered [real life workflows](wiki - workflows), so every more complex workflow in here has proven itself in real life usage. We begin with basic workflows and then go on to more complex examples. 

The workflows on this page are rather terse to give you a good overview. You can find a longer introduction which shows how to use these workflows in [learning Mercurial in workflows](learning_mercurial_in_workflows). 

<!--Structure: 
* For whom? -> Why?
* What do you need? -> Resources + extensions
* Single Developer workflow
* Sharing changes. -->

<!-- Plan

* Simple workflows without extensions

* Complex Workflows, including collaborative patch development and similar. 

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


Workflows: 

* One-off patch submission
* Lone Developer
* ... 

-->

== 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. 

==== Flow ====

First get the repository

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

Now do and commit your changes

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

Export your patch

$ hg export tip &gt; patch.diff

And send patch.diff to the developers email address, ideally with a description what your patch does and why it's important. 

Note: "tip" is the most current revision in your repository. 

==== Modifications ====

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

== Lone Developer ==

...