97 |
97 |
98 - Centralized VCS: |
98 - Centralized VCS: |
99 In this kind of system all the revision control functions are performed on a shared server. If two developers try to change the same file at the same time, without some method of managing access the developers may end up overwriting each other's work. Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging. Both svn and cvs follows this kind of management. |
99 In this kind of system all the revision control functions are performed on a shared server. If two developers try to change the same file at the same time, without some method of managing access the developers may end up overwriting each other's work. Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging. Both svn and cvs follows this kind of management. |
100 |
100 |
101 - Distributed VCS: |
101 - Distributed VCS: |
102 In a distributed model, every developer has their own repo. Diffs, commits, and reverts are all done locally, one needs Internet only to share the changes with others. It makes work faster, handles branching and merging in better way, with less management. hg, bzr and git uses this workflow. |
102 In a distributed model, every developer has their own repo. Diffs, commits, and reverts are all done locally, one needs Internet only to share the changes with others. It makes work faster, handles branching and merging in better way, with less management. hg, bzr and git uses this work flow. |
103 |
103 |
104 Get Going with Hg: |
104 Get Going with Hg: |
105 ------------------ |
105 ------------------ |
106 |
106 |
107 Reasons for selecting Hg rather then any other tools are: |
107 Why hg? |
|
108 ~~~~~~~ |
108 |
109 |
109 - It is easy to learn and use. |
110 - It is easy to learn and use. |
110 - It is lightweight. |
111 - It is lightweight. |
111 - It scales excellently. |
112 - It scales excellently. |
112 - It is based on Python. |
113 - It is based on Python. |
113 |
114 |
114 To get going with hg, following command gives the version. :: |
115 Getting Started: |
|
116 ~~~~~~~~~~~~~~~~ |
|
117 |
|
118 Following command tells the version of hg installed on machine: |
115 |
119 |
116 $hg version |
120 $hg version |
117 |
121 |
118 Mercurial Distributed SCM (version 1.1.2) |
122 Mercurial Distributed SCM (version 1.1.2) |
119 Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> and others |
123 Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> and others |
127 Mercurial Distributed SCM |
131 Mercurial Distributed SCM |
128 list of commands: |
132 list of commands: |
129 add add the specified files on the next commit |
133 add add the specified files on the next commit |
130 addremove ----------------------- |
134 addremove ----------------------- |
131 |
135 |
132 |
136 For specific command, just follow the command name after the help. :: |
|
137 |
|
138 $hg help diff |
|
139 hg diff [OPTION]... [-r REV1 [-r REV2]] [FILE]... |
|
140 |
|
141 diff repository (or selected files) |
|
142 Show differences between revisions for the specified files. |
|
143 Differences between files are shown using the unified diff format. |
|
144 NOTE:____________ |
|
145 |
|
146 Let there be Repository: |
|
147 ~~~~~~~~~~~~~~~~~~~~~~~~ |
|
148 |
|
149 In Mercurial, everything happens inside a repository. The repository for a project contains all of the files that “belong to” that project, along with a historical record of the project's files.A repository is simply a directory tree in filesystem that Mercurial treats as special. |
|
150 |
|
151 There can be two ways to create a repo, either getting local copy for existing repo available on Internet or machine, or creating a new repo. For getting already existing repo hg uses command *"clone"* :: |
|
152 |
|
153 $hg clone http://hg.serpentine.com/tutorial/hello localCopyhello |
|
154 |
|
155 requesting all changes |
|
156 adding changesets |
|
157 adding manifests |
|
158 adding file changes |
|
159 added 5 changesets with 5 changes to 2 files |
|
160 updating working directory |
|
161 2 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
162 |
|
163 If clone succeeded, there would be a local directory called localCopyhello, with some files: :: |
|
164 |
|
165 $ls localCopyhello/ |
|
166 hello.c Makefile |
|
167 |
|
168 Every Mercurial repository is complete, self-contained, and independent. It contains its own private copy of a project's files and history. |
|
169 |
|
170 To start a new repository hg uses *"init"*: :: |
|
171 |
|
172 $ mkdir newRepo |
|
173 $ cd newRepo/ |
|
174 $ cp ../Desktop/handOut.rst . |
|
175 $ ls -a |
|
176 . .. handOut.rst |
|
177 $ hg init |
|
178 $ ls -a |
|
179 . .. handOut.rst .hg |
|
180 |
|
181 *.hg* directory indicates that this new dir is now a repo.This is where Mercurial keeps all of its metadata for the repository.The contents of the .hg directory and its subdirectories are private to Mercurial. Rest all files are for the user to use them as they pleases. |
|
182 |
|
183 Creating a branch of existing local repo is very easy via hg using clone command: :: |
|
184 |
|
185 $ hg clone localCopyhello newCopy |
|
186 updating working directory |
|
187 2 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
188 |
|
189 now newCopy is exact copy of already existing repo. And this command can be used to create branch of locally created repo also: :: |
|
190 |
|
191 $ hg clone newRepo copyNewRepo |
|
192 updating working directory |
|
193 1 files updated, 0 files merged, 0 files removed, 0 files unresolved |
|
194 |
|
195 These local branches can prove really handy at times. It allows keep multiple copies of local branch for different purposes, say for debugging, testing, working version. |
|
196 |
|
197 History or Logs: |
|
198 ~~~~~~~~~~~~~~~~ |
|
199 |
|
200 For the new repo created, first thing which can be tried is to check the logs/history. What changes were made and when and why, answers to all those questions are stored in logs safely. So for the the cloned repo the history can be viewed using command *"log"* (we are working here on localCopyhello repo). :: |
|
201 |
|
202 $hg log |
|
203 changeset: 4:2278160e78d4 |
|
204 tag: tip |
|
205 user: Bryan O'Sullivan <bos@serpentine.com> |
|
206 date: Sat Aug 16 22:16:53 2008 +0200 |
|
207 summary: Trim comments. |
|
208 |
|
209 changeset: 3:0272e0d5a517 |
|
210 user: Bryan O'Sullivan <bos@serpentine.com> |
|
211 date: Sat Aug 16 22:08:02 2008 +0200 |
|
212 summary: Get make to generate the final binary from a .o file. |
|
213 |
|
214 changeset: 2:fef857204a0c |
|
215 user: Bryan O'Sullivan <bos@serpentine.com> |
|
216 date: Sat Aug 16 22:05:04 2008 +0200 |
|
217 summary: Introduce a typo into hello.c. |
|
218 |
|
219 changeset: 1:82e55d328c8c |
|
220 user: mpm@selenic.com |
|
221 date: Fri Aug 26 01:21:28 2005 -0700 |
|
222 summary: Create a makefile |
|
223 |
|
224 changeset: 0:0a04b987be5a |
|
225 user: mpm@selenic.com |
|
226 date: Fri Aug 26 01:20:50 2005 -0700 |
|
227 summary: Create a standard "hello, world" program |
|
228 |
|
229 By default, this command prints a brief paragraph of output for each change to the project that was recorded.The fields in a record of output from hg log are as follows: |
|
230 |
|
231 - changeset: This field has the format of a number, followed by a colon, followed by a hexadecimal (or hex) string. These are identifiers for the changeset. The hex string is a unique identifier: the same hex string will always refer to the same changeset in every copy of this repository. |
|
232 - user: The identity of the person who created the changeset. |
|
233 - date: The date and time on which the changeset was created, and the timezone in which it was created. |
|
234 - summary: The first line of the text message that the creator of the changeset entered to describe the changeset. |
|
235 - tag: A tag is another way to identify a changeset, by giving it an easy-to-remember name. |
|
236 |
|
237 To narrow the output of hg log down to a single revision, use the -r (or --rev) option. :: |
|
238 |
|
239 $hg log -r 3 |
|
240 changeset: 3:0272e0d5a517 |
|
241 user: Bryan O'Sullivan <bos@serpentine.com> |
|
242 date: Sat Aug 16 22:08:02 2008 +0200 |
|
243 summary: Get make to generate the final binary from a .o file. |
|
244 |
|
245 *range notation* can be used to get history of several revisions without having to list each one. :: |
|
246 |
|
247 $ hg log -r 2:4 |
|
248 changeset: 2:fef857204a0c |
|
249 user: Bryan O'Sullivan <bos@serpentine.com> |
|
250 date: Sat Aug 16 22:05:04 2008 +0200 |
|
251 summary: Introduce a typo into hello.c. |
|
252 |
|
253 changeset: 3:0272e0d5a517 |
|
254 user: Bryan O'Sullivan <bos@serpentine.com> |
|
255 date: Sat Aug 16 22:08:02 2008 +0200 |
|
256 summary: Get make to generate the final binary from a .o file. |
|
257 |
|
258 changeset: 4:2278160e78d4 |
|
259 tag: tip |
|
260 user: Bryan O'Sullivan <bos@serpentine.com> |
|
261 date: Sat Aug 16 22:16:53 2008 +0200 |
|
262 summary: Trim comments. |
|
263 |
|
264 The hg log command's -v (or --verbose) option gives you this extra detail. :: |
|
265 |
|
266 $ hg log -v -r 3 |
|
267 changeset: 3:0272e0d5a517 |
|
268 user: Bryan O'Sullivan <bos@serpentine.com> |
|
269 date: Sat Aug 16 22:08:02 2008 +0200 |
|
270 files: Makefile |
|
271 description: |
|
272 Get make to generate the final binary from a .o file. |
|
273 |
|
274 All about command options??? should we use this? |
|
275 |
133 Suggested Reading: |
276 Suggested Reading: |
134 ------------------ |
277 ------------------ |
135 |
278 |
136 * http://karlagius.com/2009/01/09/version-control-for-the-masses/ |
279 * http://karlagius.com/2009/01/09/version-control-for-the-masses/ |
137 * http://betterexplained.com/articles/a-visual-guide-to-version-control/ |
280 * http://betterexplained.com/articles/a-visual-guide-to-version-control/ |