--- a/versionControl/handOut.rst Fri Aug 21 18:00:18 2009 +0530
+++ b/versionControl/handOut.rst Fri Aug 21 20:26:01 2009 +0530
@@ -67,9 +67,9 @@
Initial download of repo onto machine.
Check in:
Upload a file to repository(if it has changed). The file gets a new revision number, and people can “check out” the latest one.
- Checkin Message:
+ Checking Message:
A short message describing what was changed.
- Changelog/History:
+ Change log/History:
A list of changes made to a file since it was created.
Update/Sync:
Synchronize local files with the latest from the repository on server. This get the latest revisions of all files.
@@ -99,19 +99,23 @@
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.
- Distributed VCS:
- 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.
+ 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.
Get Going with Hg:
------------------
-Reasons for selecting Hg rather then any other tools are:
+Why hg?
+~~~~~~~
- It is easy to learn and use.
- It is lightweight.
- It scales excellently.
- It is based on Python.
-To get going with hg, following command gives the version. ::
+Getting Started:
+~~~~~~~~~~~~~~~~
+
+Following command tells the version of hg installed on machine:
$hg version
@@ -129,7 +133,146 @@
add add the specified files on the next commit
addremove -----------------------
-
+For specific command, just follow the command name after the help. ::
+
+ $hg help diff
+ hg diff [OPTION]... [-r REV1 [-r REV2]] [FILE]...
+
+ diff repository (or selected files)
+ Show differences between revisions for the specified files.
+ Differences between files are shown using the unified diff format.
+ NOTE:____________
+
+Let there be Repository:
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+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"* ::
+
+ $hg clone http://hg.serpentine.com/tutorial/hello localCopyhello
+
+ requesting all changes
+ adding changesets
+ adding manifests
+ adding file changes
+ added 5 changesets with 5 changes to 2 files
+ updating working directory
+ 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+If clone succeeded, there would be a local directory called localCopyhello, with some files: ::
+
+ $ls localCopyhello/
+ hello.c Makefile
+
+Every Mercurial repository is complete, self-contained, and independent. It contains its own private copy of a project's files and history.
+
+To start a new repository hg uses *"init"*: ::
+
+ $ mkdir newRepo
+ $ cd newRepo/
+ $ cp ../Desktop/handOut.rst .
+ $ ls -a
+ . .. handOut.rst
+ $ hg init
+ $ ls -a
+ . .. handOut.rst .hg
+
+*.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.
+
+Creating a branch of existing local repo is very easy via hg using clone command: ::
+
+ $ hg clone localCopyhello newCopy
+ updating working directory
+ 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+now newCopy is exact copy of already existing repo. And this command can be used to create branch of locally created repo also: ::
+
+ $ hg clone newRepo copyNewRepo
+ updating working directory
+ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+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.
+
+History or Logs:
+~~~~~~~~~~~~~~~~
+
+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). ::
+
+ $hg log
+ changeset: 4:2278160e78d4
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:16:53 2008 +0200
+ summary: Trim comments.
+
+ changeset: 3:0272e0d5a517
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:08:02 2008 +0200
+ summary: Get make to generate the final binary from a .o file.
+
+ changeset: 2:fef857204a0c
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:05:04 2008 +0200
+ summary: Introduce a typo into hello.c.
+
+ changeset: 1:82e55d328c8c
+ user: mpm@selenic.com
+ date: Fri Aug 26 01:21:28 2005 -0700
+ summary: Create a makefile
+
+ changeset: 0:0a04b987be5a
+ user: mpm@selenic.com
+ date: Fri Aug 26 01:20:50 2005 -0700
+ summary: Create a standard "hello, world" program
+
+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:
+
+ - 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.
+ - user: The identity of the person who created the changeset.
+ - date: The date and time on which the changeset was created, and the timezone in which it was created.
+ - summary: The first line of the text message that the creator of the changeset entered to describe the changeset.
+ - tag: A tag is another way to identify a changeset, by giving it an easy-to-remember name.
+
+To narrow the output of hg log down to a single revision, use the -r (or --rev) option. ::
+
+ $hg log -r 3
+ changeset: 3:0272e0d5a517
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:08:02 2008 +0200
+ summary: Get make to generate the final binary from a .o file.
+
+*range notation* can be used to get history of several revisions without having to list each one. ::
+
+ $ hg log -r 2:4
+ changeset: 2:fef857204a0c
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:05:04 2008 +0200
+ summary: Introduce a typo into hello.c.
+
+ changeset: 3:0272e0d5a517
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:08:02 2008 +0200
+ summary: Get make to generate the final binary from a .o file.
+
+ changeset: 4:2278160e78d4
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:16:53 2008 +0200
+ summary: Trim comments.
+
+The hg log command's -v (or --verbose) option gives you this extra detail. ::
+
+ $ hg log -v -r 3
+ changeset: 3:0272e0d5a517
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sat Aug 16 22:08:02 2008 +0200
+ files: Makefile
+ description:
+ Get make to generate the final binary from a .o file.
+
+All about command options??? should we use this?
+
Suggested Reading:
------------------