Merged heads.
--- a/Python_Problem_Set_1.tex Tue Aug 31 18:52:49 2010 +0530
+++ b/Python_Problem_Set_1.tex Tue Aug 31 19:10:09 2010 +0530
@@ -1,3 +1,4 @@
+%% a comment
\documentclass[11pt]{article}
\title{Basic Python Problem Set 1}
\author{Asokan Pichai}
--- a/basic_python/oop.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/basic_python/oop.rst Tue Aug 31 19:10:09 2010 +0530
@@ -3,7 +3,7 @@
In the previous sections we learnt about functions which provide certain level
of abstraction to our code by holding the code which performs one or more
-specific functionalities. We were able to use this function as many times as we
+specific functionality. We were able to use this function as many times as we
wanted. In addition to functions, Python also higher level of abstractions
through *Classes* and *Objects*. *Objects* can be loosely defined as a
collection of a set of data items and a set of methods. The data items can be
@@ -31,7 +31,7 @@
which it was called as the first argument. It is conventionally given the name,
*self*. Note that *self* is only a convention. You can use any other name, but
the first argument to the method will always be the same object of the class
-from which the method was called. The data memebers that belong to the class are
+from which the method was called. The data members that belong to the class are
called as *class attributes*. *Class attributes* are preceded by the object of
the class and a dot. In the above example, *name* is a class attribute since it
is preceded by the *self* object. *Class attributes* can be accessed from
@@ -70,3 +70,45 @@
print e.name
AttributeError: Employee instance has no attribute 'name'
+It is also possible to assign values to the attributes using the above notation::
+
+ >>> emp = Employee()
+ >>> emp.name = 'John'
+ >>> print emp.name
+ John
+
+Magic methods
+-------------
+
+Python reserves a number of names starting and ending with **__**. Note that it
+is a double underscore. We must not invent names of this kind in our programs.
+These methods are generally referred to as *Magic methods* or sometimes called
+as *Special Methods*. Each *Magic method* performs a specific function. One such
+magic method we will discuss now is **__init__** method. If you are from C++
+background, the **__init__** method is analogous to the class constructor. This
+method is called a constructor because, it is implicitly called everytime a new
+instance of the class is created. So effectively **__init__** method constructs
+the object from the class and sets up some initial values for the object. Other
+than the above special properties, the **__init__** method is similar to any other
+class method. The argument passing rules are same for **__init__** method. Although,
+since **__init__** is called when the object is created we need to pass the
+arguments to the class name we call while creating the object. It passes the
+arguments to the **__init__** method::
+
+ class Employee:
+ def __init__(self, name):
+ self.name = name
+
+ def getName(self):
+ return self.name
+
+ >>> emp = Employee('John')
+ >>> print emp.getName()
+ John
+
+
+Writing Object Oriented Code
+----------------------------
+
+Object oriented code mainly encompasses three components: Encapsulation, Inheritence and Polymorphism.
+Lets briefly look at each of them with examples.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tdd/tdd.rst Tue Aug 31 19:10:09 2010 +0530
@@ -0,0 +1,78 @@
+Fundamentals
+============
+
+Test Driven Development, abbreviated as TDD is a method of software
+development which banks on the idea of writing test cases that fail for the
+code that doesn't even exist yet. The actual code is written later to pass
+the test and then refactored.
+
+Writing tests
+=============
+
+Writing a test is simple. Writing a failing test? It is much more simple.
+Let us consider a very simple program which returns the Greatest Common
+Divisor (GCD) of two numbers. Since the test cases for the code is written
+prior to the code itself, it is necessary to have a clear idea of the code
+units that our program will contain. Let us attempt to clearly define the
+code units in our case of a GCD program. Let our program contain one and
+only one function called gcd() which takes in two arguments as parameters.
+These arguments are the numbers for which GCD must be computed. The gcd()
+function returns a single value which is the GCD of the two arguments
+passed. So if we want to find out GCD of 44, 23, I will call my code unit
+as c = gcd(44, 23) where c will contain the GCD of those two numbers.
+
+Now we have defined our code units, how will we write tests? Before writing
+the test, a very fundamental question arises in our minds. How do tests
+look like? So let us answer this question first. Tests are nothing but a
+series of assertions which are either True or False depending on the
+expected behaviour of the code. We tell our tests whether our code unit
+asserts True or asserts False based on the expected behaviour of the code
+units. If we happen to run the tests now we are sure to get errors. Oh! But
+why? We don't even have the function gcd to call. The test code doesn't
+even compile! So what should we do now? So the idea is to first write the
+stubs for the code units before we start writing tests. This is necessary
+for two reasons. Firstly, by writing the stubs for the code units we will
+be able to correctly decide and fix on to the code units that we have
+planned to include in our program. We have a clear cut idea as to how our
+program is structured, how the tests must be written among other
+things. Secondly, the tests must at least compile and then fail! If the
+tests don't even compile, that doesn't mean the tests failed. It means
+it was a failure on the programmer's part. Let us define our stub::
+
+ def gcd(a, b):
+ pass
+
+This stub does nothing other than defining a new function called gcd which
+takes two parameters a and b for which the GCD must be calculated. The body
+of the function just contains pass which means it does nothing, i.e. empty.
+We have our stub ready. One important thing we need to keep in mind when
+we adopt TDD methodology is that we need to have a clear set of results
+defined for our code units. To put it more clearly, for every given set of
+inputs as test case we must have, before hand, the exact outputs that are
+expected for those input test cases. If we don't have that we have failed
+in the first step of the TDD methodology itself. We must never run for
+outputs for our test cases after we have the code ready or even while
+writing tests. The expected outputs/behaviour must be in our hands before
+we start writing tests. Therefore let us define our test cases and the
+expected output for those inputs. Let one of our test cases be 48 and 64
+as *a* and *b* respectively. For this test case we know that the GCD is
+16. So that is the expected output. Let our second test case be 44 and
+19 as *a* and *b* respectively. We know that their GCD is 1 by simple paper
+and pen calculation.
+
+Now we know what a test is? What are the ingredients required to write
+tests? So what else should we wait for? Let us write our first test!::
+
+ tc1 = gcd(48, 64)
+ if tc1 != 16:
+ print "Test failed for the case a=48 and b=64. Expected 16. Obtained
+ %d instead." % tc1
+ exit(1)
+
+ tc2 = gcd(44, 19)
+ if tc2 != 1:
+ print "Test failed for the case a=44 and b=19. Expected 1. Obtained
+ %d instead." % tc2
+ exit(1)
+
+ print "All tests passed!"
--- a/ult/Section_5.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/ult/Section_5.rst Tue Aug 31 19:10:09 2010 +0530
@@ -1,18 +1,3 @@
-Module Objectives:
-==================
-
-After successfully completing this module a participant will be able to: ::
-
- - Understand
- * What are archives and zipped files U
- * What are environment variables U
- * What are Shell Scripts U
- - Able to use file comparison commands like Ap
- diff, cmp, comm
- - Create and extract archives(.tar files) and zipped files(.gz) Ap
- - Set/Modify environment as per need Ap
- - Create shell scripts to automate tasks. Ap
-
tar:
====
@@ -23,7 +8,7 @@
GNU tar creates and manipulates archives which are actually collections of many other files; the program provides users with an organized and systematic method for controlling a large amount of data. It is basically form of creating archive by concatenating one or more files.
-Getting Started(go go go!):
+Getting Started:
---------------------------
As mentioned previously and if not, *The best way to get started with any command line tool of Linux is to use "man".* ::
@@ -151,12 +136,6 @@
second.txt
-Further Reading for this section:
----------------------------------
-
- * http://en.wikipedia.org/wiki/Tar_(file_format)
- * http://www.gnu.org/software/tar/manual/tar.html
- * http://linuxreviews.org/beginner/
GZip:
=====
@@ -196,7 +175,7 @@
second.txt: -4.8% -- replaced with second.txt.gz
third.txt: 3.8% -- replaced with third.txt.gz
-For files of very small sizes and some other cases, one might end up with a zipped file whose size is greater then original file, but compression is always performed(so don't be disheartened in the above case, as files are larger :P). So unlike tar, here all files are zipped separately by default, to make them part of one single chunk one can use some *pipes* and *redirections* ::
+
$ gzip -c *.txt > all.gz
@@ -212,7 +191,9 @@
./allfiles.tar: 96.6% -- replaced with ./allfiles.tar.gz
./fourth.txt: -7.1% -- replaced with ./fourth.txt.gz
-Hence one always sees files like xxxxx.tar.gz, to create a zip of whole directory in a single file, first archive everything inside a folder and then use gzip on that. For zipping the files using tar itself, one has to use the option *`g`*. ::
+Hence one always sees files like something.tar.gz, to create a zip of whole directory in a single file, first archive everything inside a folder and then use gzip on that. For zipping the files using tar itself, one has to use the option *`g`*. ::
+
+
$ tar -cvzf zipped.tar.gz *.txt
first.txt
@@ -228,7 +209,7 @@
compressed uncompressed ratio uncompressed_name
332 10240 97.0% zipped.tar
-Other feature of gzip is option for mentioning the kind of compression one wants. There is a option of *`-n`* where *n varies from 0 to 9* which regulate the speed/quality of compression. With *`-1`* or *`--fast`* option it means the fastest compression method (less compression) and *`--best`* or *`-9`* indicates the slowest compression method, default compression level is *`-6`*.
+
To decompress a already compressed file there are two options, either use *`gunzip`* command or use *`-d`* option with gzip command: ::
@@ -263,15 +244,7 @@
cmp:
----
-If one wants to compare two files whether they are same or not, one can use this handy tool. Let us consider some situation, we run find/locate command to locate some file, and it turns out that we have a file with same name in different location, and in case we want to run a quick check on there content, cmp is the right tool. For my system I perform these tasks to illustrate the use of this command: ::
-
- $ find . -name quick.c
- ./Desktop/programs/quick.c
- ./c-folder/quick.c
- $ cmp Desktop/programs/quick.c c-folder/quick.c
- $
-
-For me it returns nothing, hence that means both the files are exact copy of each other, by default, cmp is silent if the files are the same. Make some changes in one of the file and rerun the command. For me it works like this: ::
+If one wants to compare two files whether they are same or not, one can use this handy tool. Let us consider some situation, we run find/locate command to locate some file, and it turns out that we have a file with same name in different location, and in case we want to run a quick check on there content, cmp is the right tool. Usage ::
$ cmp Desktop/programs/quick.c c-folder/quick.c
Desktop/programs/quick.c c-folder/quick.c differ: byte 339, line 24
@@ -283,9 +256,9 @@
Now there are situations when one wants to exactly know the differences among two files, for them, GNU diff can show whether files are different without detailing the differences. For simple and basic usage of this programs, consider following example: ::
- $ echo -e "quick\nbrown\nfox\njumped\nover\nthe\nlazy\ndog" > allcharacters.txt
- $ echo -e "quick\nbrown\nfox\njmuped\nover\nteh\nlzay\ndog" > problem.txt
- $ diff problem.txt allcharacters.txt
+ $ echo -e "quick\nbrown\nfox\njumped\nover\nthe\nlazy\ndog" > allcorrect.txt
+ $ echo -e "quick\nbrown\nfox\njmuped\nover\nteh\nlzay\ndog" > incorrect.txt
+ $ diff problem.txt allc.txt
4c4
< jmuped
---
@@ -299,7 +272,7 @@
Looking at results above mentioned it is very trivial to deduce that, diff if used on two separate text files will result in line by line results for all the lines which are different. So most common use case scenario can be, got some files in various location of system with same name and size, just run diff through them and remove all the redundant files. Other similar command which one can find more effective for this can be *sdiff*, for the same files using sdiff will result in: ::
- $ sdiff problem.txt allcharacters.txt
+ $ sdiff incorrect.txt allcorrect.txt
quick quick
brown brown
fox fox
@@ -309,18 +282,13 @@
lzay | lazy
dog dog
-Some exercise for a change:
-
- * Try using diff for any binary file, does it work?
- * What are other equivalent for diff command based on needs/requirements?
- * Can we use diff to compare two directories? If yes how?
comm:
-----
This is one more command which proves handy at times, the short and sweet man page states "compare two sorted files line by line". Or this it compares sorted files and selects or rejects lines common to two files. For ex: ::
- $ sort allcharacters.txt>sortedcharac.txt; sort problem.txt>sortedprob.txt
+ $ sort allcorrect.txt>sortedcharac.txt; sort incorrect.txt>sortedprob.txt
$ comm sortedcharac.txt sortedprob.txt
brown
dog
@@ -339,12 +307,12 @@
These variables like HOME, OSTYPE,Variables are a way of passing information from the shell to programs when you run them. Programs look "in the environment" for particular variables and if they are found will use the values stored. Standard UNIX variables are split into two categories, environment variables and shell variables. In broad terms, shell variables apply only to the current instance of the shell and are used to set short-term working conditions; environment variables have a farther reaching significance, and those set at login are valid for the duration of the session.By convention, environment variables have UPPER CASE and shell variables have lower case names.
-Some of examples of Environment variables are(result may vary!): ::
+Some of examples of Environment variables are: ::
$ echo $OSTYPE
linux-gnu
$ echo $HOME
- /home/baali
+ /home/user
To see all the variables and there values use any of following commands: ::
@@ -362,15 +330,8 @@
*set* command is used to define a variable for the current shell. Try opening a new shell and use the above mentioned command, it wont work as expected. The other child process wont be able to see these variables unless we *export* them. Repeat the above mentioned activity with *export* command. Now with all new shells, *$repo* will work.
-Again these changes are limited to current session. To make them permanent or get loaded each time you log in, just add those lines to *.bashrc* file.
-
-Further Reading:
-----------------
- * http://lowfatlinux.com/linux-environment-variables.html
- * http://www.codecoffee.com/tipsforlinux/articles/030.html
- * http://www.ee.surrey.ac.uk/Teaching/Unix/unix8.html
- * http://en.wikipedia.org/wiki/Environment_variable
+
Shell Scripting:
@@ -382,7 +343,7 @@
Shell program or shell script,a sequence of commands to a text file and tell the shell to execute the text file instead of entering the commands. The first *"Hello World"* sample for shell scripting is as easy as it sounds: ::
$ echo '#!/bin/sh' > my-script.sh
- $ clear >> my-script.sh
+ $ echo 'clear' >> my-script.sh
$ echo 'echo Hello World' >> my-script.sh
$ chmod 755 my-script.sh
$ ./my-script.sh
@@ -408,9 +369,9 @@
echo "Last modified: $last_modified"
$ ./search.sh fname
-Try giving some file you want to search in place of fname. Please note in second line *`* its a back-quote(other key mapped with tilda), it is specifically used to get the output of one command into a variable. In this particular case name is a User defined variables (UDV) which stores the value. We access value stored in any variable using *$* symbol before name of variable.
+Try giving some file you want to search in place of fname. Please note in second line *`* its a back-quote(other key mapped with tilda), it is specifically used to get the output of one command into a variable. In this particular case name is a User defined variables which stores the value. We access value stored in any variable using *$* symbol before name of variable.
-naming conventions for variables?? do we need them??
+
Shell Arithmetic:
-----------------
@@ -483,7 +444,7 @@
fi
fi
-One important thing to not in shell script is spacing, with many comparison and evaluation operation a wrongly placed space will spoil all the fun. So in previous example the expression *[ $# -eq 0 ]* will work properly, but if we remove those leading or trailing spaces like *[ $# -eq 0]*, it wont work as expected, or rather throw a warning. Both *test* and *[]* do the same task of testing a expression and returning true or false.
+One important thing to note in shell script is spacing, with many comparison and evaluation operation a wrongly placed space will spoil all the fun. So in previous example the expression *[ $# -eq 0 ]* will work properly, but if we remove those leading or trailing spaces like *[ $# -eq 0]*, it wont work as expected, or rather throw a warning. Both *test* and *[]* do the same task of testing a expression and returning true or false.
Lets create something interesting using these if-else clause. Now we will create a script which will greet the user when he opens the shell. We will create the script, change the permission to make it executable and append the *.bashrc* file with *./greet.sh* line and we are done. The script is: ::
@@ -509,7 +470,7 @@
For me when I open the shell the output is something like: ::
- Good Morning baali, Have a nice day!
+ Good Morning user, Have a nice day!
This is Wednesday 16 in September of 2009 (11:54:47 AM IST)
Loops
@@ -558,16 +519,16 @@
echo "$i -> $j"
done
-Now we just replace the echo command with a ``mv`` or a ``cp`` command.
+Now we just replace the echo command with a ``mv`` command.
::
for i in *.mp3
do
j=$(echo "$i"|grep -o "[A-Za-z'&. ]*.mp3")
- cp "$i" "$j"
+ mv "$i" "$j"
done
-As an exercise, you could try sorting the files in reverse alphabetical order and then prefix numbers to each of the filenames.
+
``while``
~~~~~~~~~
@@ -646,14 +607,10 @@
Functions
---------
-When a group of commands are repeatedly being used within a script, it is convenient to group them as a function. This saves a lot of time and you can avoid retyping the code again and again. Also, it will help you maintain your code easily. Let's see how we can define a simple function, ``hello-world``. Functions can be defined in bash, either using the ``function`` built-in followed by the function name or just the function name followed by a pair of parentheses.
+When a group of commands are repeatedly being used within a script, it is convenient to group them as a function. This saves a lot of time and you can avoid retyping the code again and again. Also, it will help you maintain your code easily. Let's see how we can define a simple function, ``hello-world``. Function can be defined by using function name followed by a pair of parentheses.
::
- function hello-world
- {
- echo "Hello, World.";
- }
-
+
hello-world () {
echo "Hello, World.";
}
@@ -664,21 +621,40 @@
Passing parameters to functions is similar to passing them to scripts.
::
- function hello-name
+
+ #! /bin/bash
+
+ hello-name()
+ {
+ echo "hello ". $1
+
+ }
+
+ hello-name $1
+
+
+ #!usr/bin/bash
+ hello-name
{
echo "Hello, $1.";
}
- $ hello-name 9
+ hello-name $1
+
+ save this in a file helloscipt.sh and give it execute permission
+
+
+ $ ./helloscipt 9
Hello, 9.
Any variables that you define within a function, will be added to the global namespace. If you wish to define variables that are restricted to the scope of the function, define a variable using the ``local`` built-in command of bash.
+
We shall now write a function for the word frequency generating script that we had looked at in the previous session.
::
- function word_frequency {
+ word_frequency() {
if [ $# -ne 1 ]
then
echo "Usage: $0 file_name"
@@ -691,13 +667,8 @@
fi
}
-As an exercise, modify the function to accept the input for the number of top frequency words to be shown (if none is given, assume 10).
+ word_frequency $1
-Further Reading:
-----------------
- * http://www.freeos.com/guides/lsst/
- * http://bash.cyberciti.biz/guide/Main_Page
- * http://tldp.org/LDP/abs/html/
- * http://tldp.org/LDP/Bash-Beginners-Guide/html/Bash-Beginners-Guide.html
+
--- a/ult/Using_Linux_Tools.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/ult/Using_Linux_Tools.rst Tue Aug 31 19:10:09 2010 +0530
@@ -1,28 +1,12 @@
Introducing Linux
=================
-(Attribution : A significant chunk of the content under this section is based on data from Wikipedia and the Linux Documentation Project)
-
-Linux (usually pronounced ˈlɪnəks') is a generic term referring to Unix-like computer operating systems based on the Linux kernel, where a kernel is the intermediate layer between the hardware and the applications. The kernel is, on an abstract level, the core of (most) operating systems, that manages the various system resources. The development of the Linux OS is considered the basis for Free and Open Source Software (FOSS) collaboration since typically the underlying source code can be used, modified freely, and redistributed by anyone under the terms of the GNU (a recursive acronym for "GNU's Not Unix!") Global Public License (GPL) and other free software licences. This freedom to access and reuse various components of a system, is one of the primary reasons for the popularity of Linux.
-
-Linux is installed on a variety of computer hardware, that include mobile phones, embedded devices and supercomputers, but is infamous for its use in servers.
-
-The name "Linux" comes from the Linux kernel, originally written in 1991 by Linus Torvalds. The rest of the system usually comprises components such as the Apache HTTP Server, the X Window System, the GNOME and KDE desktop environments, and utilities and libraries from the GNU Project (announced in 1983 by Richard Stallman). Commonly-used applications with desktop Linux systems include the Mozilla Firefox web-browser and the OpenOffice.org office application suite. The GNU contribution is the basis for the Free Software Foundation's preferred name GNU/Linux. The kernel's mascot is a penguin named "Tux". Mozilla Firefox and OpenOffice.org are open-source projects which can be run on most Operating Systems, including proprietary ones.
-
-Historical Background
-----------------------
+We are here to welcome you to Linux. GNU/Linux is an operating system that is similar to the UNIX operating system, but is open source software. Being an open source program means that (if you wanted to) you could view the source code of the operating system and change it to suit your needs.
-Events leading to the creation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- The Unix operating system was developed in the 1960s and released for public use in 1970. Its accessibility and portability caused it to be widely adopted, copied and modified by academic institutions and businesses. Its design became influential to authors of other systems. Other free operating systems include the Berkeley Software Distribution (BSD), developed at the University of California at Berkeley, and MINIX which was released by Andrew S. Tanenbaum. The development and adoption of BSD and MINIX were limited due to various reasons, and this lack of a widely-adopted and free kernel triggered Linus Torvalds into starting his project.
-
-- In 1983, Richard Stallman started the GNU project with the goal of creating a free UNIX-like operating system. As part of this work, he wrote the GNU General Public License (GPL). By the early 1990s there was almost enough available software to create a full operating system. However, the GNU kernel, called Hurd, failed to attract enough attention from developers leaving GNU incomplete.
+The name "Linux" properly refers to an operating system "kernel", a single but key component of a complete operating system. In everyday use, the term "Linux" is frequently used to refer to a complete operating system which consists of the kernel and some of the thousands of other programs required to make an operating system useful. Much of the important system software that is typically installed on a Linux system comes from The GNU Project, a project to build an operating system made entirely of free software.
+The first Linux kernel was created by Linus Torvalds. It was started as an x86-only, single processor operating system, but grew to become one of the most ported pieces of software. Other parts of a complete GNU/Linux system come from other projects such as the GNU project, and are integrated into a complete GNU/Linux OS by your supplier. Usually your supplier will assign their own version number to the integrated whole.This collection of the kernal and programs maintained by vendor is called distro or distribution.
+The GNU Project is overseen by the Free Software Foundation. The Free Software Foundation was founded by Richard Stallman. Stallman believes that the people should use the term "GNU/Linux" to refer to such an operating system, because so many of the required programs were in fact, written as part of the GNU Project.
-The Creation of Linux
-~~~~~~~~~~~~~~~~~~~~~~
-In 1991, Linus Torvalds began a project at the University of Helsinki that later became the Linux kernel. It was initially a terminal (command-line) emulator, which Torvalds used to access the large UNIX servers of the university. He wrote the program targeting just the hardware he was using and independent of an operating system because he wanted to use the functions of his computer with an 80386 processor. Development was done on Minix using the GNU C compiler. This application is still the main choice for compiling Linux today (although the code can be built with other compilers, such as the Intel C Compiler).
-
-Torvalds continues to direct the development of the kernel. Stallman heads the Free Software Foundation, which in turn supports the GNU components. Finally, individuals and corporations develop third-party non-GNU components, which constitute a vast body of work and including kernel modules, and user applications and libraries. Linux vendors and communities combine and distribute the kernel, GNU components, and non-GNU components, with additional package management software in the form of Linux distributions.
Design and Implications
@@ -30,40 +14,9 @@
A Linux-based system is a modular Unix-like operating system, deriving much of its basic design from principles established in Unix earlier. Such a system uses a monolithic kernel, called the Linux kernel, which handles process control, networking, and peripheral and file system access. Device drivers are integrated directly with the kernel. Separate projects that interface with the kernel provide much of the system's higher-level functionality. The GNU userland is an important part of most Linux-based systems, providing the most common implementation of the C library, a popular shell, and many of the common Unix tools which carry out many basic operating system tasks. The graphical user interface (or GUI) used by most Linux systems is based on the "X Window System".
-User Interface
-~~~~~~~~~~~~~~
-Users can control a Linux-based system through a command line interface (or CLI), a graphical user interface (or GUI), or through controls attached to the associated hardware (this is common for embedded systems). For desktop systems, the default mode is usually the GUI. On desktop machines, "KDE", "GNOME" and "Xfce" are the most popular user interfaces,though a variety of additional user interfaces exist. Most popular user interfaces run on top of the "X Window System" (or X), which enables a graphical application running on one machine to be displayed and controlled from another in a network.
-A Linux system also provides a CLI of some sort through a shell, which is the traditional way of interacting with a Unix system. A Linux distribution specialized for servers may use the CLI as its only interface. A “headless system” (system run without even a monitor) can be controlled by the command line via a remote-control protocol such as SSH or telnet. The CLI is particularly suited for automation of repetitive or delayed tasks, and provides very simple inter-process communication. A graphical terminal emulator program is often used to access the CLI from a Linux desktop.
-
-Development
-~~~~~~~~~~~
-The primary difference between Linux and many other popular contemporary operating systems is that the Linux kernel and other components are free and open source software. Linux is not the only such operating system, although it is by far the most widely used. Some free and open source software licenses are based on the principle of "copyleft", a kind of reciprocity: any work derived from a copyleft piece of software must also be copyleft itself. The most common free software license, the GNU GPL, is a form of copyleft, and is used for the Linux kernel and many of the components from the GNU project.
-
-Linux based distributions are intended by developers for interoperability with other operating systems and established computing standards. Linux systems adhere to POSIX, SUS, ISO and ANSI standards where possible, although to date only one Linux distribution has been POSIX.1 certified, Linux-FT.Free software projects, although developed in a collaborative fashion, are often produced independently of each other. The fact that the software licenses explicitly permit redistribution, however, provides a basis for larger scale projects that collect the software produced by stand-alone projects and make it available all at once in the form of a Linux distribution.
-
-A Linux distribution, commonly called a "distro", is a project that manages a remote collection of system software and application software packages available for download and installation through a network connection. This allows the user to adapt the operating system to his/her specific needs. Distributions are maintained by individuals, loose-knit teams, volunteer organizations, and commercial entities. A distribution can be installed using a CD that contains distribution-specific software for initial system installation and configuration. A package manager such as Synaptic or YAST allows later package upgrades and installations. A distribution is responsible for the default configuration of the installed Linux kernel, general system security, and more generally integration of the different software packages into a coherent whole.
-Community
-~~~~~~~~~
-A distribution is largely driven by its developer and user communities. Some vendors develop and fund their distributions on a volunteer basis. Examples include Debian and the Debian-based, Ubuntu. Others maintain a community version of their commercial distributions, as Red Hat does with Fedora.
-In many cities and regions, local associations known as Linux Users Groups (LUGs) seek to promote their preferred distribution and by extension free software. They hold meetings and provide free demonstrations, training, technical support, and operating system installation to new users. Many Internet communities also provide support to Linux users and developers. Most distributions and free software / open source projects have IRC (Internet Relay Chat) chatrooms or newsgroups. Online forums are another means for support. Linux distributions host mailing lists; commonly there will be a specific topic such as usage or development for a given list. All these can be found simply by running an appropriate search on Google.
-
-Although Linux distributions are generally available without charge, several large corporations sell, support, and contribute to the development of the components of the system and of free software. These include Dell, IBM, HP, Oracle, Sun Microsystems, Novell, Nokia. A number of corporations, notably Red Hat, have built their entire business around Linux distributions.
-
-Can I make a profit out of running a business involving Linux?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The answer is, "Yes!". The free software licenses, on which the various software packages of a distribution built on the Linux kernel are based, explicitly accommodate and encourage commercialization; the relationship between a Linux distribution as a whole and individual vendors may be seen as symbiotic. One common business model of commercial suppliers is charging for support, especially for business users. A number of companies also offer a specialized business version of their distribution, which adds proprietary support packages and tools to administer higher numbers of installations or to simplify administrative tasks. Another business model is to give away the software in order to sell hardware. Examples of corporations that are extensively (and sometimes exclusively) open-source and Linux-powered , with successful revenue generation models involving these, are Google, SUN, Mozilla, etc.
-
-Programming on Linux
-~~~~~~~~~~~~~~~~~~~~
-Most Linux distributions support dozens of programming languages. The most common collection of utilities for building both Linux applications and operating system programs is found within the GNU toolchain, which includes the GNU Compiler Collection (GCC) and the GNU build system. Amongst others, GCC provides compilers for Ada, C, C++, Java, and Fortran. The Linux kernel itself is written to be compiled with GCC. Proprietary compilers for Linux include the Intel C++ Compiler, Sun Studio, and IBM XL C/C++ Compiler.
-
-Most distributions also include support for PHP, Perl, Ruby, Python and other dynamic languages. Examples of languages that are less common, but still supported, are C# via the Mono project, sponsored by Novell, and Scheme. A number of Java Virtual Machines and development kits run on Linux, including the original Sun Microsystems JVM (HotSpot), and IBM's J2SE RE, as well as many open-source projects like Kaffe.
-
-The two main frameworks for developing graphical applications are those of GNOME and KDE. These projects are based on the GTK+ and Qt widget toolkits, respectively, which can also be used independently of the larger framework. Both support a wide variety of languages. There are a number of Integrated Development Environments (IDEs) available including Anjuta, Code::Blocks, Eclipse, KDevelop, Lazarus, MonoDevelop, NetBeans, and Omnis Studio while the long-established editors Vim and Emacs remain popular.
Reasons for Using Linux
-----------------------
@@ -71,7 +24,7 @@
As in "free beer". Linux can be downloaded in its entirety from the Internet completely for free. No registration fees, no costs per user, free updates, and freely available source code in case you want to change the behavior of your system.
Most of all, Linux is free as in "free speech":
-The license commonly used is the GNU Public License (GPL). The license says that anybody who may want to do so, has the right to change Linux and eventually to redistribute a changed version, on the one condition that the code is still available after redistribution. In practice, you are free to grab a kernel image and sell the new code, as long as your customers can still have a copy of that code.
+
- Linux is portable to any hardware platform:
@@ -87,53 +40,21 @@
- Linux is scalable:
-From a Palmtop with 2 MB of memory to a petabyte storage cluster with hundreds of nodes: add or remove the appropriate packages and Linux fits all. One does not need a supercomputer anymore,because you can use Linux to do big things using the building blocks provided with the system. If one wants to do little things, such as making an operating system for an embedded processor or just recycling your old 486, Linux will do that as well.
+From a Palmtop with 2 MB of memory to a petabyte storage cluster with hundreds of nodes: add or remove the appropriate packages and Linux fits all.
-- The Linux OS and Linux applications have very short debug−times:
-Because Linux has been developed and tested by thousands of people, both errors and people to fix them are found very quickly. It often happens that there are only a couple of hours between discovery and fixing of a bug.
Getting Started
================
Logging in, activating the user interface and logging out
----------------------------------------------------------
-In order to work on a Linux system directly, one needs to provide a user name and password. You always need to authenticate to the system. Most PC−based Linux systems have two basic modes for a system to run in: either quick and clean in text console mode,which includes with mouse, multitasking and multi−user features, or in graphical console mode, which looks better but eats more system resources.
-
-Graphical Mode
-~~~~~~~~~~~~~~
-This is the default nowadays on most desktop computers. You know you will be connecting to the system using graphical mode when you are first asked for your user name, and then to type your password.
-
-To log in, make sure the mouse pointer is in the login window, provide your user name and password to the system and click *OK* or press *Enter*.
-It is generally considered a bad idea to connect (graphically) using the root user name, the system adminstrator's account, since the use of graphics includes running a lot of extra programs, in root's case with a lot of extra permissions. To keep all risks as low as possible, use a normal user account to connect graphically. But there are enough risks to keep this in mind as a general advice, for all use of the root account: only log in as root when extra privileges are required.
-
-After entering your user name/password combination, it can take a little while before the graphical environment is started, depending on the CPU speed of your computer, on the software you use and on your personal settings.
+In order to work on a Linux system directly, one needs to provide a user name and password. You always need to authenticate to the system. Most PC−based Linux systems have two basic modes for a system to run in: either quick and clean in text console mode,which includes with mouse, multitasking and multi−user features, or in graphical console mode.
-To continue, you will need to open a *terminal window* or *xterm* for short (X being the name for the underlying software supporting the graphical environment). This program can be found in the *Applications−>Utilities->System Tools* or *Internet menu*, depending on what window manager you are using. There might be icons that you can use as a shortcut to get an *xterm* window as well, and clicking the right mouse button on the desktop background will usually present you with a menu containing a terminal window application.
-While browsing the menus, you will notice that a lot of things can be done without entering commands via the keyboard. For most users, the good old point−n−click method of dealing with the computer will do. But for those who want to enter the "heart" of the system, a tool stronger than a mouse will be required to handle the various tasks. This tool is the shell, and when in graphical mode, we activate our shell by opening a terminal window.
-
-A terminal window should always show a command prompt when you open one. This terminal shows a standard prompt, which displays the user's login name, and the current working directory, represented by the twiddle (~)
-
-Another common form for a prompt is this one:
-[user@host dir]
-
-In the above example, *user* will be your login name, *hosts* the name of the machine you are working on, and *dir* an indication of your current location in the file system. Prompts can display all kinds of information, but they are not part of the commands you are giving to your system. To disconnect from the system in graphical mode, you need to close all terminal windows and other applications. After that, hit the *logout* icon or find *Log Out* in the menu. Closing everything is not really necessary, and the system can do this for you, but session management might put all currently open applications back on your screen when you connect again, which takes longer and is not always the desired effect. However, this behavior is configurable.
When you see the login screen again, asking to enter user name and password, logout was successful.
-Text Mode
-~~~~~~~~~
-One is in text mode when the whole screen is black, showing (in most cases white) characters. A text mode login screen typically shows some information about the machine you are working on, the name of the machine and a prompt waiting for you to log in.
-
-The login is different from a graphical login, in that you have to hit the *Enter* key after providing your user name, because there are no buttons on the screen that you can click with the mouse. Then you should type your password, followed by another *Enter*. You will not see any indication that you are entering something, not even an asterisk, and you won't see the cursor move. But this is normal on Linux and is done for security
-reasons.
-
-When the system has accepted you as a valid user, you may get some more information, called the *message of the day*, which can be anything. Additionally, it is popular on UNIX systems to display a fortune cookie, which contains some general wise or unwise (this is up to you) thoughts. After that, you will be given a shell, indicated with the same prompt that you would get in graphical mode.
-
-Also in text mode: log in as root only to do setup and configuration that absolutely requires administrator privileges, such as adding users, installing software packages, and performing network and other system configuration. Once you are finished, immediately leave the special account and resume your work as a non−privileged user.
-
-Logging out is done by entering the *logout* command, followed by Enter. You are successfully disconnected from the system when you see the login screen again.Don't power−off the computer after logging out. It is not meant to be shut off without application of the proper procedures for halting the system. Powering it off without going through the halting process might cause severe damage!
Basic Commands
===============
@@ -141,55 +62,18 @@
ls
---
-When invoked without any arguments, *ls* lists the files in the current working directory. A directory that is not the current working directory can be specified and ls will list the files there. The user also may specify any list of files and directories. In this case, all files and all contents of specified directories will be listed. The name *ls* is derived from *list segments* which was used in earlier systems.
-
-Files whose names start with "." are not listed, unless the *-a* flag is specified or the files are specified explicitly.
-
-Without options, *ls* displays files in a bare format. This bare format however makes it difficult to establish the type, permissions, and size of the files. The most common options to reveal this information or change the list of files are:
+*ls* lists the files in the current working directory. A directory that is not the current working directory can be specified and ls will list the files there.::
- * *-l* long format, displaying Unix file types, permissions, number of hard links, owner, group, size, date, and filename
- * *-F* appends a character revealing the nature of a file, for example, * for an executable, or / for a directory. Regular files have no suffix.
- * *-a* lists all files in the given directory, including those whose names start with "." (which are hidden files in Unix). By default, these files are excluded from the list.
- * *-R* recursively lists subdirectories. The command ls -R / would therefore list all files.
- * *-d* shows information about a symbolic link or directory, rather than about the link's target or listing the contents of a directory.
- * *-t* sort the list of files by modification time.
- * *-h* print sizes in human readable format. (e.g., 1K, 234M, 2G, etc.)
-
-In some environments, providing the option *--color* (for GNU ls) or *-G* (FreeBSD ls) causes ls to highlight different types of files with different colors, instead of with characters as *-F* would. To determine what color to use for a file, GNU *ls* checks the Unix file type, the file permissions, and the file extension, while FreeBSD *ls* checks only the Unix file type and file permissions.::
$ ls
jeeves.rst psmith.html blandings.html
- $ ls -l
- drwxr--r-- 1 plum editors 4096 jeeves
- -rw-r--r-- 1 plum editors 30405 psmith
- -r-xr-xr-x 1 plum plum 8460 blandings
-
-Here "$" actually is the beginning of the prompt. This is typical in most Unix-based systems.
-
-date
------
-
-The Unix date command displays the time and date. The super-user can use it to set the system clock.
-
-With no options, the date command displays the current date and time, including the abbreviated day name, abbreviated month name, day of the month, the time separated by colons, the timezone name, and the year. For example::
-
- $date
- Tue Sep 8 12:01:45 IST 2009
-
-On some systems to set the current date and time to September 8, 2004 01:22 you type::
-
- $date --set="20040908 01:22"
-
-In order to view the various options for the *date* command, type::
-
- $man date
-
-This will take you to the "Manual" page comprising of all the details on the *date* command. You can return to the terminal from the "man" page by pressing the *Esc* key in the keyboard and typing ":q" in that order.
cd
---
-This stands for "change directory". When one wants to go up to the parent directory, bypassing the tree of directories one has entered, “ cd ..” can be used.
+This stands for "change directory". When one wants to change the directory .
+
+ $cd Music
One dot '.' represents the current directory while two dots '..' represent the parent directory.
@@ -233,11 +117,7 @@
The command can be invoked with the arguments *am i* or *am I* (so it is invoked as *who am i* or * who am I*), showing information about the current terminal only (see the *-m* option below, of which this invocation is equivalent).
-In order to find out the various options that can be appended to the *who* command, check the *man* page by typing out the following in the terminal::
- $man who
-
-This will take you to the "Manual" page containing details about the *who* command
mkdir
-----
@@ -248,36 +128,35 @@
Where *name_of_directory* is the name of the directory one wants to create. When typed as above (ie. normal usage), the new directory would be created within the current directory. On Unix, multiple directories can be specified, and *mkdir* will try to create all of them.
-Options
-~~~~~~~
+
+
-On Unix-like operating systems, *mkdir* takes options. Three of the most common options are:
+pwd
+----
+pwd is a Linux / Unix command which prints the current working directory. If you wish to know the full path of the directory in which you are in from the Linux console, then the pwd command will come to your rescue. pwd stands for Print Working Directory.
- * *-p*: will also create all directories leading up to the given directory that do not exist already. If the given directory already exists, ignore the error.
- * *-v*: display each directory that mkdir creates. Most often used with -p.
- * *-m*: specify the octal permissions of directories created by mkdir.
+pwd have one option called -P, which lists the current working directory with all the links resolved.
+
+Usage of pwd command
-*-p* is most often used when using mkdir to build up complex directory hierarchies, in case a necessary directory is missing or already there. -m is commonly used to lock down temporary directories used by shell scripts.
+I have a directory called "Examples/" on my machine which is actually a soft link to the directory /usr/share/example-content/.
-Examples
-~~~~~~~~
+I move into the "Examples" directory and run the pwd command to get the following output.
-An example of *-p* in action is::
-
- $mkdir -p /tmp/a/b/c
+$ cd Examples
+$ pwd
+/home/laf/Examples
-If */tmp/a* exists but */tmp/a/b* does not, mkdir will create */tmp/a/b* before creating */tmp/a/b/c*.
-
-And an even more powerful command, creating a full tree at once (this however is a Shell extension, nothing mkdir does itself)::
- $mkdir -p tmpdir/{trunk/sources/{includes,docs},branches,tags}
-
-This will create:
+FLAGS
+~~~~~
+The standard commands in Linux have a lot of options also called flags to change or provide some additional functionality to the command For example ::
+
+ $ls -l
+
+ * *ls with flag -l* displays the result in long format, displaying Unix file types, permissions, number of hard links, owner, group, size, date, and filename
-tmpdir - branches
- - tag
- - trunk - sources - includes
- - docs
+
Getting Help
============
@@ -333,43 +212,12 @@
at a shell prompt; for example, "man ftp". In order to simplify navigation through the output, *man* generally uses the less terminal pager.
-Pages are traditionally referred to using the notation "name(section)"; for example, ftp(1). The same page name may appear in more than one section of the manual, this can occur when the names of system calls, user commands, or macro packages coincide. Two examples are *man(1)* and *man(7)*, or *exit(2)* and *exit(3)*. The syntax for accessing the non-default manual section varies between different man implementations. On Linux and *BSD, for example, the syntax for reading *printf(3)* is::
-
- $man 3 printf
-
-Another example::
+To see the manual on man itself do::
$man man
The previous example will take you to the "Manual" page entry about manual pages!
-Layout
-~~~~~~
-
-All man pages follow a common layout that is optimized for presentation on a simple ASCII text display, possibly without any form of highlighting or font control. Sections present may include:
-
-NAME
- The name of the command or function, followed by a one-line description of what it does.
-SYNOPSIS
- In the case of a command, you get a formal description of how to run it and what command line options it takes. For program functions, a list of the parameters the function takes and which header file contains its definition. For experienced users, this may be all the documentation they need.
-DESCRIPTION
- A textual description of the functioning of the command or function.
-EXAMPLES
- Some examples of common usage.
-SEE ALSO
- A list of related commands or functions.
-
-Other sections may be present, but these are not well standardized across man pages. Common examples include: OPTIONS, EXIT STATUS, ENVIRONMENT, KNOWN BUGS, FILES, AUTHOR, REPORTING BUGS, HISTORY and COPYRIGHT.
-
-These days virtually every Unix command line application comes with its man page, and many Unix users perceive a lack of man pages as a sign of low quality; indeed, some projects, such as Debian, go out of their way to write man pages for programs lacking one. Few alternatives to *man* have enjoyed much popularity, with the possible exception of the GNU project's "info" system, an early and simple hypertext system.
-
-However, the format of a single page for each application, the lack of classification within the sections and the relatively unsophisticated formatting facilities have motivated the development of alternative documentation systems, such as the previously mentioned "info" system.
-
-Most Unix GUI applications (particularly those built using the GNOME and KDE development environments) now provide end-user documentation in HTML and include embedded HTML viewers such as yelp for reading the help within the application.
-
-Usually the man pages are written in English. Translations into other languages can be also available on the system.
-
-The default format of the man pages is troff, with either the macro package man (appearance oriented) or on some systems mdoc (semantic oriented). This makes it possible to typeset a man page to PostScript, PDF and various other formats for viewing or printing.
info
-----
@@ -421,6 +269,7 @@
Report bugs to <bug-coreutils@gnu.org>.
+
Basic file handling
===================
@@ -434,21 +283,19 @@
To copy a file to another file::
- $ cp [ -f ] [ -H ] [ -i ] [ -p ][ -- ] SourceFile TargetFile
+ $ cp SourceFile TargetFile
To copy a file to a directory::
- $ cp [ -f ] [ -H ] [ -i ] [ -p ] [ -r | -R ] [ -- ] SourceFile ... TargetDirectory
-
+ $ cp SourceFile TargetDirectory
+
To copy a directory to a directory::
- $ cp [ -f ] [ -H ] [ -i ] [ -p ] [ -- ] { -r | -R }
- SourceDirectory ... TargetDirectory
+ $ cp -r SourceDirectory TargetDirectory
Flags
~~~~~
-*-f* (force) – specifies removal of the target file if it cannot be opened for write operations. The removal precedes any copying performed by the cp command.
*-P* – makes the cp command copy symbolic links. The default is to follow symbolic links, that is, to copy files to which symbolic links point.
@@ -527,7 +374,6 @@
::
$ mv myfile mynewfilename renames a file
- $ mv myfile otherfilename renames a file and deletes the existing file "myfile"
$ mv myfile /myfile moves 'myfile' from the current directory to the root directory
$ mv myfile dir/myfile moves 'myfile' to 'dir/myfile' relative to the current directory
$ mv myfile dir same as the previous command (the filename is implied to be the same)
@@ -572,32 +418,15 @@
Permissions
~~~~~~~~~~~
+Linux is a proper multi-user environment. In a multi-user environment, security of user and system data is very important. Access should be given only to users who need to access the data. Since Linux is essentially a server OS, good and efficient file security is built right . The permissions are based on whether one is allowed to read, write or execute a file.
Usually, on most filesystems, deleting a file requires write permission on the parent directory (and execute permission, in order to enter the directory in the first place). (Note that, confusingly for beginners, permissions on the file itself are irrelevant. However, GNU rm asks for confirmation if a write-protected file is to be deleted, unless the -f option is used.)
-To delete a directory (with rm -r), one must delete all of its contents recursively. This requires that one must have read and write and execute permission to that directory (if it's not empty) and all non-empty subdirectories recursively (if there are any). The read permissions are needed to list the contents of the directory in order to delete them. This sometimes leads to an odd situation where a non-empty directory cannot be deleted because one doesn't have write permission to it and so cannot delete its contents; but if the same directory were empty, one would be able to delete it.
-
-If a file resides in a directory with the sticky bit set, then deleting the file requires one to be the owner of the file.
+To delete a directory (with rm -r), one must delete all of its contents recursively. This requires that one must have read and write and execute permission to that directory (if it's not empty) and all non-empty subdirectories recursively (if there are any).
-Command Line Arguments
-=======================
-
-In computer command line interfaces, a command line argument is an argument sent to a program being called. In general, a program can take any number of command line arguments, which may be necessary for the program to run, or may even be ignored, depending on the function of that program.
-
-For example, in Unix and Unix-like environments, an example of a command-line argument is::
-
- rm file.s
-"file.s" is a command line argument which tells the program rm to remove the file "file.s".
-Programming languages such as C, C++ and Java allow a program to interpret the command line arguments by handling them as string parameters in the main function.
-
-A command line option or simply *option* (also known as a command line parameter, flag, or a switch) is an indication by a user that a computer program should change its default output.
-
-Long options are introduced via "--", and are typically whole words. For example, *ls --long --classify --all*. Arguments to long options are provided with "=", as *ls --block-size=1024*. Some Unix programs use long options with single dashes, for example MPlayer as in *mplayer -nosound*.
-
-Linux also uses "--" to terminate option lists. For example, an attempt to delete a file called *-file1* by using *rm -file1* may produce an error, since rm may interpret *-file1* as a command line switch. Using *rm -- -file1* removes ambiguity.
Basic Text Processing
======================
@@ -617,7 +446,7 @@
$ head -n 5 foo*
-Some versions omit the n and just let you say -5.
+
Flags
~~~~~
@@ -625,14 +454,6 @@
-c <x number of bytes> Copy first x number of bytes.
-Other options: *sed*
-
-Many early versions of Unix did not have this command, and so documentation and books had *sed* do this job::
-
- sed 5q foo
-
-This says to print every line (implicit), and quit after the fifth.
-
tail
----
@@ -655,12 +476,7 @@
$ tail -n +2 filename
-Using an older syntax (still used in Sun Solaris as the -n option is not supported), the last 20 lines and the last 50 bytes of filename can be shown with the following command::
- $ tail -20 filename
- $ tail -50c filename
-
-However this syntax is now obsolete and does not conform with the POSIX 1003.1-2001 standard. Even if still supported in current versions, when used with other options (like -f, see below), these switches could not work at all.
File monitoring
~~~~~~~~~~~~~~~
@@ -728,7 +544,7 @@
| Jeeves | London | March 19 |
+-----------+------------+------------+
-This creates the file named *www* containing::
+This creates the file named *www* containing ::
Batman GothamCity January 3
Trillian Andromeda February 4
@@ -743,7 +559,6 @@
\ / < > ! $ % ^ & * | { } [ ] " ' ` ~ ;
-Different shells may differ in the meta characters recognized.
As an example,
::
@@ -760,17 +575,7 @@
because the c* matches that long file name.
-Filenames containing metacharacters can pose many problems and should never be intentionally created. If you do find that you've created a file with metacharacters, and you would like to remove it, you have three options. You may use wildcards to match metacharacter, use the \ to directly enter the filename, or put the command in double quotes (except in the case of double quotes within the file name, these must be captured with one of the first two methods). For example, deleting a file named `"``*`|more`"` can be accomplished with::
-
- $ rm ??more
-
-or::
-
- $ rm $\backslash$*$\backslash$|more
-
-or::
-
- $ rm ''*|more''
+Filenames containing metacharacters can pose many problems and should never be intentionally created.
Looking At Files
@@ -785,57 +590,13 @@
If the filename is specified as -, then *cat* will read from standard input at that point in the sequence. If no files are specified, *cat* will read from standard input entered.
-Jargon File Definition
-~~~~~~~~~~~~~~~~~~~~~~
-
-The Jargon File version 4.4.7 lists this as the definition of *cat*::
-
- 1. To spew an entire file to the screen or some other output sink without
- pause (syn. blast).
-
- 2. By extension, to dump large amounts of data at an unprepared target or
- with no intention of browsing it carefully. Usage: considered silly.
- Rare outside Unix sites. See also dd, BLT.
-
- Among Unix fans, *cat(1)* is considered an excellent example of
- user-interface design, because it delivers the file contents without
- such verbosity as spacing or headers between the files, and because
- it does not require the files to consist of lines of text, but works
- with any sort of data.
-
- Among Unix critics, *cat(1)* is considered the canonical example of
- bad user-interface design, because of its woefully unobvious name.
- It is far more often used to blast a single file to standard output
- than to concatenate two or more files. The name cat for the former
- operation is just as unintuitive as, say, LISP's cdr.
-
- Of such oppositions are holy wars made...
+Usage ::
+ $ cat foo boo
+ This is file foo
+
+ This is file boo.
-Useless Use of 'cat'
-~~~~~~~~~~~~~~~~~~~~
-UUOC (from comp.unix.shell on Usenet) stands for “Useless Use of cat”. As it is observed on *comp.unix.shell*, “The purpose of cat is to concatenate (or 'catenate') files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.”
-
-Nevertheless one sees people doing::
-
- $ cat file | some_command and its args ...
-
-instead of the equivalent and cheaper::
-
- <file some_command and its args ...
-
-or (equivalently and more classically)::
-
- some_command and its args ... <file
-
-Since 1995, occasional awards for UUOC have been given out. The activity of fixing instances of UUOC is sometimes called 'demoggification'.
-
-Amongst many, it is still considered safer to use *cat* for such cases given that the < and > keys are next to each other in many popular keyboard mappings. While the risk might be low, the impact of using > instead of < can be high and prohibitive.
-
-zcat
-~~~~~
-
-*zcat* is a Unix program similar to *cat*, that decompresses individual files and concatenates them to standard output. Traditionally *zcat* operated on files compressed by compress but today it is usually able to operate on *gzip* or even *bzip2* archives. On such systems, it is equivalent to *gunzip -c*
more
-----
@@ -855,7 +616,7 @@
There are also other commands that can be used while navigating through the document; consult *more*'s *man* page for more details.
-*Options* are typically entered before the file name, but can also be entered in the environment variable *$MORE*. Options entered in the actual command line will override those entered in the *$MORE* environment variable. Available options may vary between Unix systems.
+
less
-----
@@ -869,7 +630,7 @@
By default, *less* displays the contents of the file to the standard output (one screen at a time). If the file name argument is omitted, it displays the contents from standard input (usually the output of another command through a pipe). If the output is redirected to anything other than a terminal, for example a pipe to another command, less behaves like cat.
-The command-syntax is::
+The command-syntax is ::
$ less [options] file_name
@@ -915,6 +676,10 @@
* q: Quit.
+
+
+-------------------------------------------------------------------
+
Examples
~~~~~~~~~
::
@@ -929,7 +694,7 @@
In the File Hierarchy Standard (FHS) all files and directories appear under the root directory "/", even if they are stored on different physical devices. Note however that some of these directories may or may not be present on a Unix system depending on whether certain subsystems, such as the X Window System, are installed.
-The majority of these directories exist in all UNIX operating systems and are generally used in much the same way; however, the descriptions here are those used specifically for the FHS, and are not considered authoritative for platforms other than Linux.
+The majority of these directories exist in all UNIX operating systems and are generally used in much the same way; however, the descriptions here are those used specifically for the FHS, and are not considered authoritative for platforms other thanmajor Linux distros.
+---------------+------------------------------------------------+
| Directory | Description |
@@ -1010,10 +775,40 @@
Permissions and Ownership
=========================
+let's check out the file permissions. File permissions are defined
+for users, groups and others. User would be the username that you are
+logging in as. Further more, users can be organized into groups for better
+administration and control. Each user will belong to at least one default
+group. Others includes anyone the above categories exclude.
+
+Given below is the result of an 'ls -l'
+
+drwxr-x--- 2 user group 4096 Dec 28 04:09 tmp
+-rw-r--r-- 1 user group 969 Dec 21 02:32 foo
+-rwxr-xr-x 1 user group 345 Sep 1 04:12 somefile
+
+Relevant information in the first column here is the file type followed by the file permissions. The third and the fourth column show the owner of the file and the group that the file belongs to.The fifth column is no bytes and sixth modification date .The first entry here is tmp. The first character in the first column is 'd', which means the tmp is a directory. The other entries here are files,as indicated by the '-'.
+
+d rwx r-x ---
+file type users group others
+
+The next 9 characters define the file permissions. These permissions are given in groups of 3 each. The first 3 characters are the permissions for the owner of the file or directory. The next 3 are permissions for the group that the file is owned by and the final 3 characters define the access permissions for everyone not part of the group. There are 3 possible attributes that make up file access permissions.
+
+r - Read permission. Whether the file may be read. In the case of a directory, this would mean the ability to list the contents of the directory.
+
+w - Write permission. Whether the file may be written to or modified. For a directory, this defines whether you can make any changes to the contents
+of the directory. If write permission is not set then you will not be able
+to delete, rename or create a file.
+
+x - Execute permission. Whether the file may be executed. In the case of a directory, this attribute decides whether you have permission to enter,run a search through that directory or execute some program from that directory.
+
+
+
+
chmod
------
-The *chmod* command (abbreviated from 'change mode') is a shell command and C language function in Unix and Unix-like environments. When executed, it can change file system modes of files and directories. The modes include permissions and special modes.A chmod command first appeared in AT&T Unix version 1, and is still used today on Unix-like machines.
+The *chmod* command (abbreviated from 'change mode') is a shell command and C language function in Unix and Unix-like environments. When executed, it can change file system modes of files and directories. The modes include permissions and special modes.
Usage
~~~~~
@@ -1160,24 +955,44 @@
$ ls -l myfile
-rw-rw-r-- 1 57 Jul 3 10:13 myfile
+Foe each one, you define the right like that :
+
+ * a read right correspond to 4
+ * a write right correspond to 2
+ * an execute right correspond to 1
+
+You want the user to have all the rights? : 4 + 2 + 1 = 7
+
+you want the group to have read and write rights : 4 + 2 = 6
+
+
+
Since the *setuid*, *setgid* and *sticky* bits are not set, this is equivalent to:
::
$ chmod 0664 myfile
-Special modes
-+++++++++++++
+
+chown
+~~~~~
+The chown command is used to change the owner and group of files, directories and links.
+
+By default, the owner of a filesystem object is the user that created it. The group is a set of users that share the same access permissions (i.e., read, write and execute) for that object.
-The *chmod* command is also capable of changing the additional permissions or special modes of a file or directory. The symbolic modes use **s** to represent the *setuid* and *setgid* modes, and **t** to represent the sticky mode. The modes are only applied to the appropriate classes, regardless of whether or not other classes are specified.
+The basic syntax for using chown to change owners is
+
+ chown -v alice wonderland.txt
-Most operating systems support the specification of special modes using octal modes, but some do not. On these systems, only the symbolic modes can be used.
+
+
+
Redirection and Piping
=======================
In computing, *redirection* is a function common to most command-line interpreters, including the various Unix shells that can redirect standard streams to user-specified locations.
-Programs do redirection with the *dup2(2)* system call, or its less-flexible but higher-level stdio analogues, *freopen(3)* and *popen(3)*.
+
Redirecting standard input and standard output
-----------------------------------------------
@@ -1200,7 +1015,7 @@
-------
Programs can be run together such that one program reads the output from another with no need for an explicit intermediate file:
-A pipeline of three programs run on a text terminal::
+A pipeline of two programs run on a text terminal::
$ command1 | command2
@@ -1240,7 +1055,7 @@
executes *command1*, directing the standard error stream to *file1*.
-In shells derived from *csh* (the C shell), the syntax instead appends the & character to the redirect characters, thus achieving a similar result.
+
Another useful capability is to redirect one standard file handle to another. The most popular variation is to merge standard error into standard output so error messages can be processed together with (or alternately to) the usual output. Example:
::
@@ -1332,47 +1147,6 @@
Other commands contain the word 'grep' to indicate that they search (usually for regular expression matches). The *pgrep* utility, for instance, displays the processes whose names match a given regular expression.
-tr
---
-
-*tr* (abbreviated from *translate* or *transliterate*) is a command in Unix-like operating systems.
-
-When executed, the program reads from the standard input and writes to the standard output. It takes as parameters two sets of characters, and replaces occurrences of the characters in the first set with the corresponding elements from the other set. For example,
-::
-
- $ tr 'abcd' 'jkmn'
-
-maps 'a' to 'j', 'b' to 'k', 'c' to 'm', and 'd' to 'n'.
-
-Sets of characters may be abbreviated by using character ranges. The previous example could be written:
-::
-
- $ tr 'a-d' 'jkmn'
-
-In POSIX compliant versions of *tr* the set represented by a character range depends on the locale's collating order, so it is safer to avoid character ranges in scripts that might be executed in a locale different from that in which they were written. Ranges can often be replaced with POSIX character sets such as [:alpha:].
-
-The *-c* flag complements the first set of characters.
-::
-
- $ tr -cd '[:alnum:]'
-
-therefore removes all non-alphanumeric characters.
-
-The *-s* flag causes tr to compress sequences of identical adjacent characters in its output to a single token. For example,
-::
-
- $ tr -s '\n' '\n'
-
-replaces sequences of one or more newline characters with a single newline.
-
-The *-d* flag causes tr to delete all tokens of the specified set of characters from its input. In this case, only a single character set argument is used. The following command removes carriage return characters, thereby converting a file in DOS/Windows format to one in Unix format.
-::
-
- $ tr -d '\r'
-
-Most versions of *tr*, including GNU *tr* and classic Unix *tr*, operate on single byte characters and are not Unicode compliant. An exception is the Heirloom Toolchest implementation, which provides basic Unicode support.
-
-Ruby and Perl also have an internal *tr* operator, which operates analogously. Tcl's *string map* command is more general in that it maps strings to strings while *tr* maps characters to characters.
Elementary Regex
=================
@@ -1381,61 +1155,37 @@
Regular expressions are used by many text editors, utilities, and programming languages to search and manipulate text based on patterns. For example, Perl, Ruby and Tcl have a powerful regular expression engine built directly into their syntax. Several utilities provided by Unix distributions—including the editor *ed* and the filter *grep* — were the first to popularize the concept of regular expressions.
-Traditional Unix regular expression syntax followed common conventions but often differed from tool to tool. The IEEE POSIX *Basic Regular Expressions* (BRE) standard (released alongside an alternative flavor called Extended Regular Expressions or ERE) was designed mostly for backward compatibility with the traditional (Simple Regular Expression) syntax but provided a common standard which has since been adopted as the default syntax of many Unix regular expression tools, though there is often some variation or additional features. Many such tools also provide support for ERE syntax with command line arguments.
+
+Regular Expressions are a feature of UNIX. They describe a pattern to match, a sequence of characters, not words, within a line of text. Here is a quick summary of the special characters used in the grep tool and their meaning:
-In the BRE syntax, most characters are treated as literals — they match only themselves (i.e., a matches "a"). The exceptions, listed below, are called metacharacters or metasequences.
+* ^ (Caret) = match expression at the start of a line, as in ^A.
+* $ (Question) = match expression at the end of a line, as in A$.
+* \ (Back Slash) = turn off the special meaning of the next character, as in \^.
+* [ ] (Brackets) = match any one of the enclosed characters, as in [aeiou].
+ Use Hyphen "-" for a range, as in [0-9].
+* [^ ] = match any one character except those enclosed in [ ], as in [^0-9].
+* . (Period) = match a single character of any value, except end of line.
+* * (Asterisk) = match zero or more of the preceding character or expression.
+* \{x,y\} = match x to y occurrences of the preceding.
+* \{x\} = match exactly x occurrences of the preceding.
+* \{x,\} = match x or more occurrences of the preceding.
+
-+-------------+------------------------------------------------------------+
-|Metacharacter| Description |
-+=============+============================================================+
-| . | Matches any single character (many applications exclude |
-| | newlines, and exactly which characters are considered |
-| | newlines is flavor, character encoding, and platform |
-| | specific, but it is safe to assume that the line feed |
-| | character is included). Within POSIX bracket expressions, |
-| | the dot character matches a literal dot. For example, a.c |
-| | matches abc, etc., but [a.c] matches only a, ., or |
-| | c. |
-+-------------+------------------------------------------------------------+
-| [ ] | A bracket expression. Matches a single character that is |
-| | contained within the brackets. For example, [abc] matches |
-| | a, b, or c. [a-z] specifies a range which matches any |
-| | lowercase letter from a to z. These forms can be mixed: |
-| | [abcx-z] matches a, b, c, x, y, or z, as does |
-| | [a-cx-z]. The - character is treated as a literal character|
-| | if it is the last or the first character within the |
-| | brackets, or if it is escaped with a backslash: [abc-], |
-| | [-abc], or [a\-bc]. |
-+-------------+------------------------------------------------------------+
-| [^ ] | Matches a single character that is not contained within the|
-| | brackets. For example, [^abc] matches any character other |
-| | than a, b, or c. [^a-z] matches any single character |
-| | that is not a lowercase letter from a to z. As above, |
-| | literal characters and ranges can be mixed. |
-+-------------+------------------------------------------------------------+
-| ^ | Matches the starting position within the string. In |
-| | line-based tools, it matches the starting position of any |
-| | line. |
-+-------------+------------------------------------------------------------+
-| $ | Matches the ending position of the string or the position |
-| | just before a string-ending newline. In line-based tools, |
-| | it matches the ending position of any line. |
-+-------------+------------------------------------------------------------+
-| `*` | Matches the preceding element zero or more times. For |
-| | example, ab*c matches "ac", "abc", "abbbc", etc. [xyz]* |
-| | matches "", "x", "y", "z", "zx", "zyx", "xyzzy", and so on.|
-| | \(ab\)* matches "", "ab", "abab", "ababab", and so on. |
-+-------------+------------------------------------------------------------+
-| ? | Matches the preceding element zero or one time. For |
-| | example, ba? matches "b" or "ba". |
-+-------------+------------------------------------------------------------+
-| `+` | Matches the preceding element one or more times. For |
-| | example, ba+ matches "ba", "baa", "baaa", and so on. |
-+-------------+------------------------------------------------------------+
-| `|` | The choice (aka alternation or set union) operator matches |
-| | either the expression before or the expression after the |
-| | operator. For example, abc|def matches "abc" or "def". |
-+-------------+------------------------------------------------------------+
+
+Here are some examples using grep:
+
+* grep smug files {search files for lines with 'smug'}
+* grep '^smug' files {'smug' at the start of a line}
+* grep 'smug$' files {'smug' at the end of a line}
+* grep '^smug$' files {lines containing only 'smug'}
+* grep '\^s' files {lines starting with '^s', "\" escapes the ^}
+* grep '[Ss]mug' files {search for 'Smug' or 'smug'}
+* grep 'B[oO][bB]' files {search for BOB, Bob, BOb or BoB }
+* grep '^$' files {search for blank lines}
+* grep '[0-9][0-9]' file {search for pairs of numeric digits}
+
+
+
Lazy quantification
--------------------
@@ -1465,49 +1215,15 @@
The use of the phrase one-liner has been widened to also include program-source for any language that does something useful in one line.
-The word *One-liner* has two references in the index of the book *The AWK Programming Language* (the book is often referred to by the abbreviation TAPL). It explains the programming language AWK, which is part of the Unix operating system. The authors explain the birth of the One-liner paradigm with their daily work on early Unix machines:
-::
- “The 1977 version had only a few built-in variables and predefined functions. It was designed for writing short programs [...] Our model was that an invocation would be one or two lines long, typed in and used immediately. Defaults were chosen to match this style [...] We, being the authors, knew how the language was supposed to be used, and so we only wrote one-liners.”
-
-Notice that this original definition of a One-liner implies immediate execution of the program without any compilation. So, in a strict sense, only source code for interpreted languages qualifies as a One-liner. But this strict understanding of a One-liner was broadened in 1985 when the IOCCC introduced the category of Best One Liner for C, which is a compiled language.
-
-The TAPL book contains 20 examples of One-liners (A Handful of Useful awk One-Liners) at the end of the book's first chapter.
-
-Here are the first few of them:
-
- 1. Print the total number of input lines:
-
- END { print NR }
-
- 2. Print the tenth input line:
-
- NR == 10
-
- 3. Print the last field of every input line:
-
- { print $NF }
-
-One-liners are also used to show off the differential expressive power of programming languages. Frequently, one-liners are used to demonstrate programming ability. Contests are often held to see who can create the most exceptional one-liner.
-
-The following example is a C program (a winning entry in the "Best one-liner" category of the IOCCC, here split to two lines for presentation).::
-
- main(int c,char**v){return!m(v[1],v[2]);}m(char*s,char*t){return
- *t-42?*s?63==*t|*s==*t&&m(s+1,t+1):!*t:m(s,t+1)||*s&&m(s+1,t);}
-
-This one-liner program is a *glob pattern matcher*. It understands the glob characters '*' meaning 'zero or more characters' and '?' meaning exactly one character, just like most Unix shells.
-
-Run it with two args, the string and the glob pattern. The exit status is 0 (shell true) when the pattern matches, 1 otherwise. The glob pattern must match the whole string, so you may want to use * at the beginning and end of the pattern if you are looking for something in the middle. Examples::
-
- $ prog foo 'f??'; echo $?
-
- $ prog 'best short program' '??st*o**p?*'; echo $?
Here is a one line shell script to show directories:
::
- $ ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/ /' -e 's/-/|/'
+ $grep user * | cut -d":" -f1|uniq
+
+This returns list of all files which has the word user in it .
--- a/ult/session4.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/ult/session4.rst Tue Aug 31 19:10:09 2010 +0530
@@ -226,282 +226,3 @@
$ grep "[A-Za-z]*" -o alice-in-wonderland.txt | tr 'A-Z' 'a-z' | sort | uniq -c | sort -nr
-Basic editing and editors
-=========================
-
-vim
----
-Vim is a very powerful editor. It has a lot of commands, and all of them cannot be explained here. We shall try and look at a few, so that you can find your way around in vim.
-
-To open a file in vim, we pass the filename as a parameter to the ``vim`` command. If a file with that filename does not exist, a new file is created.
-::
-
- $ vim first.txt
-
-To start inserting text into the new file that we have opened, we need to press the ``i`` key. This will take us into the *insert* mode from the *command* mode. Hitting the ``esc`` key, will bring us back to the *command* mode. There is also another mode of vim, called the *visual* mode which will be discussed later in the course.
-
-In general, it is good to spend as little time as possible in the insert mode and extensively use the command mode to achieve various tasks.
-
-To save the file, use ``:w`` in the command mode. From here on, it is understood that we are in the command mode, whenever we are issuing any command to vim.
-
-To save a file and continue editing, use ``:w FILENAME``
-The file name is optional. If you do not specify a filename, it is saved in the same file that you opened. If a file name different from the one you opened is specified, the text is saved with the new name, but you continue editing the file that you opened. The next time you save it without specifying a name, it gets saved with the name of the file that you initially opened.
-
-To save file with a new name and continue editing the new file, use ``:saveas FILENAME``
-
-To save and quit, use ``:wq``
-
-To quit, use ``:q``
-
-To quit without saving, use ``:q!``
-
-Moving around
-~~~~~~~~~~~~~
-
-While you are typing in a file, it is in-convenient to keep moving your fingers from the standard position for typing to the arrow keys. Vim, therefore, provides alternate keys for moving in the document. Note again that, you should be in the command mode, when issuing any commands to vim.
-
-The basic cursor movement can be achieved using the keys, ``h`` (left), ``l`` (right), ``k`` (up) and ``j`` (down).
-::
-
- ^
- k
- < h l >
- j
- v
-
-Note: Most commands can be prefixed with a number, to repeat the command. For instance, ``10j`` will move the cursor down 10 lines.
-
-Moving within a line
-++++++++++++++++++++
-
-+----------------------------------------+---------+
-| Cursor Movement | Command |
-+========================================+=========+
-| Beginning of line | ``0`` |
-+----------------------------------------+---------+
-| First non-space character of line | ``^`` |
-+----------------------------------------+---------+
-| End of line | ``$`` |
-+----------------------------------------+---------+
-| Last non-space character of line | ``g_`` |
-+----------------------------------------+---------+
-
-Moving by words and sentences
-+++++++++++++++++++++++++++++
-+------------------------------+---------+
-| Cursor Movement | Command |
-+==============================+=========+
-| Forward, word beginning | ``w`` |
-+------------------------------+---------+
-| Backward, word beginning | ``b`` |
-+------------------------------+---------+
-| Forward, word end | ``e`` |
-+------------------------------+---------+
-| Backward, word end | ``ge`` |
-+------------------------------+---------+
-| Forward, sentence beginning | ``)`` |
-+------------------------------+---------+
-| Backward, sentence beginning | ``(`` |
-+------------------------------+---------+
-| Forward, paragraph beginning | ``}`` |
-+------------------------------+---------+
-| Backward, paragraph beginning| ``{`` |
-+------------------------------+---------+
-
-More movement commands
-++++++++++++++++++++++
-+---------------------------------+------------+
-| Cursor Movement | Command |
-+=================================+============+
-| Forward by a screenful of text | ``C-f`` |
-+---------------------------------+------------+
-| Backward by a screenful of text | ``C-b`` |
-+---------------------------------+------------+
-| Beginning of the screen | ``H`` |
-+---------------------------------+------------+
-| Middle of the screen | ``M`` |
-+---------------------------------+------------+
-| End of the screen | ``L`` |
-+---------------------------------+------------+
-| End of file | ``G`` |
-+---------------------------------+------------+
-| Line number ``num`` | ``[num]G`` |
-+---------------------------------+------------+
-| Beginning of file | ``gg`` |
-+---------------------------------+------------+
-| Next occurrence of the text | ``*`` |
-| under the cursor | |
-+---------------------------------+------------+
-| Previous occurrence of the text | ``#`` |
-| under the cursor | |
-+---------------------------------+------------+
-
-Note: ``C-x`` is ``Ctrl`` + ``x``
-
-The visual mode
-~~~~~~~~~~~~~~~
-The visual mode is a special mode that is not present in the original vi editor. It allows us to highlight text and perform actions on it. All the movement commands that have been discussed till now work in the visual mode also. The editing commands that will be discussed in the future work on the visual blocks selected, too.
-
-Editing commands
-~~~~~~~~~~~~~~~~
-
-The editing commands usually take the movements as arguments. A movement is equivalent to a selection in the visual mode. The cursor is assumed to have moved over the text in between the initial and the final points of the movement. The motion or the visual block that's been highlighted can be passed as arguments to the editing commands.
-
-+-------------------------+---------+
-| Editing effect | Command |
-+=========================+=========+
-| Cutting text | ``d`` |
-+-------------------------+---------+
-| Copying/Yanking text | ``y`` |
-+-------------------------+---------+
-| Pasting copied/cut text | ``p`` |
-+-------------------------+---------+
-
-The cut and copy commands take the motions or visual blocks as arguments and act on them. For instance, if you wish to delete the text from the current text position to the beginning of the next word, type ``dw``. If you wish to copy the text from the current position to the end of this sentence, type ``y)``.
-
-Apart from the above commands, that take any motion or visual block as an argument, there are additional special commands.
-
-+----------------------------------------+---------+
-| Editing effect | Command |
-+========================================+=========+
-| Cut the character under the cursor | ``x`` |
-+----------------------------------------+---------+
-| Replace the character under the | ``ra`` |
-| cursor with ``a`` | |
-+----------------------------------------+---------+
-| Cut an entire line | ``dd`` |
-+----------------------------------------+---------+
-| Copy/yank an entire line | ``yy`` |
-+----------------------------------------+---------+
-
-Note: You can prefix numbers to any of the commands, to repeat them.
-
-Undo and Redo
-~~~~~~~~~~~~~
-You can undo almost anything using ``u``.
-
-To undo the undo command type ``C-r``
-
-Searching and Replacing
-~~~~~~~~~~~~~~~~~~~~~~~
-
-+-----------------------------------------+---------+
-| Finding | Command |
-+=========================================+=========+
-| Next occurrence of ``text``, forward |``\text``|
-+-----------------------------------------+---------+
-| Next occurrence of ``text``, backward |``?text``|
-+-----------------------------------------+---------+
-| Search again in the same direction | ``n`` |
-+-----------------------------------------+---------+
-| Search again in the opposite direction | ``N`` |
-+-----------------------------------------+---------+
-| Next occurrence of ``x`` in the line | ``fx`` |
-+-----------------------------------------+---------+
-| Previous occurrence of ``x`` in the line| ``Fx`` |
-+-----------------------------------------+---------+
-
-+---------------------------------------+------------------+
-| Finding and Replacing | Command |
-+=======================================+==================+
-| Replace the first instance of ``old`` |``:s/old/new`` |
-| with ``new`` in the current line. | |
-+---------------------------------------+------------------+
-| Replace all instances of ``old`` |``:s/old/new/g`` |
-| with ``new`` in the current line. | |
-+---------------------------------------+------------------+
-| Replace all instances of ``old`` |``:s/old/new/gc`` |
-| with ``new`` in the current line, | |
-| but ask for confirmation each time. | |
-+---------------------------------------+------------------+
-| Replace the first instance of ``old`` |``:%s/old/new`` |
-| with ``new`` in the entire file. | |
-+---------------------------------------+------------------+
-| Replace all instances of ``old`` |``:%s/old/new/g`` |
-| with ``new`` in the entire file. | |
-+---------------------------------------+------------------+
-| Replace all instances of ``old`` with |``:%s/old/new/gc``|
-| ``new`` in the entire file but ask | |
-| for confirmation each time. | |
-+---------------------------------------+------------------+
-
-SciTE
------
-
-SciTE is a *source code* editor, that has a feel similar to the commonly used GUI text editors. It has a wide range of features that are extremely useful for a programmer, editing code. Also it aims to keep configuration simple, and the user needs to edit a text file to configure SciTE to his/her liking.
-
-Opening, Saving, Editing files with SciTE is extremely simple and trivial. Knowledge of using a text editor will suffice.
-
-SciTE can syntax highlight code in various languages. It also has auto-indentation, code-folding and other such features which are useful when editing code.
-
-SciTE also gives you the option to (compile and) run your code, from within the editor.
-
-Personalizing your Environment
-==============================
-
-.bashrc
--------
-What would you do, if you want bash to execute a particular command each time you start it up? For instance, say you want the current directory to be your Desktop instead of your home folder, each time bash starts up. How would you achieve this? Bash reads and executes commands in a whole bunch of files called start-up files, when it starts up.
-
-When bash starts up as an interactive login shell, it reads the files ``/etc/profile``, ``~/.bash_profile``, ``~/.bash_login``, and ``~/.profile`` in that order.
-
-When it is a shell that is not a login shell, ``~/.bashrc`` is read and the commands in it are executed. This can be prevented using the ``--norc`` option. To force bash to use another file, instead of the ``~/.bashrc`` file on start-up, the ``--rcfile`` option may be used.
-
-Now, you know what you should do, to change the current directory to you Desktop. Just put a ``cd ~/Desktop`` into your ``~/.bashrc`` and you are set!
-
-This example is quite a simple and lame one. The start-up files are used for a lot more complex things than this. You could set (or unset) aliases and a whole bunch of environment variables in the ``.bashrc``. We shall look at them, in the next section where we look at environment variables and ``set`` command.
-
-
-.vimrc
-------
-``.vimrc`` is a file similar to ``.bashrc`` for vim. It is a start-up file that vim reads and executes, each time it starts up. The options that you would like to be set every time you use vim, are placed in the ``.vimrc`` file, so that they are automatically set each time vim starts. The recommended place for having your ``.vimrc`` is also your home directory.
-
-The file ``/etc/vimrc`` is the global config file and shouldn't usually be edited. You can instead edit the ``~/.vimrc`` file that is present in your home folder.
-
-There are a whole bunch of variables that you could set in the ``.vimrc`` file. You can look at all the options available, using the ``:set all`` command in vim. You could use the ``:help option_name`` to get more information about the option that you want to set. Once you are comfortable with what you want to set a particular variable to, you could add it to ``.vimrc``. You should also look at ``:help vimrc`` for more info on the ``.vimrc`` file. If you already have a ``.vimrc`` file, you can edit it from within vim, using ``:e $MYVIMRC`` command. We shall look at some of the most commonly used options.
-
-+----------------------------------+-----------------------------------------------------------------------------------+
-|Command | Vim action |
-+==================================+===================================================================================+
-|``set nocompatible`` | Explicitly disable compatibility with vi |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|``set backspace=indent,eol,start``| In the insert mode, vim allows the backspace key to delete white spaces at the |
-| | start of line, line breaks and the character before which insert mode started. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set autoindent | Vim indents a new line with the same indentation of the previous line. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set backup | Vim keeps a backup copy of a file when overwriting it. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set history=50 | Vim keeps 50 commands and 50 search patterns in the history. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set ruler | Displays the current cursor position in the lower right corner of the vim window. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set showcmd | Displays the incomplete command in the lower right corner. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-|set incsearch | Turns on incremental searching. Displays search results while you type. |
-+----------------------------------+-----------------------------------------------------------------------------------+
-
-You can see the effect of the changes made to your ``.vimrc`` file by restarting vim. If you want to see the changes that you made to your ``.vimrc`` file immediately, you could source the file from within vim.
-
-If the ``.vimrc`` file has been sourced when this instance of vim was started, you could just resource the file again::
- :so $MYVIMRC
-
-If you just created the ``.vimrc`` file or it was not sourced when you stared this instance of vim, just replace the ``$MYVIMRC`` variable above, with the location of the ``.vimrc`` file that you created/edited.
-
-Subshells and ``source``
-========================
-
-A subshell is just a separate instance of the shell which is a child process of the shell that launches it. Bash creates a subshell in various circumstances. Creation of subshells allows the execution of various processes simultaneously.
-
- * When an external command is executed, a new subshell is created. Any built-in commands of bash are executed with int the same shell, and no new subshell is started. When an external command is run, the bash shell copies itself (along with it's environment) creating a subshell and the process is changed to the external command executed. The subshell is a child process of this shell.
-
- * Any pipes being used, create a subshell. The commands on the input and output ends of the pipe are run in different subshells.
-
- * You could also, explicitly tell bash to start a subshell by enclosing a list of commands between parentheses. Each of the commands in the list is executed within a single new subshell.
-
-To avoid creating a subshell, when running a shell script, you could use the ``source`` command.
-::
-
- $ source script.sh
-
-This will run the ``script.sh`` within the present shell without creating a subshell. The ``.`` command is an alias for the source command. ``. script.sh`` is therefore equivalent to ``source script.sh``.
Binary file versionControl/folder.png has changed
Binary file versionControl/glog-2.png has changed
Binary file versionControl/glog-main.png has changed
Binary file versionControl/glog-suggestion.png has changed
--- a/versionControl/handOut.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/versionControl/handOut.rst Tue Aug 31 19:10:09 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:
==================
Binary file versionControl/heads.png has changed
Binary file versionControl/mod.png has changed
Binary file versionControl/scenario.png has changed
--- a/versionControl/vcs.tex Tue Aug 31 18:52:49 2010 +0530
+++ b/versionControl/vcs.tex Tue Aug 31 19:10:09 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
-----
--- a/versionControl/versionControl.rst Tue Aug 31 18:52:49 2010 +0530
+++ b/versionControl/versionControl.rst Tue Aug 31 19:10:09 2010 +0530
@@ -21,7 +21,7 @@
+---------+---------------------------------+---------+
| Session | Topic | Duration|
+=========+=================================+=========+
-| 1 | Introduction to Course | 5 mts |
+| 1 | Introduction to Course | 10 mts |
+---------+---------------------------------+---------+
| 2 | Why Revision Control? | 5 mts |
| | - Use case: for team | |