# HG changeset patch # User Arne Babenhauserheide # Date 1242253763 -7200 # Node ID 99bfbce775b0e68beeecbad2eccf0bd41efa2245 # Parent 9d7df1cd39d3311764f94a229074cec78fdac534 workflow guide: use

,

, h3> and

in the guide (

doesn't really show) diff -r 9d7df1cd39d3 -r 99bfbce775b0 hgscm/templates/workflow_guide.html --- a/hgscm/templates/workflow_guide.html Thu May 14 00:22:20 2009 +0200 +++ b/hgscm/templates/workflow_guide.html Thu May 14 00:29:23 2009 +0200 @@ -15,17 +15,17 @@

Note: This guide doesn't require any prior knowledge of version control systems (though subversion users will likely feel at home quite quickly). Basic commandline abilities are helpful, because we'll use the commandline client.

-

Basic workflows

+

Basic workflows

-

Log keeping

+

Log keeping

-

Use Case

+

Use Case

The first workflow is also the easiest one: You want to use Mercurial to be able to look back when you did which changes.

This workflow only requires an installed Mercurial and write access to some file storage (you almost definitely have that :) ). It shows the basic techniques for more complex workflows.

-

Workflow

+

Workflow

Prepare Mercurial
@@ -100,9 +100,9 @@
$ hg log -p -r 3
-

Lone developer with nonlinear history

+

Lone developer with nonlinear history

-

Use case

+

Use case

The second workflow is still very easy: You're a lone developer and you want to use Mercurial to keep track of your own changes.

@@ -112,7 +112,7 @@

Also you check your history from time to time, so see how you progressed.

-

Workflow

+

Workflow

Basics from log keeping
@@ -197,15 +197,15 @@

Note: If you fix a bug in an earlier revision, and some later revision copied or moved that file, the fix will be propagated to the target file(s) when you merge. This is the main reason why you should always use hg cp and hg mv.

-

Seperate features

+

Seperate features

-

Use Case

+

Use Case

At times you'll be working on several features in parallel. If you want to avoid mixing incomplete code versions, you can create clones of your local repository and work on each feature in its own code directory.

After finishing your feature you then pull it back into your main directory and merge the changes.

-

Workflow

+

Workflow

Work in different clones
@@ -267,9 +267,9 @@ Note: Rollback is possible, because Mercurial uses transactions when recording changes, and you can use the transaction record to undo the last transaction. This means that you can also use rollback to undo your last pull, if you didn't yet commit aything new. -

Sharing changes

+

Sharing changes

-

Use Case

+

Use Case

Now we go one step further: You are no longer alone, and you want to share your changes with others and include their changes.

@@ -279,7 +279,7 @@

Note: There are a few other ways to share changes, though. Instead of using the builtin webserver, you can also send the changes by email or setup a shared repository, to where you push changes instead of pulling them. We'll cover one of those later.

-

Workflow

+

Workflow

Using the builtin webserver
@@ -396,7 +396,7 @@

Note: You can also use this workflow with a shared server instead of BitBucket, either via SSH or via a shared directory. An example for an SSH URL with Mercurial is be ssh://user@example.com/path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive.

-

Summary

+

Summary

Now let's take a step back and look where we are.

@@ -408,7 +408,7 @@

A short summary of what you can do which can also act as a short check, if you still remember the meaning of the commands.

-

create a project

+

create a project

$ hg init project
 $ cd project
@@ -417,7 +417,7 @@
 $ hg commit 
 (enter the commit message)
-

do nonlinear development

+

do nonlinear development

$ (do some changes)
 $ hg commit 
@@ -431,7 +431,7 @@
 $ hg commit
 (enter the commit message)
-

use feature clones

+

use feature clones

$ cd ..
 $ hg clone project feature1
@@ -442,13 +442,13 @@
 $ cd ../project
 $ hg pull ../feature1
-

share your repository via the integrated webserver

+

share your repository via the integrated webserver

$ hg serve &
 $ cd ..
 $ hg clone http://127.0.0.1:8000 project-clone
-

export changes to files

+

export changes to files

$ cd project-clone
 $ (do some changes)
@@ -456,17 +456,17 @@
 (enter the commit message)
 $ hg export tip > ../changes.diff
-

import changes from files

+

import changes from files

$ cd ../project
 $ hg import ../changes.diff
-

pull changes from a served repository (hg serve still runs on project)

+

pull changes from a served repository (hg serve still runs on project)

$ cd ../feature1
 $ hg pull http://127.0.0.1:8000
-

Use shared repositories on BitBucket

+

Use shared repositories on BitBucket

$ (setup bitbucket repo)
 $ hg push https://bitbucket.org/USER/REPO
@@ -476,9 +476,9 @@
 
 

Let's move on towards useful features and a bit more advanced workflows.

-

Backing out bad revisions

+

Backing out bad revisions

-

Use Case

+

Use Case

When you routinely pull code from others, it can happen that you overlook some bad change. As soon as others pull that change from you, you have little chance to get completely rid of it.

@@ -486,7 +486,7 @@

Note: The basic commands don't directly rewrite history. If you want to do that, you need to activate some of the extensions which are shipped with mercurial. We'll come to that later on.

-

Workflow

+

Workflow

Let's assume the bad change was revision 3, and we already have one more revision in our repository. To remove the bad code, we just backout of it. This creates a new change which reverses the bad change. After backing out, we merge that new change into the current code.

@@ -498,13 +498,13 @@

That's it. You reversed the bad change. It's still recorded that it was once there (following the principle "don't rewrite history, if it's not really necessary"), but it doesn't affect future code anymore.

-

Collaborative feature development

+

Collaborative feature development

Now that you can share changes and reverse them if necessary, you can go one step further: Using Mercurial to help in coordinating the coding.

The first part is an easy way to develop features together, without requiring every developer to keep track of several feature clones.

-

Use Case

+

Use Case

When you want to split your development into several features, you need to keep track of who works on which feature and where to get which changes.

@@ -512,7 +512,7 @@

Note: Cloning a repository always puts you onto the default branch at first.

-

Workflow

+

Workflow

When someone in your group wants to start coding on a feature without disturbing the others, he can create a named branch and commit there. When someone else wants to join in, he just updates to the branch and commits away. As soon as the feature is finished, someone merges the named branch into the default branch.

@@ -547,9 +547,9 @@

Note: Named branches stay in history as permanent record after you finished your work. If you don't like having that record in your history, please have a look at some of the advanced workflows.

-

Tagging revisions

+

Tagging revisions

-

Use Case

+

Use Case

Since you can now code separate features more easily, you might want to mark certain revisions as fit for consumption (or similar). For example you might want to mark releases, or just mark off revisions as reviewed.

@@ -559,7 +559,7 @@

Note: To securely mark a revision, you can use the gpg extension to sign the tag.

-

Workflow

+

Workflow

Let's assume you want to give revision 3 the name "v0.1".

@@ -578,9 +578,9 @@

Now he'll be at the tagged revision and can work from there.

-

Removing history

+

Removing history

-

Use Case

+

Use Case

At times you will have changes in your repository, which you really don't want in it.

@@ -588,7 +588,7 @@

This workflow becomes inconvenient when you need to remove changes, which are buried below many new changes. If you spot the bad changes early enough, you can get rid of them without too much effort, though.

-

Workflow

+

Workflow

Let's assume you want to get rid of revision 2 and the highest revision is 3.

@@ -614,7 +614,7 @@

Note: removing history will change the revision IDs of revisions after the removed one, and if you pull from someone else who still has the revision you removed, you will pull the removed parts again. That's why rewriting history should most times only be done for changes which you didn't yet publicise.

-

Summary

+

Summary

So now you can work with Mercurial in private, and also share your changes in a multitude of ways.

@@ -624,7 +624,7 @@

With this we can conclude our practical guide.

-

More Complex Workflows

+

More Complex Workflows

If you now want to check some more complex workflows, please have a look at the general workflows wikipage.