Category Archives: General

Version Control Systems

Version control or source control is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software develoment, where a team of people may change the same files. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”. So it is also known as revision control.

Version control systems (VCSs – singular VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processor (e.g., Microsoft Word, Writer, K Word, Pages, etc.), spreadsheets (e.g., Microsoft Excel, Calc, K Spread, Numbers, etc.), and in various content management systems (e.g.,joomla, WordPress).

Distributed revision control

Distributed revision control (DRCS) takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer’s working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches (change-sets) from peer to peer. This results in some important differences from a centralized system:

  • No canonical, reference copy of the codebase exists by default; only working copies.
  • Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.

Rather, communication is only necessary when pushing or pulling changes to or from other peers.

    • Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing natural protection against data loss.


Mercurial is a modern, open source, distributed version control system, and a compelling upgrade from older systems like Subversion. Developers use it to manage source code.

In Mercurial every developer has a copy of the entire repository on their hard drive. It’s actually safer. And anyway, almost every Mercurial team uses a central repository, too, which you can back up compulsively, and you can build a three-ringed security zone complete with layers of Cylons, Stormtroopers, and adorable labradoodles.

Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmlessn Mercurial, every developer has their own repository.So you can commit your code to your private repository, and get all the benefit of version control, whenever you like. Every time you reach a logical point where your code is a little bit better, you can commit it.Once it’s solid, and you’re willing to let other people use your new code, you push your changes from your repository to a central repository that everyone else pulls from, and they finally see your code. When it’s ready.

Mercurial separates the act of committing new code from the act of inflicting it on everybody else.

And that means that you can commit (hg com) without anyone else getting your changes. When you’ve got a bunch of changes that you like that are stable and all is well, you push them (hg push) to the main repository.

Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time.In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.

Mercurial thinks in terms of “changesets” instead of “revisions” it can merge code much better than Subversion.”

Subversion is basically revision control for files, but in Mercurial, revision control always applies to an entire directory—including all subdirectories.

Actually Mercurial serves two important purposes:

  1. It keeps track of every old version of every file
  2. It can merge different versions of your code, so that teammates can work independently on the code and then merge their changes

The command for Mercurial is hg:

basic commands:
use "hg help" for the full list of commands or "hg -v" for details

hg init         –    creates a repository
hg add         – schedules files to be added to the repository. They won’t actually be added until you commit
hg commit   –  saves the current state of all files to the repository
hg log         –   shows the history of changes committed to the repository
hg revert     –   revert changed files back to committed version
hg status   –   shows a list of changed files
hg diff      –    shows what changed in a file
hg remove – schedules files to be removed from the repository. They won’t actually be removed until you commit.
hg cat        –  shows any revision of any file.
hg update  – update the working directory to a particular revision
hg serve    – runs a web server to make the current repository accessible over the Internet
hg clone   –  make a complete copy of an entire repository
hg push   –   push new changes from this repository into another
hg outgoing – list changes in current repository waiting to be pushed
hg merge   –   merge two heads
hg parent   –   show the changeset that’s in the working directory


Starting with python

Python is a Programming Language

     Started by Guido van Rossum in 1990 as a way to write software for the Amoeba operating system. Influenced by ABC, which was designed to be easy to learn. It is also very useful for large programs written by expert programmers.The word “Python” comes from the comedy troupe “Monty Python”.

Guido Van Rossum
Python is an interpreted, general-purpose high-level programming language whose design philosophy emphasizes code readability. Python claims to “[combine] remarkable power with very clear syntax”, and its standard library is large and comprehensive. Its use of indentation for block delimiters is unique among popular programming languages.

How a python program runs

When we write a python program and execute it, there occurs the output or errors. But what actually happens behind them?? Let’s see..
First take the simplest of python program. The hello world program.

$ vi

print ‘Hello World’

The filename has the extension .py to show that its a python file. Its not necessary as any filename will do as long as it contains a valid python code. We use the .py extension anyhow for consistency.
if we save the file and execute it,


Hello World
Thats all the output that we see. And we think thats it!!! Well thats what happens on the outside and thats all that a normal programmer needs to know. But sometimes its good to know what actually happens under the hood when we execute the python program. There are a couple of common steps that the pyhton program does before executing the program.
These steps are:

Compiling the code to what is known as a byte code that is common to all the machines.

Running this bytecode using a Virtual Machine

Byte Code

When we give the command to execute the program, the python first compiles our souce code to a format that is known as a byte code. This byte code is a lower level and platform independent(but version dependent) representation. Hence these can be ported to any system that contains the same python version. This step is done to improve the speed of execution of the program. The byte code in python is of .pyc format. If we execute the program outside the interpreter, then the .pyc file is usually temporarily stored in the memory and discarded after the execution.But if we are running the program from the interpreter, a .pyc file is created in the same folder as the program. And the python will execute a pyc file even if the original py file is absent. If a program is being executed, the python looks if the .pyc file is present and it has the time stamp as the file. If so, that file is executed and not the py file for a faster execution.
Now once the Byte Code has been compiled, the program is ready for execution. The virtual machine steps in. The .pyc file is send to the Python Virtual Machine for execution. The virtual machine is a big loop that executes through our byte code instruction one by one to carryout our instructions. The PVM is the runtime engine of Python; it’s always present as part of the Python system, and is the component that truly runs our scripts. Technically, it’s just the last step of what is called the Python interpreter. Byte code compilation is automatic, and the PVM is just part of the Python system that we have on our system.

‘Innovation’ begins…

Hi…. I am Vidya. I am starting this blog as per the suggestion of Mr Pramode.C.E, a programmer and consultant on free and open source software based technologies. Now I am doing a programming course in IC Software under Mr. Pramode.C.E.

I think, this will be a good experience and a great start for my career.

The Blog

The latest news on and the WordPress community.