php avatar php committed 6817312

Update 20120116

Comments (0)

Files changed (1)

 
 <h1>Learning Mercurial in Workflows</h1>
 
-<p>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 easy for beginners of version tracking to get going instantly and learn completely incrementally. It doesn't explain the concepts used, because there are already many other great resources doing that, for example <a title="Understanding Mercurial" href="http://www.selenic.com/mercurial/wiki/UnderstandingMercurial">the wiki</a> and <a title="Behind the Scenes" href="http://hgbook.red-bean.com/read/behind-the-scenes.html">the hgbook</a>.</p>
+<p>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 easy for beginners of version tracking to get going instantly and learn completely incrementally. It doesn't explain the concepts used, because there are already many other great resources doing that. </p>
 
-<p>If you want a more exhaustive tutorial with the basics, please have a look at the <a title="Mercurial Tutorial" href="http://www.selenic.com/mercurial/wiki/Tutorial">Tutorial in the Mercurial Wiki</a>. For a really detailed and very nice to read description of Mercurial, please have a look at <a title="Mercurial: The definitive Guide" href="http://hgbook.red-bean.com/">Mercurial: The Definitive Guide</a>.</p>
+<p>Alternatives to this guide and further reading: </p>
+
+<ul>
+<li> <a title="Mercurial Tutorial" href="http://www.selenic.com/mercurial/wiki/Tutorial">Tutorial</a> - a more exhaustive tutorial. </li>
+<li><a title="Mercurial: The definitive Guide" href="http://hgbook.red-bean.com/">Mercurial: The Definitive Guide</a> - a very detailed description of Mercurial including <a title="Behind the Scenes" href="http://hgbook.red-bean.com/read/behind-the-scenes.html">behind the scenes</a>, an indepth article on the design of Mercurial.</li>
+<li><a title="Understanding Mercurial" href="http://www.selenic.com/mercurial/wiki/UnderstandingMercurial">Understanding Mercurial</a> - the concepts behind Mercurial.</li>
+</ul>
 
 <div class="note">
 <p class="note-title">Note:</p>
 
 <h3>Use Case</h3>
 
-<p>The first workflow is also the easiest one: You want to use Mercurial to be able to look back when you did which changes.</p>
+<p>The first workflow is also the easiest one: You want to use Mercurial to be able to <strong>look back when you did which changes</strong>.</p>
 
 <p>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.</p>
 
 HG: added hello.py
 </div>
 
+<p>You can then look into your initial history with <em>hg log</em>:</p>
+
+<pre>$ hg log
+
+</pre>
+
+<div class="output">output of hg log:
+changeset:   0:a5ecbf5799c8
+user:        Mr. Johnson <johnson@smith.com>
+date:        Sun Nov 20 11:00:00 2011 +0100
+summary:     Initial commit.
+</div>
+
+
 <div class="note">
 <p class="note-title">Note:</p>
 You can also go into an existing directory with files and init the repository there.
 HG: changed hello.py
 </div>
 
+<p>Your history now looks like this:</p>
+
+<div class="output">output of hg log:
+changeset:   1:487d7a20ccbc
+user:        Mr. Johnson <johnson@smith.com>
+date:        Sun Nov 20 11:11:00 2011 +0100
+summary:     Say Hello World, not just Hello.
+
+changeset:   0:a5ecbf5799c8
+user:        Mr. Johnson <johnson@smith.com>
+date:        Sun Nov 20 11:00:00 2011 +0100
+summary:     Initial commit.
+</div>
+
+
 <div class="note">
 <p class="note-title">Note:</p>
 You can also supply the commit message directly via <em>hg commit -m 'MESSAGE'</em>.
 
 <h3>Use case</h3>
 
-<p>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.</p>
+<p>The second workflow is still very easy: You're a lone developer and you want to use Mercurial to <strong>keep track of your own changes</strong> and <strong>optimize your workflow</strong>.</p>
 
-<p>It works just like the log keeping workflow, with the difference that you go back to earlier changes at times.</p>
+<p>It works just like the log keeping workflow, with the difference that you go back to earlier changes at times and work onwards from there.</p>
 
 <p>To start a new project, you initialize a repository, add your files and commit whenever you finished a part of your work.</p>
 
 
 <div class="note">
 <p class="note-title">Note:</p>
-For more details on resolving conflicts, see the wiki-page <a title="Tutorial - Merging conflicting Changes href="http://mercurial.selenic.com/wiki/TutorialConflict">TutorialConflict</a>.
+For more details on resolving conflicts, see the wiki-page <a title="Tutorial - Merging conflicting Changes" href="http://mercurial.selenic.com/wiki/TutorialConflict">TutorialConflict</a>.
 </div>
 
 
 
 <h3>Use Case</h3>
 
-<p>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.</p>
+<p>At times you'll be <strong>working on several features in parallel</strong>. 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.</p>
 
 <p>After finishing your feature you then <em>pull</em> it back into your main directory and <em>merge</em> the changes.</p>
 
 
 <h3>Use Case</h3>
 
-<p>Now we go one step further: You are no longer alone, and you want to share your changes with others and include their changes.</p>
+<p>Now we go one step further: You are no longer alone, and you want to <strong>share your changes with others and include their changes</strong>.</p>
 
 <p>The basic requirement for that is that you have to be able to see the changes of others.</p>
 
 
 <p>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.</p>
 
-<p>To resolve that problem, Mercurial offers you the <em>backout</em> command. Backing out a change means, that you tell Mercurial to create a commit which reverses the bad change. That way you don't get rid of the bad code in history, but you can remove it from new revisions.</p>
+<p>To resolve that fundamental problem in any really distributed system, Mercurial offers you the <em>backout</em> command. Backing out a change means, that you tell Mercurial to <strong>create a commit which reverses the bad change</strong>. That way you don't get rid of the bad code in history, but you can remove it from new revisions.</p>
 
 <div class="note">
 <p class="note-title">Note:</p>
-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.
+The basic commands don't 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 <a title="Removing History" href="#removing_history">later on</a>.
 </div>
 
 <h3>Workflow</h3>
 
 <h2 id="collaborative_development">Collaborative feature development</h2>
 
-<p>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.</p>
+<p>Now that you can share changes and reverse them if necessary, you can go one step further: Using Mercurial to help in <strong>coordinating the coding</strong>.</p>
 
 <p>The first part is an easy way to develop features together, without requiring every developer to keep track of several feature clones.</p>
 
 
 <p>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.</p>
 
+<div class="note">
+<p class="note-title">Note:</p>
+Named branch information is <strong>permanently stored in history</strong>, so you can always see for which feature some change was added. If you only want temporary branches as short-lived markers on history, you can use Bookmarks instead. Just replace <em>hg branch</em> with <em>hg bookmark</em> and add <em>-B &lt;bookmark-name&gt;</em> to <em>hg push</em> and <em>hg pull</em>.
+</div>
+
 <h5>Working in a named branch</h5>
 
 <p>Create the branch</p>
 
 <p>And that's it. Now you can easily keep features separate without unnecessary bookkeeping.</p>
 
-<div class="note">
-<p class="note-title">Note:</p>
-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 <a title="Mercurial Workflows" href="http://www.selenic.com/mercurial/wiki/Workflows">workflows</a>.
-</div>
-
 <h2 id="tagging">Tagging revisions</h2>
 
 <h3>Use Case</h3>
 
-<p>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.</p>
+<p>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 <strong>mark releases, or just mark off revisions as reviewed</strong>.</p>
 
 <p>For this Mercurial offers tags. Tags add a name to a revision and are part of the history. You can tag a change years after it was committed. The tag includes the information when it was added, and tags can be pulled, pushed and merged just like any other committed change.</p>
 
 
 <p>There are many advanced options for removing these, and most of them use great extensions (<a title="Mercurial Queues Extension" href="http://www.selenic.com/mercurial/wiki/MqExtension">Mercurial Queues</a> is the most often used one), but in this basic guide, we'll solve the problem with just the commands we already learned. But we'll use an option to clone which we didn't yet need.</p>
 
-<p>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.</p>
+<p>This workflow becomes inconvenient when you need to remove changes, which are buried below many new changes. If you spot the them early enough, you can <strong>get rid of bad changes</strong> without too much effort, though.</p>
 
 <h3>Workflow</h3>
 
 
 <div class="note">
 <p class="note-title">Note:</p>
-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.
+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.
 </div>
 
 <h2 id="advanced_summary">Summary</h2>
 
 <p>If you now want to check some more complex workflows, please have a look at the general <a title="Mercurial Workflows" href="http://selenic.com/mercurial/wiki/Workflows">workflows wikipage</a> and the list of <a title="Mercurial extensions" href="http://mercurial.selenic.com/wiki/UsingExtensions">extensions</a>.</p>
 
-<p>To deepen your understanding, you should also check the <a title="Overview of the basic concepts of Mercurial" href="http://mercurial.selenic.com/wiki/UnderstandingMercurial">basic concept overview</a>.</p>
+<p>To deepen your understanding, you can also check the <a title="Overview of the basic concepts of Mercurial" href="http://mercurial.selenic.com/wiki/UnderstandingMercurial">basic concept overview</a>.</p>
 
 <p>Have fun with Mercurial!</p>
 
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.