comparison hgscm/templates/quick_start.html @ 207:c1c9a4f809ba

integrated quick_start and learn_mercurial into the django project (with links).

Only missing parts: A wiki-page for links to learning resources and autodetection of the most current version.

206:d3c0ba7f5284

<h1>Quick Start</h1>
<p><em>How to get going at once.</em></p>
<h2>Part 0: Instant usage</h2>
<p><em>(you know this from the main page)</em></p>
<p>Clone a project and create a patch </p>

$ cd hello
$ (edit files)
$ hg add (new files)
$ hg commit -m 'My changes'
$ hg export tip > patch.diff
</code></pre>
<p>Create a project and commit </p>
<pre><code>$ hg init (project-directory)
$ cd (project-directory)
$ (add some files)

</li><li>hg push: get all changes from your repository into another one
</li><li>hg serve: create an instant-webserver. People can see the history there and pull from it
</li><li>hg merge: join different lines of history
</li>
</ul>
<p>If you want to see a nice graph of the history, just do "hg serve" in your repository and then direct your browser to </p>
<pre><code>    http://127.0.0.1:8000
</code></pre>
<p>This also helps getting a feeling for what the commands do. </p>
<p>(you can also do a lot of finegrained stuff by using different command options. Just call "hg help <command>" to see them). </p>
<p>One step you'll likely want to do is setting your username in your Mercurial config file. </p>
<p>For this you can configure a proper name and email address in ~/.hgrc (or on a Windows system in %USERPROFILE%Mercurial.ini) by adding lines such as the following: </p>
<pre><code>[ui]
username = John Doe &lt;[e-mail]&gt;
</code></pre>
<p>I you want more than this quick overview, please have a look at our longer <a href="{% url workflow_guide %}">practical guide</a>. </p>
<h2>Part 2: Understanding Mercurial in 6 steps</h2>
<p>Now we'll look at some of the basic concepts of Mercurial to get a better understanding of its internals: </p>
<ol>
<li>
<p>Like in Subversion, history consists of a number of commits. They're
  called changesets in Mercurial.</p>

</li><li>

  everybody agrees on the revision numbers.</p>

</li><li>
<p>Mercurial generalizes this by letting each changeset have multiple
  children. If I work alone and make commits I'll make</p>
<p>C1 --&gt; C2 --&gt; C3</p>
<p>by making three commits. </p>

  <p>The commit C3 with no children is a "head".
  It is also the newest changeset in the repository -- called "tip". If I shared C1 with you and you started your work from that, your
  commits will build a repository like this:</p>
<pre><code>C1 --&gt; C2' --&gt; C3'
</code></pre>
<p>Here C3' is a head in your repository and I don't know anything
  about C2' and C3' yet.</p>

</li><li>If I pull from you, or you push to me, the two repositories are

  transfer the missing ones.
<p>After a pull from you my repository will look like this:</p>
<pre><code>     /-&gt; C2 --&gt; C3
C1 -&lt;
     \-&gt; C2' --&gt; C3'
</code></pre>
<p>Here C1 has two child changesets, and the repository has two heads
  since the development has diverged.</p>
<p>The changeset C3' will be the new tip since it is the newest
  changeset in the repository. Note that tip is always a head, but a

  merge must be committed and this creates a changeset which explains
  to the world how you think the two heads should be combined:</p>
<pre><code>     /-&gt; C2 --&gt; C3   -\
C1 -&lt;                  &gt;-&gt; M
     \-&gt; C2' --&gt; C3' -/
</code></pre>
<p>Note that the merge changeset M has two parents.</p>
<p>If you do not merge C3 and C3' and try to push, you get the 'new
  remote head' message and push aborts. It aborts since it is a little
  "impolite" to leave the job of merging to someone else -- he who

</ul>
</ol>

<p>And if you want to quickly look up something, you can use one of the <a href="http://www.selenic.com/mercurial/wiki/index.cgi/QuickReferenceCardsAndCheatSheets">Mercurial cheatsheets</a>. </p>
<p><em>Compiled from a great email by Martin Geisler.</em></p>

207:c1c9a4f809ba

{% extends "base.html" %}

{% load extras %}
{% block content %}

<div class="row">
	<div class="col big">
<h1>Quick Start</h1>
<p><em>How to get going at once.</em></p>
<h2>Part 0: Instant usage</h2>
<p><em>(you know this from the main page)</em></p>
<p>Clone a project and create a patch </p>

$ cd hello
$ (edit files)
$ hg add (new files)
$ hg commit -m 'My changes'
$ hg export tip > patch.diff

</code></pre>
<p>Create a project and commit </p>
<pre><code>$ hg init (project-directory)
$ cd (project-directory)
$ (add some files)

</li><li>hg push: get all changes from your repository into another one
</li><li>hg serve: create an instant-webserver. People can see the history there and pull from it
</li><li>hg merge: join different lines of history
</li>
</ul>
<p>If you want to see a nice graph of the history, just do <hg>hg serve</hg> in your repository and then direct your browser to </p>
<pre><code>    http://127.0.0.1:8000

</code></pre>
<p>This also helps getting a feeling for what the commands do. </p>
<p>(you can also do a lot of finegrained stuff by using different command options. Just call "hg help <command>" to see them). </p>
<p>One step you'll likely want to do is setting your username in your Mercurial config file. </p>
<p>For this you can configure a proper name and email address in ~/.hgrc (or on a Windows system in %USERPROFILE%Mercurial.ini) by adding lines such as the following: </p>
<pre><code>[ui]
username = John Doe &lt;[e-mail]&gt;

</code></pre>
<p>I you want more than this quick overview, please have a look at our longer <a href="{% url workflow_guide %}">practical guide</a>. </p>
<h2>Part 2: Understanding Mercurial in 6 steps</h2>
<p>Now we'll look at some of the basic concepts of Mercurial to get a better understanding of its internals: </p>
<ol class="undecorated_list">
<li>
<p>Like in Subversion, history consists of a number of commits. They're
  called changesets in Mercurial.</p>

</li><li>

  everybody agrees on the revision numbers.</p>

</li><li>
<p>Mercurial generalizes this by letting each changeset have multiple
  children. If I work alone and make commits I'll make</p>
<pre><code>C1 --&gt; C2 --&gt; C3

</code></pre>
<p>by making three commits. </p>

  <p>The commit C3 with no children is a "head".
  It is also the newest changeset in the repository -- called "tip". If I shared C1 with you and you started your work from that, your
  commits will build a repository like this:</p>
<pre><code>C1 --&gt; C2' --&gt; C3'

</code></pre>
<p>Here C3' is a head in your repository and I don't know anything
  about C2' and C3' yet.</p>

</li><li>If I pull from you, or you push to me, the two repositories are

  transfer the missing ones.
<p>After a pull from you my repository will look like this:</p>
<pre><code>     /-&gt; C2 --&gt; C3
C1 -&lt;
     \-&gt; C2' --&gt; C3'

</code></pre>
<p>Here C1 has two child changesets, and the repository has two heads
  since the development has diverged.</p>
<p>The changeset C3' will be the new tip since it is the newest
  changeset in the repository. Note that tip is always a head, but a

  merge must be committed and this creates a changeset which explains
  to the world how you think the two heads should be combined:</p>
<pre><code>     /-&gt; C2 --&gt; C3   -\
C1 -&lt;                  &gt;-&gt; M
     \-&gt; C2' --&gt; C3' -/

</code></pre>
<p>Note that the merge changeset M has two parents.</p>
<p>If you do not merge C3 and C3' and try to push, you get the 'new
  remote head' message and push aborts. It aborts since it is a little
  "impolite" to leave the job of merging to someone else -- he who

</ul>
</ol>

<p>And if you want to quickly look up something, you can use one of the <a href="http://www.selenic.com/mercurial/wiki/index.cgi/QuickReferenceCardsAndCheatSheets">Mercurial cheatsheets</a>. </p>
<p><em>Compiled from a great email by Martin Geisler.</em></p>

</div>
	<div class="col">					
        {% download_button %}
        {% mercurial_tricks %}
        {% mercurial_tricks_advanced %}
	</div>
</div>

{% endblock %}