--- a/versionControl/handOut.rst Sun Aug 23 01:22:44 2009 +0530
+++ b/versionControl/handOut.rst Sun Aug 23 01:23:42 2009 +0530
@@ -65,11 +65,11 @@
The latest revision of the repo.
Check out:
Initial download of repo onto machine.
- Check in:
+ Commit:
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,8 +99,241 @@
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:
+------------------
+
+Why hg?
+~~~~~~~
+
+ - It is easy to learn and use.
+ - It is lightweight.
+ - It scales excellently.
+ - It is based on Python.
+
+Getting Started:
+~~~~~~~~~~~~~~~~
+
+Following command tells the version of hg installed on machine:
+
+ $hg version
+
+ Mercurial Distributed SCM (version 1.1.2)
+ Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> and others
+ This is free software; see the source for copying conditions. There is NO
+ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+Built-in help, Mercurial provides a built-in help system. Following command will print a brief list of commands, along with a description of what each does. ::
+
+ $hg help
+
+ Mercurial Distributed SCM
+ list of commands:
+ 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 feviCol
+ $ cd feviCol/
+ $ echo "print 'Yeh Fevicol ka Majboot jod hai!'" > feviStick.py
+ $ ls -a
+ . .. feviStick.py
+ $ hg init
+ $ ls -a
+ . .. feviStick.py .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
+
+newCopy is exact copy of already existing repo. And this command can be used to create branch of locally created repo also: ::
+
+ $ hg clone feviCol feviCol-pull
+ updating working directory
+ 0 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"* (following commands are wrt 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.
+
+Making Changes:
+~~~~~~~~~~~~~~~
+
+There is feviStick.py file in repo created above with name feviCol. ::
+
+ $ cd feviCol
+ $ hg log
+ $ hg status
+ ? feviStick.py
+
+*status(st)* command prints the revision history of the specified files or the entire project. "?" sign in front of file indicates that this file is not yet part of track record. *add* command is used to add new files to repo. ::
+
+ $ hg add feviStick.py
+ $ hg st
+ A feviStick.py
+
+So file is now part of repository(A symbol). Use *commit (alias ci)* command to make changes effective(this command would be explained in more details in later parts). ::
+
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "First commit."
+ $ hg log
+ changeset: 0:84f5e91f4de1
+ tag: tip
+ user: Shantanu <shantanu@fossee.in>
+ date: Fri Aug 21 23:37:13 2009 +0530
+ summary: First commit.
+
+Similar to add there are other commands available for file management in repo. ::
+
+ $ hg cp feviStick.py pidiLite.py
+ $ hg st
+ A pidiLite.py
+
+*copy (alias cp)* command is used to mark files as copied for the next commit. ::
+
+ $ hg rename pidiLite.py feviCol.py
+ $ hg st
+ A feviCol.py
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Renamed pidiLite.py."
+ $ hg tip
+ changeset: 1:d948fb4137c5
+ tag: tip
+ user: Shantanu <shantanu@fossee.in>
+ date: Sat Aug 22 00:11:25 2009 +0530
+ summary: Renamed pidiLite.py.
+
+*rename(alias mv)* rename files; equivalent of copy + remove. *tip* command shows newest revision in the repository.. ::
+
+ $ hg remove feviCol.py
+ $ hg st
+ R feviCol.py
+
+R status of files denotes, file is marked as to be removed by the previous command *remove*. To add the file again to repo, one can use *revert* command, which restore individual files or dirs to an earlier state. ::
+
+ $ ls
+ feviStick.py
+ $ hg revert feviCol.py
+ $ ls
+ feviCol.py feviStick.py
+
+Sharing Changes:
+~~~~~~~~~~~~~~~~
+
+As mentioned earlier that repositories in Mercurial are self-contained. This means that the changeset just created exists only in Fevicol repository and not in previously cloned feviVol-pull. There are a few ways that can be used to propagate this change into other repositories.
Suggested Reading:
------------------