# HG changeset patch # User Arne Babenhauserheide # Date 1243173982 -7200 # Node ID 036f686365ca183575323cd75014ab38392e82f3 # Parent 45155fbcee67987a1580caf5ac639528f3234813# Parent f73d4e6949bf6d3841b81dce9bdaf0fef1179615 merge diff -r 45155fbcee67 -r 036f686365ca hgscm/templates/workflow_guide.html --- a/hgscm/templates/workflow_guide.html Sun May 24 16:05:17 2009 +0200 +++ b/hgscm/templates/workflow_guide.html Sun May 24 16:06:22 2009 +0200 @@ -14,8 +14,7 @@

If you want a more exhaustive tutorial with the basics, please have a look at the Tutorial in the Mercurial Wiki. For a really detailed and very nice to read description of Mercurial, please have a look at Mercurial: The definitive Guide.

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

@@ -124,7 +123,7 @@ -

Lone developer with nonlinear history

+

Lone developer with nonlinear history

Use case

@@ -241,7 +240,7 @@

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

+

Separate features

Use Case

@@ -325,7 +324,7 @@

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

@@ -484,7 +483,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.

@@ -580,7 +579,9 @@

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

-

Backing out bad revisions

+

Advanced workflows

+ +

Backing out bad revisions

Use Case

@@ -604,7 +605,7 @@

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.

@@ -659,7 +660,7 @@

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

@@ -696,7 +697,7 @@

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

-

Removing history

+

Removing history

Use Case

@@ -738,7 +739,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.

@@ -748,7 +749,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.

@@ -760,8 +761,26 @@
- {% download_button %} - {% mercurial_tricks %} +

Index

+ +