--- a/versionControl/handOut.rst Thu Jun 10 18:51:22 2010 +0530
+++ b/versionControl/handOut.rst Thu Jun 10 18:54:04 2010 +0530
@@ -5,24 +5,24 @@
Introduction
============
-The following words are from a blogpost "http://karlagius.com/2009/01/09/version-control-for-the-masses/"
+The following statement from a blog[1](http://karlagius.com/2009/01/09/version-control-for-the-masses/") aptly points usefulness of version control systems:
"Version control is one of those weird, geeky things that never really gained much ground in non-geek fields, despite the fact that it’s blindingly useful.
-Version control (or source control) is nothing more arcane than keeping copies of ones work as one make changes to it. On the surface, it’s all straight-forward; make a copy of every file before making any changes to it. That way, if something seriously messes up, one can always fall back to something that worked before, or at least compare the broken copy with one that used to work so one can figure out where it went off kilter. Accidentally deleted half of thesis and closed the word processor? No problem – out comes the backup."
+Version control (or source control) is nothing more complex than keeping copies of work as we make changes. On the surface, it’s all straight-forward; make a copy of every file before making any changes to it. That way, if something seriously messes up, one can always fall back to something that worked before, or at least compare the broken copy with one that used to work so one can figure out where it went wrong."
-Now, in the real world, it’s not so easy. One probably cooks up their own version control system without realizing it had such a geeky name. For instances files with names oldxxxxxx.py and latestxxxxxx.py. Every time to make some change in a file, one save it with different name then the original one. Luckily there are like, loads of version control systems out there to do this heavy lifting.
+One probably cooks up their own version control system without realizing it had such a geeky name. For instances files with names oldxxxxxx.py and latestxxxxxx.py. Every time to make some change in a file, one save it with different name then the original one. Luckily there are like, loads of version control systems out there to do this heavy lifting.
Why Use Version Control
=======================
-One of idea behind Version Control Tools was to build onto very first step which can be creating a empty file, or writing a first buggy program for assignment, rather then simply loose it. So here are some reasons why is automated version control needed:
+One of idea behind Version Control Tools was to build onto very first step which can be creating a empty file, or writing a first buggy program for assignment, rather than simply loose it. So here are some more reasons why is automated version control needed:
- It will track the history and evolution of a project, so one don't have to do it manually. It allows to track what changes where made, when were they made, by whom and why.
- For a team of people working on same project, revision control software makes it easier to collaborate. For example, when people more or less simultaneously make potentially incompatible changes, the software will help them to identify and resolve those conflicts.
- - It can help to recover from mistakes. If a change made at some moment of time, turns out to be in error in future, one can revert to an earlier version of one or more files. In fact, a really good revision control tool will even help in efficiently figure out exactly when a problem was introduced.
+ - It can help to recover from mistakes. If a change made at some moment of time, turns out to be an error in future, one can revert to an earlier version of one or more files. In fact, a really good revision control tool will even help in efficiently figure out exactly when a problem was introduced.
-Most of these reasons are equally valid for the project having one man show, or hundred people. Besides projects, even it can be used to maintain assignments related to one particular subject/course, it will help manage things in way much better way. These tools can be used for better *resources management*. All codes, documents, presentation, assignments related to one course maintained in such a inventory can help avoiding accidental lose of data(deletion) and Internet hosting for version control will make the work immune to local hard-disk crash, unless hosting crashes itself.
+Most of these reasons are equally valid for the project having one man show, or hundred people. Besides projects, even it can be used to maintain assignments related to one particular subject/course, it will help manage things in way much better way. These tools can be used for better *resources management*. All codes, documents, presentation, assignments related to one course maintained in such a inventory can help avoiding accidental lose of data(deletion) and Internet hosting for version control will make the work immune to local hard-disk crash.
Some of Version Control Tools available and used widely are:
@@ -37,19 +37,17 @@
Learning the Lingo
==================
-Each Version Control uses its own nomenclature for more or less the same features. Here are some of terms which are going to used through out the rest of session:
+Here are some of terms which are going to used through out the rest of session:
Basic Setup
-----------
+(should we include at all terms used by vcs's other than hg?)
+
Repository(repo):
- The database/folder storing the files.
+ The folder with all the files.
Server:
- The computer storing the repo.
- Client:
- The computer connecting to the repo.
- Working Set/Working Copy:
- Your local directory of files, where you make changes. This is what is present on client side.
+ The system with the main(mother) repo.
Trunk/Main:
The “primary” location for code in the repo. Think of code as a family tree — the “trunk” is the main line. This is generally what is present on server.
@@ -58,44 +56,41 @@
Add:
Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
+ Head/Tip:
+ The latest version of the repo(Die Hard 4.1)
Revision:
What version a file is on.
- Head/Tip:
- The latest revision of the repo.
- Check out:
- Initial download of repo onto machine.
+ Clone:
+ Creating initial copy of the repo onto a local machine.
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.
- Checking Message:
- A short message describing what was changed.
- 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.
+ Committing the changes done to the repo in terms of contents of the files or adding/removing of the files.
+ Logs/History:
+ Logs of all the past changes done to the repo.
+ Update:
+ Updating the local repo with the main one, includes both, adding changing done by us or importing changes done by others.
Revert:
- Throw away the local changes and reload the latest version from the repository.
+ Going back to previous committed state of file.
Advanced Actions:
-----------------
Branch:
- Create a separate copy of a file/folder for private use (bug fixing, testing, etc).
+ Create a separate copy of the repo for private use (bug fixing, testing, etc).
Diff/Change:
- Finding the differences between two files. Useful for seeing what changed between revisions.
+ Finding the differences between two versions of a file.
Merge (or patch):
- Apply the changes from one file to another, to bring it up-to-date.
+ Apply the changes from one branch to another, to bring it up-to-date.
Conflict:
When pending changes to a file contradict each other (both changes cannot be applied).
- Resolve:
- Fixing the changes that contradict each other and checking in the correct version.
Types of Version Control:
-------------------------
+(should we have this part at all?)
Based on how source/code management is carried out in a tool there are two categories of Version Control Systems(VCS):
- Centralized VCS:
- 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.
+ 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 others 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 work flow.
@@ -106,37 +101,46 @@
Why hg?
-------
- - It is easy to learn and use.
- - It is lightweight.
- - It scales excellently.
- - It is based on Python.
+ - easy to learn and use.
+ - lightweight.
+ - scales excellently.
+ - based on Python.
A small point to notice here, hg cant track binary files for changes, one can add them to repo, but wont be able to track changes made to it. And hg considers, odt, pdf files as binary.
+Installation:
+-------------
+
+- For Linux based systems, hg is available in most of package management. So for say Ubuntu systems::
+
+ $ sudo apt-get install mercurial
+
+ will be all you need to install hg. Similarly Fedora users can use yum to install hg.
+
+- For Windows and Mac OS X systems the setup can be downloaded from http://mercurial.selenic.com/downloads/ and standard installation can be followed.
+
Getting Started:
----------------
-Following command tells the version of hg installed on machine: ::
+After installation is complete lets get started with using. First things first, lets pay our homage to *man* pages as per rituals: ::
- $hg version
+ $ man hg
- 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.
+This will give us manuscript of all the options available with *hg*. We can either look through all of it, or a better way will be to use built-in help system of *hg*. Say to get brief list of all commands, along with a description of what each does we can use ::
-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
+ $ hg help
Mercurial Distributed SCM
list of commands:
add add the specified files on the next commit
addremove -----------------------
+ ------------------------------------
+ heads show current repository heads or show branch heads
+ ------------------------------------
For specific command, just follow the command name after the help. ::
- $hg help diff
+ $ hg help diff
hg diff [OPTION]... [-r REV1 [-r REV2]] [FILE]...
diff repository (or selected files)
@@ -147,11 +151,24 @@
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 file-system that Mercurial treats as special.
+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 which Mercurial treats as special.
+
+There can be two ways to create a repo, either downloading a copy of existing repo available on Internet, or creating/starting a new repo.
+
+Say we have a directory which we want to bring under version control, so we start a new repository using *hg init*: ::
-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"* ::
+ $ ls -a circulate/
+ . .. lena.png pendulum.txt points.txt pos.txt sslc1.py sslc1.txt
+ $ cd circulate/
+ $ hg init
+ $ ls -a
+ . .. .hg lena.png pendulum.txt points.txt pos.txt sslc1.py sslc1.txt
- $hg clone http://hg.serpentine.com/tutorial/hello localCopyhello
+*.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.
+
+For getting already existing repo hg uses command *"clone"* ::
+
+ $ hg clone http://hg.serpentine.com/tutorial/hello localCopyhello
requesting all changes
adding changesets
@@ -163,44 +180,25 @@
If clone succeeded, there would be a local directory called localCopyhello, with some files: ::
- $ls localCopyhello/
+ $ 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 use *hg 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
+ $ 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.
+newCopy is exact copy of already existing repo. 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). ::
+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 cloned repo the history can be viewed using command *"log"* (following commands are wrt localCopyhello repo). ::
- $hg log
+ $ hg log
changeset: 4:2278160e78d4
tag: tip
user: Bryan O'Sullivan <bos@serpentine.com>
@@ -229,15 +227,14 @@
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.
+ - changeset: This field is a identifier for the changeset. The hex string is a unique identifier.
- 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.
+ - date: The date and time on which the changeset was created.
+ - summary: The first line of the text message entered to describe the changeset.
-To narrow the output of hg log down to a single revision, use the -r (or --rev) option. ::
+To narrow the output of hg log down to a single revision, use the -r option. ::
- $hg log -r 3
+ $ hg log -r 3
changeset: 3:0272e0d5a517
user: Bryan O'Sullivan <bos@serpentine.com>
date: Sat Aug 16 22:08:02 2008 +0200
@@ -245,7 +242,7 @@
*range notation* can be used to get history of several revisions without having to list each one. ::
- $ hg log -r 2:4
+ $ hg log -r 2:4
changeset: 2:fef857204a0c
user: Bryan O'Sullivan <bos@serpentine.com>
date: Sat Aug 16 22:05:04 2008 +0200
@@ -262,74 +259,74 @@
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.
+-v option with "log" gives some extra details related to a changeset.
Making Changes:
---------------
-There is feviStick.py file in repo created above with name Fevicol. *status(alias st)* command prints the revision history of the specified files or the entire project::
+Lets follow a simple exercise of *managing letters* using hg. We create a new directory and start revision tracking on it.::
+
+ $ mkdir letter
+ $ cd letter
+ $ touch letter.tex
+ $ hg init
- $ cd Fevicol
- $ hg log
- $ hg status
- ? feviStick.py
+Now lets try to create a local clone of this repository::
-"?" 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 clone letter letter-clone
+ updating working directory
+ 0 files updated, 0 files merged,
+ 0 files removed, 0 files unresolved
+
+So here, message says 0 files updated but we have just created a *tex* file inside it. Lets try to see status of our main repository by using *status(st)* command::
- $ hg add feviStick.py
- $ hg st
- A feviStick.py
+ $ cd letter
+ $ hg st
+ ? letter.tex
+
+"?" sign in front of file indicates that this file is alien to hg, as in we have to *add* it to repo by::
-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 add letter.tex
+ $ hg st
+ A letter.tex
+
+So file is now part of repository(A symbol). We *commit (alias ci)* it to repo and make changes effective ::
+
+ $ hg ci -u "Shantanu <shantanu@fossee.in>"
+ -m "First commit."
$ hg log
- changeset: 0:84f5e91f4de1
+ changeset: 0:210664b4ed58
tag: tip
user: Shantanu <shantanu@fossee.in>
- date: Fri Aug 21 23:37:13 2009 +0530
+ date: Tue Feb 23 19:41:45 2010 +0530
summary: First commit.
+Some arguments passed to *ci* command are worth noticing:
+ - *u* is to provide name and email contact information of person making changes!
+ - *m* is to provide one-line summary of changeset.
+
+If we don't give these options, *ci* will take us to a default editor, there we have to specify a commit *message* in first line, then we can edit other information like username, once done just exit the editor and changes are committed to the repo. Now these changes will be visible in logs.
+
Similar to add there are other commands available for file management in repo. *copy (alias cp)* command is used to mark files as copied for the next commit. ::
- $ hg cp feviStick.py pidiLite.py
- $ hg st
- A pidiLite.py
+ $ hg cp letter.tex letter-prof.tex
-*rename(alias mv)* rename files; equivalent of copy + remove. *tip* command shows newest revision in the repository. ::
+*rename(alias mv)* rename files; equivalent of copy + remove. ::
- $ hg rename pidiLite.py feviCol.py
+ $ hg rename letter.tex letter-personal.tex
$ hg st
- A feviCol.py
- $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Renamed pidiLite.py."
+ A letter-personal.tex
+ A letter-pro.tex
+ R letter.tex
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Renamed and added letters."
+
+*tip* command shows newest revision in the repository. ::
+
$ hg tip
- changeset: 1:d948fb4137c5
- tag: tip
+ changeset: 1:4a2d973a92de
user: Shantanu <shantanu@fossee.in>
- date: Sat Aug 22 00:11:25 2009 +0530
- summary: Renamed pidiLite.py.
-
-*remove* command is used to remove files from a repo. ::
-
- $ 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
+ date: Tue Feb 23 19:50:39 2010 +0530
+ summary: Renamed and added letters.
Sharing Changes:
----------------
@@ -337,19 +334,11 @@
Pulling from repo:
~~~~~~~~~~~~~~~~~~
-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 Fevicol-pull. There are a few ways that can be used to propagate this change into other repositories. ::
-
- $ hg clone Fevicol Fevicol-clone
- updating working directory
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+As mentioned earlier that repositories in Mercurial are self-contained. This means that the changeset just created exists only in *letter* repository and not in previously cloned . There are a few ways that can be used to propagate this change into other repositories. *pull* command will download all changeset from main repo. ::
-Or traverse into the any dir which is a working hg repo(using hg init) and pull command will download all changeset from main repo. ::
-
- $ mkdir Fevicol-pull
- $ cd Fevicol-pull
- $ hg init
- $ hg pull ../Fevicol
- pulling from ../Fevicol
+ $ cd letter-clone
+ $ hg pull
+ pulling from /home/baali/letter
requesting all changes
adding changesets
adding manifests
@@ -361,120 +350,112 @@
pull changes from the specified source
- Pull changes from a remote repository to a local one.
+ Pull changes from a remote repository to a local one.
- This finds all changes from the repository at the specified path
- or URL and adds them to the local repository. By default, this
- does not update the copy of the project in the working directory.
+ This finds all changes from the repository at the specified path
+ or URL and adds them to the local repository. By default, this
+ does not update the copy of the project in the working directory.
Some times, even before pulling changesets, one may need to see what changes would be pulled, Mercurial provides *hg incoming* to tell what changes *hg pull* would pull into repo, without actually pulling the changes. This command is really handy in case of avoiding unwanted changesets into the repo.
-With Mercurial, *hg pull* does not(by default) touch the working directory. Instead there is *hg up (alias update, co, checkout)* command to do this. ::
+As output of *pull* command suggests it does not(by default) update the working directory. By update we mean, content of files and directory structure still remains the same as prior to *pull* command. *hg up (alias update)* command updates repo by adding latest imported changesets and bringing it upto date. ::
- $ cd Fevicol-pull
- $ ls -a
- . .. .hg
- $ hg up
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
- $ ls -a
- . .. feviCol.py feviStick.py .hg
+ $ ls -a
+ . .. .hg
+ $ hg up
+ 2 files updated, 0 files merged,
+ 0 files removed, 0 files unresolved
+ $ ls -a
+ . .. .hg letter-personal.tex
+ letter-pro.tex
-To update to specific version, give a version number to the *hg update* command. ::
-
- $ hg update 0
- 0 files updated, 0 files merged, 1 files removed, 0 files unresolved
- $ hg parent
- changeset: 0:84f5e91f4de1
- user: Shantanu <shantanu@fossee.in>
- date: Fri Aug 21 23:37:13 2009 +0530
- summary: First commit.
-
-If no version number is specified *hg up* will update to the tip version. Version number of hg starts from 0. Compare *hg parent* output to the one before doing update to see the difference.
+To update to specific version, give a version number to the *hg update* command.
Making Changes:
~~~~~~~~~~~~~~~
-After getting the desired version of local repo, one can make changes as he/she needs and then make them available(share) for others. For these operations we will be working in Fevicol-clone repo which we created earlier. It's often good practice to keep a “pristine” copy of a remote repository around, which you can then make temporary clones of to create sandboxes for each task you want to work on. ::
-
- $ cd Fevicol-clone/
- $ cat feviStick.py
- print 'Yeh Fevicol ka Majboot jod hai'
-
-This tagline is correct for feviCol.py but for feviStick.py it should be different. ::
+Lets start with adding content to letters. For start personal letter can be a letter to ask a boy/girl out! Using LaTeX to write letter, it would be straight forward, open the file in any text editor and add the following content to it ::
- $ echo "print 'Ab no more Chip Chip'" > feviStick.py
- $ cat feviStick.py
- print 'Ab no more Chip Chip'
- $ hg st
- M feviStick.py
+ \documentclass{letter}
+ \begin{document}
+ \begin{letter}{}
+ \opening{Hello xxxxxx,}
+ I really enjoyed meeting you in CS 101,
+ but would love to know you better.
+ How about a coffee on Thursday after class?
+ \closing{-xxxxx}
+ \end{letter}
+ \end{document}
-Mercurial's hg status command will tell us what Mercurial knows about the files in the repository. 'M' sign in front of feviStick.py indicates that Mercurial has noticed change.
+Replace "xxxxx" with proper names to suite yourself. Mercurial's hg status command will tell us what Mercurial knows about the files in the repository. 'M' sign in front of feviStick.py indicates that Mercurial has noticed change(modified). ::
-It's somewhat helpful to know that feviStick.py was modified, but one might prefer to know exactly what changes were made to it. To do this, use the *hg diff* command. ::
+ $ hg st
+ M letter-personal.tex
+
+At times more information is needed on knowing exactly what changes were made to what files. To do this, use the *hg diff* command. ::
$ hg diff
- diff -r a7912d45f47c feviStick.py
- --- a/feviStick.py Sun Aug 23 22:34:35 2009 +0530
- +++ b/feviStick.py Sun Aug 23 22:47:49 2009 +0530
- @@ -1,1 +1,1 @@
- -print 'Yeh Fevicol ka Majboot jod hai'
- +print 'Ab no more Chip Chip'
+ diff -r 4a2d973a92de letter-personal.tex
+ --- a/letter-personal.tex Tue Feb 23 19:50:39 2010 +0530
+ +++ b/letter-personal.tex Tue Jun 08 16:12:19 2010 +0530
+ @@ -0,0 +1,11 @@
+ +\documentclass{letter}
+ +\begin{document}
+ +
+ +\begin{letter}{}
+ +\opening{Hello Jas,}
+ +
+ +I really enjoyed meeting you in CS 101, but would love to know you better. How about a coffee on Thursday after class?
+ +
+ +\closing{-Samarth}
+ +\end{letter}
+ +\end{document}
+
+We can modify files, build and test our changes, and use hg status and hg diff to review our changes, until we're satisfied with what we've done and arrive at a natural stopping point where we want to record our work in a new changeset. All the diffs prior to committing the changes would be done wrt earlier marked record.Then we use *hg commit* to create a new changeset
-We can modify files, build and test our changes, and use hg status and hg diff to review our changes, until we're satisfied with what we've done and arrive at a natural stopping point where we want to record our work in a new changeset. All the diffs prior to committing the changes would be done wrt earlier marked record.The hg commit command lets us create a new changeset.
+Mercurial records your name and email-address with each change that you commit, so that you and others will later be able to tell who made each change. It also tries to automatically figure out a sensible username to commit the change with. When we try to use *hg commit* there are various ways by which one can specify User name, some of those are:
+
+ - Specify a -u option to the hg commit command on the command line, followed by a username, this is the procedure we used earlier.
+ - set HGUSER environment variable::
-Mercurial records your name and address with each change that you commit, so that you and others will later be able to tell who made each change. Mercurial tries to automatically figure out a sensible username to commit the change with. When we try to use *hg commit* there are various ways by which one can specify User name, some of those are:
-
- - Specify a -u option to the hg commit command on the command line, followed by a username.
- - set HGUSER environment variable.
+ $ export HGUSER="xxxxx"
- Edit hgrc file present in .hg folder to set this property, add following lines to that file and Mercurial will read those parameters from that location. ::
[ui]
username = Firstname Lastname <email.address@example.net>
-For me the hgrc file looks like this: ::
+ For me the hgrc file for *letter* clone repo looks like this: ::
- [paths]
- default = /home/baali/Fevicol
- [ui]
- username = Shantanu Choudhary <shantanu@fossee.in>
+ [paths]
+ default = /home/baali/letter
+ [ui]
+ username = Shantanu Choudhary <shantanu@fossee.in>
Once this parameter is set, *hg commit* command drops us into a text editor, to enter a message that will describe the modifications we've made in this changeset. This is called the commit message. It will be a record for readers of what we did and why, and it will be printed by hg log after we've finished committing. ::
- Changed tagline for feviStick.py.
+ Added content to personal letter.
HG: Enter commit message. Lines beginning with 'HG:' are removed.
HG: --
HG: user: Shantanu Choudhary <shantanu@fossee.in>
HG: branch 'default'
- HG: changed feviStick.py
+ HG: changed letter-personal.tex
This would be your default system editor(for me it is vim, one can set it also), where you can enter the log message in first line, once you are done with log message quit the editor using *[ESC] key ":wq"*.Once we've finished the commit, we can use the hg tip command to display the changeset we just created. ::
$ hg tip
- changeset: 3:e1ab2aff4ddd
- tag: tip
- user: Shantanu Choudhary <shantanu@fossee.in>
- date: Sun Aug 23 23:32:01 2009 +0530
- summary: Changed tagline for feviStick.py.
-
+ changeset: 2:a5d8cb2fac01
+ user: Shantanu <shantanu@fossee.in>
+ date: Tue Feb 23 20:34:12 2010 +0530
+ summary: Added content to personal letter.
+
One can do above mentioned procedure using following one line command: ::
- $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Changed tagline for feviStick.py."
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Added content to personal letter."
Sharing Changes:
~~~~~~~~~~~~~~~~
-The *hg outgoing* command tells us what changes would be pushed into another repository. ::
-
- $ hg outgoing ../Fevicol
- comparing with ../Fevicol
- searching for changes
- changeset: 3:e1ab2aff4ddd
- tag: tip
- user: Shantanu Choudhary <shantanu@fossee.in>
- date: Sun Aug 23 23:32:01 2009 +0530
- summary: Changed tagline for feviStick.py.
-
-And the *hg push* command does the actual push. ::
+So now we have this *letter-clone* repo where we created above changes and committed them. But the main repo(*trunk*) that is *letter* wont be hinted of these changes. It will be still in older stage, same way as we pulled changes to this cloned repo from main branch at starting. To share changes from a cloned repo to main branch hg provides with *push* command. It is same as *pull* but instead of pulling it pushes the changes to trunk. ::
$ hg push ../Fevicol
pushing to ../Fevicol
@@ -484,24 +465,29 @@
adding file changes
added 1 changesets with 1 changes to 1 files
-As with hg pull, the hg push command does not update the working directory in the repository that it's pushing changes into. One has to use hg update to populate the changes in desired repo. ::
+Same as with hg pull, the hg push command populates the changesets nothing more. ::
- $ cd ../Fevicol
+ $ cd ../letter
$ hg tip
- changeset: 3:e1ab2aff4ddd
- tag: tip
- user: Shantanu Choudhary <shantanu@fossee.in>
- date: Sun Aug 23 23:32:01 2009 +0530
- summary: Changed tagline for feviStick.py.
- $ cat feviStick.py
- print 'Yeh Fevicol ka Majboot jod hai'
+ changeset: 2:a5d8cb2fac01
+ user: Shantanu <shantanu@fossee.in>
+ date: Tue Feb 23 20:34:12 2010 +0530
+ summary: Added content to personal letter.
+
+The branch where changes are being pushed still need *up* to be updated or for inclusion of all the imported changesets ::
-changesets are imported, but update is yet to be done. ::
-
- $ hg up tip
+ $ hg up
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
- $ $ cat feviStick.py
- print 'Ab no more Chip Chip'
+ $ cat letter-personal.tex
+ \documentclass{letter}
+ \begin{document}
+ \begin{letter}{}
+ \opening{Hello xxxx,}
+ I really enjoyed meeting you in CS 101, but would love to know you better. How about a coffee on Thursday after class?
+
+ \closing{-xxxx}
+ \end{letter}
+ \end{document}
Merging the Work:
~~~~~~~~~~~~~~~~~
@@ -510,110 +496,85 @@
Two persons, A and B are contributing on same project. Both starts from cloning the same online repo(lets say present state X), so that both have a working local repo. Now A edits one of file, commits the changes and pushes to the repo, hence changing the state of repo to Y, but B, have not updated his repo, makes a change in one of files and reaches to a different state Z. Now when A pulls repo from B, his repo will have multiple heads. This stage is clearly ambiguous, the repo of A is not consistent, it has multiple heads, and from here, whatever changes he makes can take whatsoever direction if it is not fixed, and hence A will have to merge changes so that everything becomes consistent again.
-Lets see how this work with working repo, we will use Fevicol and Fevicol-clone repositories created earlier. For now, the status of both repo is: ::
+Lets see how this work with working repo, we will use letter and letter-clone repositories created earlier. For now, the status of both repo is: ::
- $ cd Fevicol-clone
- $ hg tip
- changeset: 3:e1ab2aff4ddd
- tag: tip
- user: Shantanu Choudhary <shantanu@fossee.in>
- date: Sun Aug 23 23:32:01 2009 +0530
- summary: Changed tagline for feviStick.py.
+ $ cd letter-clone
+ $ hg tip
+ changeset: 2:a5d8cb2fac01
+ user: Shantanu <shantanu@fossee.in>
+ date: Tue Feb 23 20:34:12 2010 +0530
+ summary: Added content to personal letter.
-The tagline for feviCol.py is not complete, so we make changes in that file in this repo. ::
+We share(clones) this repo with a friend, he goes through the letter and just makes small change of adding color to clogins part of letter. ::
- $ echo "print 'Yeh Fevicol ka Majboot jod hai, tootega nahin'" > feviStick.py
- $ hg st
- M feviStick.py
+ $ hg diff
+ diff -r 4a2d973a92de letter-personal.tex
+ --- a/letter-personal.tex Tue Feb 23 19:50:39 2010 +0530
+ +++ b/letter-personal.tex Wed Feb 24 12:03:33 2010 +0530
+ @@ -0,0 +1,12 @@
+ \documentclass{letter}
+ +\usepackage{color}
+ \begin{document}
+ .
+ -\closing{-Samarth}
+ +\closing{\textcolor{red}{-Samarth}}
-And commit the changes made ::
+Here the "-" sign shows which lines are removed, and "+" indicates what lines are added. He is satisfied and commits the changes. ::
- $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Updated tag line for feviCol.py."
- $ hg st
+ $ hg ci -u "Vattam <vattam@fossee.in>" -m "Added some suggestions."
+ changeset: 3:71fd776d856b
+ parent: 2:a5d8cb2fac01
+ user: Vattam <vattam@fossee.in>
+ date: Wed Feb 24 12:54:31 2010 +0530
+ summary: Added some suggestions.
+
+In the meanwhile, it seems, our "xxxx" is already dating someone else. So we also change the name to "yyyy" who is available, and we commit it ::
+
+ $ cd letter
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Changed name."
$ hg tip
- changeset: 4:caf986b15e05
- tag: tip
+ changeset: 3:02b49a53063f
user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 16:28:24 2009 +0530
- summary: Updated tag line for feviCol.py.
+ date: Wed Feb 24 13:12:26 2010 +0530
+ summary: Changed name.
+
+So now we have two repo, who have different commit history and tree.
-Now we will make some changes on Fevicol repo. We will add new file here ::
+.. image:: glog-main.png
- $ cd Fevicol
- $ echo "print 'Jor laga ke hayyiya'" > firstAdd.py
- $ hg st
- ? firstAdd.py
- $ hg add firstAdd.py
- $ hg st
- A firstAdd.py
- $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Added firsAdd.py."
- $ hg tip
- changeset: 4:fadbd6492cc4
- tag: tip
- user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 16:46:24 2009 +0530
- summary: Added firsAdd.py.
-
-So now we have two repo, who have different commit history and tree, now if we try to pull changes from one to another, this is how it goes(we are still in Fevicol repo): ::
+.. image:: glog-suggestion.png
- $ hg pull ../Fevicol-clone
- pulling from ../Fevicol-clone
+If we try to pull changes from one to another, this is how it goes(we are still in letter repo): ::
+
+ $ hg pull ../letter-suggestion
+ pulling from ../letter-suggestion
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
- (run 'hg heads' to see heads, 'hg merge' to merge)
+ (run 'hg heads' to see heads, 'hg merge' to merge)
There we go, since both repo were on different track, hg pull command in last line gives some heading from here. *hg heads* command show current repository heads or show branch heads. ::
- $ hg heads
- changeset: 5:caf986b15e05
+ $ hg heads
+ changeset: 4:71fd776d856b
tag: tip
- parent: 3:e1ab2aff4ddd
- user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 16:28:24 2009 +0530
- summary: Updated tag line for feviCol.py.
-
- changeset: 4:fadbd6492cc4
- user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 16:46:24 2009 +0530
- summary: Added firsAdd.py.
+ parent: 2:a5d8cb2fac01
+ user: Vattam <vattam@fossee.in>
+ date: Wed Feb 24 12:54:31 2010 +0530
+ summary: Added some suggestions.
+
+ changeset: 3:02b49a53063f
+ user: Shantanu <Shantanu@fossee.in>
+ date: Wed Feb 24 13:12:26 2010 +0530
+ summary: Changed name.
To get better understanding of what is going on hg have a tool known as *glog* which shows revision history alongside an ASCII revision graph. ::
$ hg glog
- o changeset: 5:caf986b15e05
- | tag: tip
- | parent: 3:e1ab2aff4ddd
- | user: Shantanu <shantanu@fossee.in>
- | date: Tue Aug 25 16:28:24 2009 +0530
- | summary: Updated tag line for feviCol.py.
- |
- | @ changeset: 4:fadbd6492cc4
- |/ user: Shantanu <shantanu@fossee.in>
- | date: Tue Aug 25 16:46:24 2009 +0530
- | summary: Added firsAdd.py.
- |
- o changeset: 3:e1ab2aff4ddd
- | user: Shantanu Choudhary <shantanu@fossee.in>
- | date: Sun Aug 23 23:32:01 2009 +0530
- | summary: Changed tagline for feviStick.py.
- |
- o changeset: 2:a7912d45f47c
- | user: Shantanu <shantanu@fossee.in>
- | date: Sun Aug 23 22:34:35 2009 +0530
- | summary: Updated Content.
- |
- o changeset: 1:d948fb4137c5
- | user: Shantanu <shantanu@fossee.in>
- | date: Sat Aug 22 00:11:25 2009 +0530
- | summary: Renamed pidiLite.py.
- |
- o changeset: 0:84f5e91f4de1
- user: Shantanu <shantanu@fossee.in>
- date: Fri Aug 21 23:37:13 2009 +0530
- summary: First commit.
+
+.. image:: heads.png
To bring repo on single track/branch once again we will have to merge these two branches. Without merging them even hg update wont work for obvious reason of confusing track record. ::
@@ -624,50 +585,16 @@
$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
- (branch merge, don't forget to commit)
- $ hg tip
- changeset: 5:caf986b15e05
- tag: tip
- parent: 3:e1ab2aff4ddd
- user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 16:28:24 2009 +0530
- summary: Updated tag line for feviCol.py.
+ (branch merge, don't forget to commit)
After merging two branches, until we commit the results of merge it will keep on showing two heads. ::
- $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Merged branches of add and tag line."
- $ hg heads
- changeset: 6:edbe97209954
- tag: tip
- parent: 4:fadbd6492cc4
- parent: 5:caf986b15e05
- user: Shantanu <shantanu@fossee.in>
- date: Tue Aug 25 17:06:03 2009 +0530
- summary: Merged branches of add and tag line.
-
-Here is brief and meaningful output of glog ::
-
+ $ hg ci -u "Shantanu <shantanu@fossee.in>" -m "Merged branches."
$ hg glog
- @ changeset: 6:edbe97209954
- |\ tag: tip
- | | parent: 4:fadbd6492cc4
- | | parent: 5:caf986b15e05
- | | user: Shantanu <shantanu@fossee.in>
- | | date: Tue Aug 25 17:06:03 2009 +0530
- | | summary: Merged branches of add and tag line.
- | |
- | o changeset: 5:caf986b15e05
- | | parent: 3:e1ab2aff4ddd
- | | user: Shantanu <shantanu@fossee.in>
- | | date: Tue Aug 25 16:28:24 2009 +0530
- | | summary: Updated tag line for feviCol.py.
- | |
- o | changeset: 4:fadbd6492cc4
- |/ user: Shantanu <shantanu@fossee.in>
- | date: Tue Aug 25 16:46:24 2009 +0530
- | summary: Added firsAdd.py.
-And we are back on track.
+.. image:: glog-2.png
+
+*And we are back on track.*
Workflow:
=========
@@ -691,6 +618,11 @@
$ hg push
+Cheatsheet
+==========
+
+.. image:: mod.png
+
Suggested Reading:
==================
--- a/versionControl/vcs.tex Thu Jun 10 18:51:22 2010 +0530
+++ b/versionControl/vcs.tex Thu Jun 10 18:54:04 2010 +0530
@@ -123,30 +123,50 @@
% Introduction to course-need of version control, history, options available.
\section{Introduction}
+%% Home made version control system?
+\begin{frame}[fragile]
+ \frametitle{Home-brew}
+ \begin{center}
+ \includegraphics[height=1.8in,width=4.2in]{folder.png}
+ \end{center}
+ \begin{lstlisting}
+$ ls
+a.out id1.txt id2.txt identifier.cpp id.txt lex pda1.cpp pda2.cpp pda.cpp pda.txt string.txt
+ \end{lstlisting} %%$
+ %%a screen-shot of folder with all crazy names.
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{Problems with such nomenclature}
+ \begin{block}{}
+ \begin{itemize}
+ \item Difficult to relate to content of file.
+ \item Cant track changes done to file.
+ \item It wont scale.
+ \end{itemize}
+ \end{block}
+\end{frame}
+
\begin{frame}
- \frametitle{What is Version Control?}
+ \frametitle{What is version control}
\begin{block}{From a blog post}
- ``Version control (or source control) is nothing more arcane than keeping copies of ones work as one make changes to it.''
- \end{block}
- \pause
- \begin{block}{}
- It is better to use these tools rather than wasting creativity to invent VCS which have files with names like \begin{color}{red}{prog1.py, prog2.py}\end{color} or \begin{color}{red}prog-old.py, prog.py.\end{color}
+ ``Version control (or source control) is nothing more than keeping copies of work as we make changes to it.''
\end{block}
\end{frame}
-\begin{frame}
- \frametitle{Motivation behind such tools}
+\begin{frame}[fragile]
+ \frametitle{Need of Version Control}
\begin{itemize}
\item Track the history and evolution of a program.
\item To collaborate effectively on a project.
- \item \begin{color}{red}``To err is Human''\end{color} \pause for recovery we have ``Version Control''
+ \item \begin{color}{red}``To err is Human''\end{color} for recovery we have ...
\end{itemize}
\end{frame}
%% Introduction to how logs are managed in VCS.
%% A analogy in logs and day-to-day life?
\begin{frame}[fragile]
- \frametitle{How does it work?}
+ \frametitle{How does it work? Analogy}
It can roughly be related to Computer/Video Games.
\begin{itemize}
\item We play games in stages.
@@ -168,115 +188,134 @@
\begin{frame}
\frametitle{How is it done?}
\begin{itemize}
- \item It keeps track of changes you make to a file. You can improvise, revisit, and amend.
- \item All procedure is logged/recorded, so you and others can follow the development cycle.
+ \item It keeps track of changes you make to a file. You can improve, revisit, and amend.
+ \item All changes are logged/recorded, so you and others can follow the development cycle.
\end{itemize}
\end{frame}
-\begin{frame}
- \frametitle{Do we really need this?}
- \emphbar{For team of people working remotely(even different computers/machines) on a project, use of version control is inevitable!}
- \vspace{0.15in}
- \emphbar{For single person: managing projects and assignments becomes easy}
- \vspace{0.15in}
- \pause
- \emphbar{\color{red}{It is a good habit!}}
-\end{frame}
+
+%% Introduction to jargon
+%% This should have some excerpts from normal systems.
+%% Like diffs, folders etc.
+
+%% \section{Learning the Lingo!}
+
+%% \begin{frame}[fragile]
+%% \frametitle{Common jargon: Basic setup}
+%% \begin{lstlisting}
+%% $ ls slides/
+%% filter.png lena_mean.png lena.png
+%% neighbour.png pool.aux pool.log
+%% pool.nav pool.out pool.pdf pool.snm
+%% pool.tex pool.tex~ pool.toc pool.vrb
+%% \end{lstlisting} %%$
+%% \begin{itemize}
+%% \item Repository(repo):\\
+%% The folder with all files.
+%% %% \item Server:\\
+%% %% Machine with main inventory/repo.
+%% %% \item Client:\\
+%% %% Local machines with copy of main repo.
+%% \end{itemize}
+%% \end{frame}
+
+%% \begin{frame}[fragile]
+%% \frametitle{Actions}
+%% \begin{itemize}
+%% \item Add:\\
+%% Creating/Copying files(cp, touch).
+%% \item Check out/Clone:\\
+%% Creating copy of working folder.
+%% \end{itemize}
+%% \begin{lstlisting}
+%% $ cp -rv circulate/ local
+%% `circulate/' -> `local'
+%% `circulate/sslc1.txt' -> `local/sslc1.txt'
+%% `circulate/pos.txt' -> `local/pos.txt'
+%% `circulate/pendulum.txt' -> `local/pendulum.txt'
+%% `circulate/lena.png' -> `local/lena.png'
+%% `circulate/sslc1.py' -> `local/sslc1.py'
+%% `circulate/points.txt' -> `local/points.txt'
+%% \end{lstlisting} %%$
+%% \end{frame}
-\begin{frame}
- \frametitle{Whats on the menu!}
- \begin{itemize}
- \item cvs (Concurrent Version System)
- \item svn (Subversion)
- \item hg (Mercurial)
- \item bzr (Bazaar)
- \item git
- \end{itemize}
- \inctime{10}
-\end{frame}
+%% \begin{frame}
+%% \frametitle{Actions cont...}
+%% \begin{itemize}
+%% \item Version:\\
+%% Version number(Die Hard 4.0).\\
+%% Making changes to folder, changes state/version.
+%% \item Head/Tip:\\
+%% Most recent revision/stage.
+%% \item Commit:\\
+%% Saving(recording) a change.
+%% \item Change log/History:\\
+%% List of all past changes.
+%% \end{itemize}
+%% \end{frame}
-% Introduction to jargon
-\section{Learning the Lingo!}
+%% \begin{frame}
+%% \frametitle{Actions cont...}
+%% \begin{itemize}
+%% \item Branch:\\
+%% Separate local copy for bug fixing, testing.
+%% \item Diff/Change:\\
+%% Changes made in a file in two different versions.
+%% \item Merge (or patch):\\
+%% Appling the changes to file, to make it up-to-date.
+%% \item Conflict:\\
+%% When merging a file is not obvious.
+%% \item Resolve:\\
+%% Fixing the conflict manually.
+%% \end{itemize}
+%% \end{frame}
-\begin{frame}
- \frametitle{Common jargon: Basic setup}
- \begin{itemize}
- \item Repository(repo):\\
- The folder with all files.
- \item Server:\\
- Machine with main inventory/repo.
- \item Client:\\
- Local machines with copy of main repo.
- \end{itemize}
-\end{frame}
+%% % Types of Version Controls
+%% %% \section{Types of VCS}
+
+%% %% \begin{frame}
+%% %% \frametitle{Types:}
+%% %% Based on ways of managing the repo there are two types of VCS:
+%% %% \begin{itemize}
+%% %% \item Centralized VCS\\
+%% %% cvs, svn fall under this category.
+%% %% \item Distributed VCS\\
+%% %% hg, bzr, git follows this methodology.
+%% %% \end{itemize}
+%% %% \emphbar{We would be covering \typ{hg}}
+%% %% \end{frame}
\begin{frame}
- \frametitle{Actions}
- \begin{itemize}
- \item Add:\\
- Adding file into the repo for the first time.
- \item Version:\\
- Version number(Die Hard 4.0).
- \item Head/Tip:\\
- Most recent revision/stage.
- \item Check out/Clone:\\
- Initial download of working copy.
- \item Commit:\\
- Saving(recording) a change.
- \item Change log/History:\\
- List of all past changes.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Actions cont...}
- \begin{itemize}
- \item Branch:\\
- Separate local copy for bug fixing, testing.
- \item Diff/Change:\\
- Changes made in a file in two different versions.
- \item Merge (or patch):\\
- Appling the changes to file, to make it up-to-date.
- \item Conflict:\\
- When merging a file is not obvious.
- \item Resolve:\\
- Fixing the conflict manually.
- \end{itemize}
-\end{frame}
-
-% Types of Version Controls
-\section{Types of VCS}
-
-\begin{frame}
- \frametitle{Types:}
- Based on ways of managing the repo there are two types of VCS:
- \begin{itemize}
- \item Centralized VCS\\
- cvs, svn fall under this category.
- \item Distributed VCS\\
- hg, bzr, git follows this methodology.
- \end{itemize}
- \emphbar{We would be covering \typ{hg}}
-\end{frame}
-
-\begin{frame}
- \frametitle{Why hg?}
- \includegraphics[height=.75in, interpolate=true]{mercurial}
+ \frametitle{We will cover hg?}
+ \includegraphics[height=.75in, interpolate=true]{mercurial}\\
+ Because it is:
\begin{itemize}
\item Easy to learn and use.
\item Lightweight.
\item Scales excellently.
\item Written in Python.
\end{itemize}
- \inctime{10}
+ \inctime{15}
\end{frame}
% Initializing the repo, cloning, committing changes, pushing, pulling to repo.
\section{Getting Started}
+\begin{frame}
+ \frametitle{Objective}
+ \begin{block}{}
+ We will \alert{manage} letters collaboratively using \typ{hg}.
+ \end{block}
+
+ %% \pause
+ %% \begin{block}{Disclaimer}
+ %% Please note, objective is not to learn creative writing, but to learn \alert{hg(mercurial)} via \alert{interesting} use case.
+ %% \end{block}
+\end{frame}
+
\begin{frame}[fragile]
\frametitle{Getting comfortable:}
- For checking \typ{hg} installation and its version try:
+ For checking \typ{hg} installation and its version type:
\begin{lstlisting}
$ hg version
\end{lstlisting}
@@ -293,22 +332,34 @@
\begin{frame}[fragile]
\frametitle{Getting working/existing code base}
- \typ{clone} is used to make a copy of an existing repository. It can be both local or remote.
+ To get an already existing code base:
\begin{lstlisting}
$ hg clone
- http://hg.serpentine.com/tutorial/hello
- localCopyhello
+http://hg.serpentine.com/tutorial/hello
+localCopyhello
\end{lstlisting}
- And we get a local copy of this repository.
+\typ{localCopyhello} is copy of code-base.
\begin{lstlisting}
$ ls localCopyhello/
hello.c Makefile
\end{lstlisting}
\end{frame}
+%%introduction to clone, repo, server, client.
\begin{frame}[fragile]
- \frametitle{To start track-record on existing files}
- I have some files which I want to bring under version control. \typ{hg} provides \typ{init} command for this:
+ \frametitle{What did we do!}
+ \begin{block}{Explanation}
+ \begin{itemize}
+ \item<1-> \typ{hello} is a \alert{repo}, it's a collection of files and folders.
+ \item<2-> This repo is located on remote(\alert{server}) machine.
+ \item<3-> We copy(\alert{clone}) repo to our local machine.
+ \end{itemize}
+ \end{block}
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{Creating repo of existing files}
+ I have some files which I want to bring under version control. \typ{hg} provides \alert{\typ{init}} command for this:
\begin{lstlisting}
$ ls -a circulate/
. .. lena.png pendulum.txt points.txt pos.txt sslc1.py sslc1.txt
@@ -324,15 +375,14 @@
\frametitle{Starting fresh}
We can use \typ{init} to start a new repository also
\begin{lstlisting}
-$ mkdir Fevicol
-$ cd Fevicol/
-$ echo "print 'Yeh Fevicol ka majboot
- jod hai'" > feviStick.py
+$ mkdir letter
+$ cd letter
+$ touch letter.tex
$ ls -a
-. .. feviStick.py
+. .. letter.tex
$ hg init
$ ls -a
-. .. feviStick.py .hg
+. .. letter.tex .hg
\end{lstlisting}
\end{frame}
@@ -345,14 +395,28 @@
2 files updated, 0 files merged,
0 files removed, 0 files unresolved
\end{lstlisting}
- or
+ \alert{or}
\begin{lstlisting}
-$ hg clone Fevicol Fevicol-pull
+$ hg clone letter letter-clone
updating working directory
0 files updated, 0 files merged,
-0 files removed, 0 files unresolved
- \end{lstlisting}
- \inctime{20}
+0 files removed, 0 files unresolved
+ \end{lstlisting}
+\end{frame}
+
+%%introduction to branch
+\begin{frame}[fragile]
+ \frametitle{Why do we need branching?}
+ \begin{block}{}
+ \begin{itemize}
+ \item To keep separate set for \alert{experimentation}.
+ \item Simple way to \alert{backup} all in one go!
+ \item It helps in collaborative environment.
+ %% should we mention it at all? there is no need to know atleast here.
+ %% syncing and integrating in backup files and testing environment can also be mentioned.
+ \end{itemize}
+ \end{block}
+ \inctime{15}
\end{frame}
%% Should we here stress on how are distribute VCS have
@@ -360,8 +424,8 @@
%% or some other graphical representation.
\begin{frame}[fragile]
\frametitle{Revisiting saved points:history/logs}
- In \typ{hg}, the difference between consecutive stages is termed as changeset.\\
- Once we have saved stages, we need a mechanism to review and access them, for that use \typ{log} command.
+ In \typ{hg}, the difference between consecutive stages is termed as \alert{changeset}.\\
+ Once we have saved stages, we need a mechanism to review and access them, for that use \alert{\typ{log}} command.
\begin{lstlisting}
$ cd localCopyhello
$ hg log
@@ -370,15 +434,17 @@
\begin{frame}[fragile]
\frametitle{Understanding output}
- The output provides following information:
+ It provides following information:
\begin{itemize}
- \item changeset: Identifiers for the changeset.
- \item user: Person who created the changeset.
- \item date: Date and time of creation of changeset.
- \item summary: One line description.
+ \item \alert{changeset}: Identifiers for the changeset.
+ \item \alert{user}: Person who created the changeset.
+ \item \alert{date}: Date and time of creation of changeset.
+ \item \alert{summary}: One line description.
\end{itemize}
\end{frame}
+%% here we should have image of dotA or halo for resuming from a stage in game.
+
\begin{frame}[fragile]
\frametitle{History/Logs cont...}
By default \typ{log} returns complete list of all changes. \\
@@ -397,56 +463,70 @@
\begin{frame}[fragile]
\frametitle{Advancing through a stage:status}
We often need to add/delete some files from directory(repo). The structure keeps on evolving, and tools for handling them are needed.\\
- We will use the Fevicol repo we created earlier.
+ We will use the \typ{letter} repo we created earlier.
\begin{lstlisting}
-$ cd Fevicol
+$ cd letter
$ hg log
$ hg st
-? feviStick.py
+? letter.tex
\end{lstlisting} %%$
- \typ{st} (aka status) is command to show changed files in the working directory.\\
+ \alert{\typ{st}} (aka status) is command to show changed files in the working directory.\\
\end{frame}
%% track record is confusing for some. Duma have some doubts :(
\begin{frame}[fragile]
\frametitle{Adding files}
- "?" indicates that these file are aliens to track record.\\
- \typ{add} command is available to add new files to present structure.
+ "?" indicates that this file are aliens to track record.\\
+ \alert{\typ{add}} command is available to add new files to present structure.
\begin{lstlisting}
-$ hg add feviStick.py
+$ hg add letter.tex
$ hg st
-A feviStick.py
+A letter.tex
\end{lstlisting}
\end{frame}
\begin{frame}[fragile]
\frametitle{Saving present stage: committing}
\emphbar{This is equivalent to completing tasks, before reaching a stage where you want to save.}
- \typ{hg} uses \typ{ci}(aka \typ{commit}) command to save changes. So after adding file, we have to commit it also:
+ \typ{hg} uses \alert{\typ{ci}}(aka \typ{commit}) command to save changes. So after adding file, we have to commit it also:
\begin{lstlisting}
$ hg ci -u "Shantanu <shantanu@fossee.in>"
-m "First commit."
$ hg log
-changeset: 0:84f5e91f4de1
+changeset: 0:210664b4ed58
tag: tip
user: Shantanu <shantanu@fossee.in>
-date: Fri Aug 21 23:37:13 2009 +0530
-summary: First commit.
+date: Tue Feb 23 19:41:45 2010 +0530
+summary: First commit.
\end{lstlisting}
\end{frame}
+%% explanation of ci command??
+\begin{frame}[fragile]
+ \frametitle{\typ{ci} command}
+ Some arguments passed to \typ{ci} command are worth noticing:
+ \begin{itemize}
+ \item \alert{u}: To provide name and email contact information of person making changes!\\
+ In case you don't want to repeat that each time of committing, add info to \typ{hgrc} file.
+ \item<2-> \alert{m}: It is to provide one-line summary of changeset. \\
+ if this argument is not passed, hg takes you to editor to specify the message which is required to commit.
+ \end{itemize}
+\end{frame}
+
\begin{frame}[fragile]
\frametitle{Other operations}
\typ{hg} supports basic file-management functions like copy, remove, rename etc.
\begin{lstlisting}
-$ hg cp feviStick.py pidiLite.py
-$ hg rename pidiLite.py feviCol.py
+$ hg cp letter.tex letter-prof.tex
+$ hg rename letter.tex letter-personal.tex
$ hg st
-A feviCol.py
+A letter-personal.tex
+A letter-pro.tex
+R letter.tex
$ hg ci -u "Shantanu <shantanu@fossee.in>"
- -m "Added feviCol.py."
+ -m "Renamed and added letters."
$ hg tip| grep summary
-summary: Added feviCol.py.
+summary: Renamed and added letters.
\end{lstlisting} %$
%% Other commands which can be handy are \typ{remove}, \typ{revert} etc.
\inctime{10}
@@ -465,8 +545,9 @@
\end{itemize}
\end{itemize}
\begin{lstlisting}
+$ cd letter-clone
$ hg pull
-pulling from /home/baali/Fevicol
+pulling from /home/baali/letter
requesting all changes
adding changesets
adding manifests
@@ -478,48 +559,76 @@
\begin{frame}[fragile]
\frametitle{Pulling changesets cont...}
- \typ{pull} command doesn't update current directory, it just imports changesets. To add all these changes, use \typ{up}:
+ \alert{\typ{pull}} command doesn't update current directory, it just imports changesets. To add all these changes, use \alert{\typ{up}}:
\begin{lstlisting}
-$ cd Fevicol-pull
$ ls -a
. .. .hg
$ hg up
2 files updated, 0 files merged,
0 files removed, 0 files unresolved
$ ls -a
-. .. feviCol.py feviStick.py .hg
- \end{lstlisting}
+. .. .hg letter-personal.tex
+letter-pro.tex
+ \end{lstlisting} %% $
\pause
\emphbar{Why \typ{pull} and \typ{up} are needed separately?}
\end{frame}
\begin{frame}[fragile]
- \frametitle{Making changes across branches}
+ \frametitle{Content of letter}
+ Personal letter can be letter to ask a girl out!\\
+ Using LaTeX to write letter, it would be straight forward:
+
+ \begin{small}
+ \begin{block}{}
\begin{lstlisting}
-$ cd Fevicol-pull/
- \end{lstlisting} %$
- Lets edit and correct the feviStick.py
-\begin{lstlisting}
-$ echo "print 'Ab no more Chip Chip'"
- > feviStick.py
+\documentclass{letter}
+\begin{document}
+\begin{letter}{}
+\opening{Hello Jas,}
+I really enjoyed meeting you in CS 101,
+but would love to know you better.
+How about a coffee on Thursday after class?
+
+\closing{-Samarth}
+\end{letter}
+\end{document}
+
+ \end{lstlisting}
+ \end{block}
+ \end{small}
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{Sharing the changes!}
+ \begin{lstlisting}
$ hg st
-M feviStick.py
-\end{lstlisting}
- 'M' sign indicates that \typ{hg} has noticed change.\\
+M letter-personal.tex
+ \end{lstlisting} %%$
+ \alert{'M'} sign indicates that \typ{hg} has noticed change in that particular file.
\end{frame}
\begin{frame}[fragile]
\frametitle{Revisiting changes}
- To view changes made \typ{hg} provides \typ{diff}:
-\begin{lstlisting}
+ To view changes made \typ{hg} provides \alert{\typ{diff}}:
+ \begin{small}
+ \begin{lstlisting}
$ hg diff
-diff -r a7912d45f47c feviStick.py
---- a/feviStick.py Sun Aug 23 22:34:35 2009 +0530
-+++ b/feviStick.py Sun Aug 23 22:47:49 2009 +0530
-@@ -1,1 +1,1 @@
--print 'Yeh Fevicol ka Majboot jod hai'
-+print 'Ab no more Chip Chip'
+diff -r 4a2d973a92de letter-personal.tex
+--- a/letter-personal.tex Tue Feb 23 19:50:39 2010 +0530
++++ b/letter-personal.tex Tue Feb 23 20:28:46 2010 +0530
+@@ -0,0 +1,11 @@
++\documentclass{letter}
++\begin{document}
++
++\begin{letter}{}
++\opening{Hello Jas,}
++
++I really enjoyed meeting you in CS 101,
+.
+.
\end{lstlisting} %$
+ \end{small}
\end{frame}
\begin{frame}[fragile]
@@ -527,16 +636,16 @@
We have to commit these changes.
\begin{lstlisting}
$ hg ci -u "Shantanu <shantanu@fossee.in>"
- -m "Changed tagline for feviStick.py."
+ -m "Added content to personal letter."
\end{lstlisting} %$
\end{frame}
\begin{frame}[fragile]
\frametitle{Syncing two repos}
- To bring both the repos at same stage we have to \typ{push} differences.
+ To bring both the repos at same stage we have to \alert{\typ{push}} changesets
\begin{lstlisting}
$ hg push
-pushing to /home/baali/Fevicol
+pushing to /home/baali/letter
searching for changes
adding changesets
adding manifests
@@ -547,13 +656,14 @@
\begin{frame}[fragile]
\frametitle{Syncing cont...}
- Same as pulling, pushing wont update the main directory by default.
+ Same as \typ{pull}, \typ{push} wont update the main directory by default.
\begin{lstlisting}
-$ cd Fevicol
+$ cd letter
$ hg tip
-$ cat feviStick.py
- \end{lstlisting}
- \typ{tip} shows latest changeset, but content of file are not updated. We have to use \typ{up} on main branch
+$ cat letter-personal.tex
+ \end{lstlisting} %%$
+ \alert{\typ{tip}} shows latest changeset, but content of file are not updated.\\
+ We have to use \typ{up} on main branch
\begin{lstlisting}
$ hg up
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
@@ -570,35 +680,71 @@
\end{center}
\end{frame}
+\begin{frame}
+ \frametitle{Scenario cont...}
+ \begin{block}{}
+ \begin{itemize}
+ \item To make this letter better, I ask for suggestions.
+ \item Friend of mine, clones this repo and edit things.
+ \item When he/she pushes changes, I can decide to use them or not.
+ \end{itemize}
+ \end{block}
+\end{frame}
+
\begin{frame}[fragile]
- \frametitle{Making changes to one of repo}
+ \frametitle{Creating more clones for sharing}
+ I create a clone of repo which is accessible to my friend.
\begin{lstlisting}
-$ cd Fevicol-pull
-$ echo "print 'Yeh Fevicol ka Majboot jod
- hai, tootega nahin'" > feviCol.py
-$ hg st
-M feviStick.py
-$ hg ci -u "Shantanu <shantanu@fossee.in>"
- -m "Updated tag line for feviCol.py."
-$ hg tip| grep changeset
-changeset: 3:caf986b15e05
+$ hg clone letter letter-suggestion
+updating working directory
+2 files updated, 0 files merged, 0 files removed, 0 files unresolved
\end{lstlisting} %$
\end{frame}
+%% here we can have introduction to concept of DVCS and CVCS?
+
\begin{frame}[fragile]
- \frametitle{In the meanwhile, other repo is ...}
+ \frametitle{Suggestions!}
+ He is convinced that using some colored text would be a good idea.
+ He just adds color to closing part.
+ %% a comment on how bad is this idea :P
+ \begin{small}
\begin{lstlisting}
-$ cd Fevicol
-$ echo "print 'Jor laga ke hayyiya'"
- > firstAdd.py
-$ hg add
-$ hg st
-A firstAdd.py
+$ hg dif
+diff -r 4a2d973a92de letter-personal.tex
+--- a/letter-personal.tex Tue Feb 23 19:50:39 2010 +0530
++++ b/letter-personal.tex Wed Feb 24 12:03:33 2010 +0530
+@@ -0,0 +1,12 @@
+ \documentclass{letter}
++\usepackage{color}
+ \begin{document}
+.
+-\closing{-Samarth}
++\closing{\textcolor{red}{-Samarth}}
+ \end{lstlisting} %%$
+ \end{small}
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{Committing the changes}
+ He is satisfied with his minor changes, so he commits.
+ \begin{lstlisting}
+$ hg ci
+ -u "Vattam <vattam@fossee.in>"
+ -m "Added some suggestions."
+ \end{lstlisting} %%$
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{The other good half of repo...}
+ It turns out, in this process, Jas is already dating, so we edit the letter for someone else from same class.
+ \begin{lstlisting}
$ hg ci -u "Shantanu <shantanu@fossee.in>"
- -m "Added firsAdd.py."
+ -m "Changed name."
$ hg tip|grep changeset
changeset: 3:fadbd6492cc4
\end{lstlisting}
+ %%\emphbar{\alert{moral:} Don't wait for it!}
\end{frame}
%%\hspace*{-0.5in}
@@ -608,11 +754,11 @@
\begin{columns}
\column{0.5\textwidth}
\begin{block}{\center{main directory}}
- \includegraphics[height=2in, interpolate=true]{main}
+ \includegraphics[height=2in, interpolate=true]{glog-main}
\end{block}
\column{0.5\textwidth}
\begin{block}{\center{cloned directory}}
- \includegraphics[height=2in, interpolate=true]{clone}
+ \includegraphics[height=2in, interpolate=true]{glog-suggestion}
\end{block}
\end{columns}
\end{frame}
@@ -621,8 +767,8 @@
\frametitle{Merging}
\emphbar{Lets sync both these branches!}
\begin{lstlisting}
-$ hg pull ../Fevicol-pull
-pulling from ../Fevicol-pull
+$ hg pull ../letter-suggestion
+pulling from ../letter-suggestion
searching for changes
adding changesets
adding manifests
@@ -632,7 +778,8 @@
\end{lstlisting} %$
\begin{itemize}
\item \typ{pull} can be done from a branch explicitly also.
- \item Output is already suggesting something!
+ \pause
+ \item \alert{Output is already suggesting something!}
\end{itemize}
\end{frame}
@@ -642,18 +789,18 @@
Since hg \typ{pull} don't update the files directly, our changes are still safe. \typ{hg} provides some commands to help understand such problems.
\begin{tiny}
\begin{lstlisting}
-$ hg heads
-changeset: 4:c5f40fda69cf
+$ hg heads
+changeset: 4:71fd776d856b
tag: tip
-parent: 2:0b8286c48e88
-user: Shantanu <shantanuc@fosse.in>
-date: Fri Jan 22 19:43:46 2010 +0530
-summary: Updated tagline for feviCol.py.
+parent: 2:a5d8cb2fac01
+user: Vattam <vattam@fossee.in>
+date: Wed Feb 24 12:54:31 2010 +0530
+summary: Added some suggestions.
-changeset: 3:60edf0e499e7
-user: Shantanu <shantanuc@fosse.in>
-date: Fri Jan 22 19:47:58 2010 +0530
-summary: Added firstAdd.py.
+changeset: 3:02b49a53063f
+user: Shantanu <Shantanu@fossee.in>
+date: Wed Feb 24 13:12:26 2010 +0530
+summary: Changed name.
\end{lstlisting} %%$
\end{tiny}
It shows current repository heads or show branch head
@@ -665,7 +812,7 @@
$ hg glog
\end{lstlisting} %%$
\begin{center}
- \includegraphics[height=2in]{glog}
+ \includegraphics[height=2in]{heads}
\end{center}
It shows history alongside an ASCII revision graph.
\end{frame}
@@ -675,13 +822,14 @@
Because of different 'pasts', \typ{up} command fails.
\begin{lstlisting}
$ hg up
-abort: crosses branches (use 'hg merge' or 'hg update -C')
+abort: crosses branches (use 'hg merge'
+ or 'hg update -C')
\end{lstlisting} %$
\end{frame}
\begin{frame}[fragile]
\frametitle{Merging}
- To deal such situations \typ{hg merge} command merge working directory with another revision.
+ To deal such situations \typ{hg} \alert{merge} command merge working directory with another revision.
\begin{lstlisting}
$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
@@ -703,6 +851,17 @@
\end{frame}
\begin{frame}[fragile]
+ \frametitle{Revisiting history!}
+ In case earlier girl is available again and you are still looking for date you can \alert{revert} back to previous letter!
+ \begin{lstlisting}
+$ hg revert -r 2 -a
+reverting letter-personal.tex
+ \end{lstlisting} %%$
+ And the content changes. From here on you can further change your letter as you wish.
+ %% more options for revert are to explained here!
+\end{frame}
+
+\begin{frame}[fragile]
\frametitle{More information}
\begin{itemize}
\item \typ{merge} fails if there are conflicting changes.
@@ -710,15 +869,20 @@
\item Like two persons editing same file, same line and pushing it upstream.
\end{itemize}
\item In conflicts, one have to perform \typ{merge} manually.
- \item \typ{hg} provides \typ{incoming} command, which checks the would-be imported changes
+ \item \typ{hg} provides \alert{\typ{incoming}} command, which checks the would-be imported changes
\begin{itemize}
\item To avoid conflicting changes before importing.
\end{itemize}
\end{itemize}
+ \inctime{10}
\end{frame}
+%% Manual and force merge
+%% hgignore
+
+%% Reverting to previous versions!
% Steps to follow to make life easier. How to avoid/handle manual merges.
-\section{Work flow: DOS and DON'Ts}
+\section{Work flow: DOs and DON'Ts}
\begin{frame}
\frametitle{Motto behind hg}
@@ -728,14 +892,7 @@
\end{frame}
\begin{frame}
- \frametitle{Cheat Sheet}
- \begin{center}
- \includegraphics[height=2.8in]{mod}
- \end{center}
-\end{frame}
-
-\begin{frame}
- \frametitle{Steps to be followed}
+ \frametitle{Work-flow}
\begin{itemize}
\item Make changes.
\item Commit.
@@ -743,7 +900,40 @@
\item Merge(if required).
\item Push.
\end{itemize}
- \inctime{20}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Cheat Sheet}
+ \begin{center}
+ \includegraphics[height=2.8in]{mod}
+ \end{center}
+ \inctime{15}
+\end{frame}
+
+%% Move it to end of session. Once introduction part is
+%% over. Then mentioning about options and utility.
+\section{Use case and Options}
+
+\begin{frame}
+ \frametitle{Use cases}
+ \emphbar{For team of people working remotely(even different computers/machines) on a project, use of version control is inevitable!}
+ \vspace{0.15in}
+ \emphbar{For single person: managing projects and assignments becomes easy}
+ \vspace{0.15in}
+ \pause
+ \emphbar{\color{red}{It is a good habit!}}
+\end{frame}
+
+\begin{frame}
+ \frametitle{What are other options!}
+ \begin{itemize}
+ \item cvs (Concurrent Version System)
+ \item svn (Subversion)
+ \item hg (Mercurial)
+ \item bzr (Bazaar)
+ \item git
+ \end{itemize}
+ \inctime{5}
\end{frame}
\begin{frame}
@@ -760,6 +950,10 @@
\end{frame}
\end{document}
+Some more suggestions from Nishanth:
+revert
+resolve
+
Notes
-----