comparison original/hgscm/templates/quick_start.html @ 244:4b97017259f9

Move the original site into a single folder to reduce clutter.
author Steve Losh <steve@stevelosh.com>
date Wed, 23 Sep 2009 20:05:13 -0400
parents hgscm/templates/quick_start.html@c7bf003b17fd
children 960885d6e884
comparison
equal deleted inserted replaced
240:85a7a53db1a5 244:4b97017259f9
1 {% extends "base.html" %}
2
3 {% load extras %}
4 {% block content %}
5
6 <div class="row">
7 <div class="col big">
8 <h1>Quick Start</h1>
9 <p><em>How to get going at once.</em></p>
10 <h2>Part 0: Instant usage</h2>
11 <p><em>(you know this from the main page)</em></p>
12 <p>Clone a project and create a patch </p>
13 <pre><code>$ hg clone http://hg-scm.org/hello
14 $ cd hello
15 $ (edit files)
16 $ hg add (new files)
17 $ hg commit -m 'My changes'
18 $ hg export tip &gt; patch.diff
19
20 </code></pre>
21 <p>Create a project and commit </p>
22 <pre><code>$ hg init (project-directory)
23 $ cd (project-directory)
24 $ (add some files)
25 $ hg add
26 $ hg commit -m 'Initial commit'
27 </code></pre>
28 <h2>Part 1: Using Mercurial</h2>
29 <p>Aside from the practical Quick Start above, there are only a few commands you need to start
30 working. </p>
31 <p>Even if you stick to these basics, Mercurial is quite powerful. And they are very easy to
32 use, once you see the model behind them: Each repository has the whole history, and history is
33 not necessarily linear (part 2 explains that model in a bit more detail). </p>
34 <p>A quick overview of the basic commands: </p>
35 <ul>
36 <li>hg init: create a new repository
37 </li><li>hg commit: save your changes in the current repository
38 </li><li>hg log: see all changes in your repository
39 </li><li>hg pull: get all changes from another repository into the current one
40 </li><li>hg push: get all changes from your repository into another one
41 </li><li>hg serve: create an instant-webserver. People can see the history there and pull from it
42 </li><li>hg merge: join different lines of history
43 </li>
44 </ul>
45 <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>
46 <pre><code> http://127.0.0.1:8000
47
48 </code></pre>
49 <p>This also helps getting a feeling for what the commands do. </p>
50 <p>(you can also do a lot of finegrained stuff by using different command options. Just call "hg help &lt;command&gt;" to see them). </p>
51 <p>One step you'll likely want to do is setting your username in your Mercurial config file. </p>
52 <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>
53 <pre><code>[ui]
54 username = John Doe &lt;john@example.com&gt;
55
56 </code></pre>
57 <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>
58 <h2>Part 2: Understanding Mercurial in 6 steps</h2>
59 <p>Now we'll look at some of the basic concepts of Mercurial to get a better understanding of its internals: </p>
60 <ol class="undecorated_list">
61 <li>
62 <p>Like in Subversion, history consists of a number of commits. They're
63 called changesets in Mercurial.</p>
64
65 </li><li>
66 <p>Subversion requires a strict linear ordering of the commits and
67 gives nice linear revision numbers to them. So revision N has only
68 one child revision, N+1. This is simple, but it requires a central server to make sure that
69 everybody agrees on the revision numbers.</p>
70
71 </li><li>
72 <p>Mercurial generalizes this by letting each changeset have multiple
73 children. If I work alone and make commits I'll make</p>
74 <pre><code>C1 --&gt; C2 --&gt; C3
75
76 </code></pre>
77 <p>by making three commits. </p>
78
79 <p>The commit C3 with no children is a "head".
80 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
81 commits will build a repository like this:</p>
82 <pre><code>C1 --&gt; C2' --&gt; C3'
83
84 </code></pre>
85 <p>Here C3' is a head in your repository and I don't know anything
86 about C2' and C3' yet.</p>
87
88 </li><li>If I pull from you, or you push to me, the two repositories are
89 compared. By default, all missing changesets are transferred. This
90 is all there is to push/pull: compare two graphs of changesets and
91 transfer the missing ones.
92 <p>After a pull from you my repository will look like this:</p>
93 <pre><code> /-&gt; C2 --&gt; C3
94 C1 -&lt;
95 \-&gt; C2' --&gt; C3'
96
97 </code></pre>
98 <p>Here C1 has two child changesets, and the repository has two heads
99 since the development has diverged.</p>
100 <p>The changeset C3' will be the new tip since it is the newest
101 changeset in the repository. Note that tip is always a head, but a
102 head need not be the tip.</p>
103
104 </li><li>Having two heads suggest that someone should merge them -- otherwise
105 the changes from one will never be combined with the changed made in
106 the other head.
107 <p>When merging with 'hg merge' the task is to figure out the canonical
108 way to combine the changesets. If the changes do not overlap this is
109 usually trivial, otherwise you have to do a three-way merge. The
110 merge must be committed and this creates a changeset which explains
111 to the world how you think the two heads should be combined:</p>
112 <pre><code> /-&gt; C2 --&gt; C3 -\
113 C1 -&lt; &gt;-&gt; M
114 \-&gt; C2' --&gt; C3' -/
115
116 </code></pre>
117 <p>Note that the merge changeset M has two parents.</p>
118 <p>If you do not merge C3 and C3' and try to push, you get the 'new
119 remote head' message and push aborts. It aborts since it is a little
120 "impolite" to leave the job of merging to someone else -- he who
121 created the two heads by pulling in some code should also normally
122 do the merging.
123 </p>
124 </li><li>
125 <p>It helped my understanding a lot to think in terms of the changeset graph. Just remember that:</p>
126 <ul><li>
127 <p>"hg commit" adds a new node. The parent changesets of the new node
128 is given by "hg parents"</p>
129
130 </li><li>
131 <p>"hg push" and "hg pull" transfer nodes in the graph between two
132 repositories.</p>
133
134 </li><li>
135 <p>"hg update" updates the working copy to reflect a given node in
136 the history graph. This also changes the parent changeset of the
137 next commit, see "hg parents".</p>
138 </li>
139 </ul>
140 </ol>
141
142 <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>
143 <p><em>Compiled from a great email by Martin Geisler.</em></p>
144
145 </div>
146 <div class="col">
147 {% download_button %}
148 {% mercurial_tricks %}
149 {% mercurial_tricks_advanced %}
150 </div>
151 </div>
152
153 {% endblock %}