annotate text/workflows.txt @ 135:8d069bba8cce

learning in workflows: shared server now contains a bit more information for people with existing servers.

= 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 basic Mercurial usage compatible with 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: 

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

collaborating on features: 
* Shared repo + named branches and bugzilla for feature development
* centralized with attic
* 

Dependency tracking: 
* Dependency tracking
* Snapshots

Special usages
* 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: 
* bundle incoming

-->

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

...