Working with Mercurial

 

What is Mercurial

Mercurial is a Version Control System, just like Git with few changes, Mercurial is a Open Source Software, written in Python, unlike Git which is written in perl and C and was developed by Linus Torvalds. Although Git and Mercurial are almost same in there nature, different people have different preferences.

 According to Wikipedia, Mercurial is a cross-platform, distributed revision control tool for software developers. Mercurial's major design goals include high performance and scalability, decentralized, fully distributed collaborative development, robust handling of both plain text and binary files, and advanced branching and merging capabilities, while remaining conceptually simple.It includes an integrated web interface. Mercurial has also taken steps to ease the transition for SVN users.

Getting started with Mercurial

• You can download and install Mercurial using

                      sudo apt-get install mercurial (for Ubuntu/debian)
                      yum install mercurial (for Fedora)

• You have to create a .hgrc file in your home directory, as  "." in hgrc suggest that it is a hidden file, it is a configuration file and must be stored in home directory. Following is an example of .hgrc  file.

                       

[ui]
username = Rahul Mishra <rahulmishra@gmail.com>

[extensions]
purge =
strip =
color =
pager =
progress =
rebase =

[pager]
pager = LESS='FSRX' less
attend = tags, help, annotate, cat, diff, export, status,\
         outgoing, incoming, glog, log, grep

Using Mercirial

• After setting up the .hgrc file we are ready to go, we can make a directory, mkdir dir_name then cd dir_name.

•  Then we can create a file say vim Test.txt and we can write in it  and finally save and exit.

• For intailizing Mercurial we have to give command hg init, just like git init, this command will initialize this directory as Mercurail repo.

• hg init will add a hidden file .hg in this directory,also we have to add our file Test.txt to the empty repo by using command hg add Test.txt.

• Next we have to commit the file, using hg commit <file_name>, this will open an editor, it is nano as default, you can also change with  select-editor command. Writing a good and precise and meaning full is very important, also give a space between the heading and the details.

• A patch file is generated in the same way, now if we change our Test.txt and do a hg diff, we can see the difference made in the file. hg diff works only when you have not committed the changes, because once you have committed the changes the buffer are overridden and hg diff will not produce any output.

• hg log gives the changes made in every commit and also gives the heading of the commit message. 

•   hg status will give the currnt status of the files as Modified or  Added.     

         The dgplug Summer Training is back '14

The #dgplug Summer Training is back again this year, started this week, it had more then 150 members in the initial days. This Summer training is however different from any other training, conducted on IRC(Internet Relay Chat) and surely one of a kind, the summer training aims mainly on python and FOSS(Free and Open Source Software) and Real-world project experience.



This training is conducted on freenode network and #dgplug channel, can be accessed by any IRC client, chatzilla and Xchat being the most famous ones. I personally use chatzilla as IRC Client. Typically the students are from Durgapur and Kolkata, however there are many students from different parts of India as well as abroad. The class usually starts at 18:30 IST and mainly conducted by Kushal Das (nick- kushal) CPython Developer and works in Redhat, Pune, India. Also others moderators are Sayan Choudhary(nick - sayan), Ratan Debnath (rtnpro), Chandan Kumar and Eijah.


Highlight of this summer training being interactions with the develpores, talks given by various Up stream Developers and online communcations atticates. This is my second year in this Training, last year i could not complete it because of Placement and studies issues, this year i have another problem, its the damn job training starting next month, although i will try my level best to continue my classes.

The only problem that the class have (according to me) is that the no. of students participating decrease day by day, and only 10-20 students complete there training fully, may be this is because not everybody can grasp to the new things they are learning also the pace the class goes with presents a little problem but the main problem being the students itself, they grows the tendency of not asking question and gradually the lose there interest too, else everything related with this training is just awesome.

 UNDERSTANDING GITHUB

To understand GitHub, you must first have an understanding of Git. Git is an open-source version control system that was started by Linus Trovalds – the same person who created Linux. Git is similar to other version control systems – Subversion, CVS, and Mercurial to name a few.

Git in Github

So, Git is a “version control system,” what’s that mean? When developers are creating something (an application, for example), they are making constant changes to the code and releasing new versions, up to and after the first official (non-beta) release.

Version control systems keep these revisions straight, and store the modifications in a central repository. This allows developers to easily collaborate, as they can download a new version of the software, make changes, and upload the newest revision. Every developer can see these new changes, download them, and contribute.

Similarly, people who have nothing to do with the development of a project can still download the files and use them. Most Linux users should be familiar with this process, as using Git, Subversion, or some other similar method is pretty common for downloading needed files, especially in preparation for compiling a program from source code (a rather common practice for Linux geeks).

Hub in GitHub

We’ve established that Git is a version control system, similar but better than the many alternatives available. So, what makes GitHub so special? Git is a command-line tool, but the center around which all things involving Git revolve – effectively, the Hub, is GitHub.com, where developers can store their projects and network with likeminded people.

Technical Terms

Repository

A repository is a location where all the files for a particular project are stored, usually abbreviated to “repo.” Each project will have its own repo, and can be accessed by a unique URL.

Forking a repo

“Forking” is when you create a new project based off of another project that already exists. This is an amazing feature that vastly encourages the further development of programs and other projects. If you find a project on GitHub that you’d like to contribute to, you can fork the repo, make the changes you’d like, and release the revised project as a new repo. If the original repository that you forked to create your new project gets updated, you can easily add those updates to your current fork.

Pull requests

You fork a repository, make a great revision to the project, and want it to be recognized by the original developers, maybe even included in the official project/repository. You can do so by creating a pull request, so the authors of the original repository can see your work, and then choose whether or not to accept it into the official project. Whenever you issue a pull request, GitHub provides a perfect medium for you and the project’s maintainer to communicate.

 And the best part: GitHub isn’t just for developers

All this talk about how GitHub is ideal for programmers may have you believing that they are the only ones who will find it useful. Although it’s a lot less common, GitHub can actually be used for any types of files – so if you have a team that is constantly making changes to a word document, you can actually use GitHub as your version control system.  This practice isn’t common as there are better alternatives, but keep it in mind.

GSoC 2014

Ah!, finally GSoC Registration time for students are coming to an end. And hopes and  dreams of thousands of students, are on stake as working for some big orgs can come true in real life. But getting a proposal approved by the mentoring organisations is not a easy task, especially if you are working with big orgs, like Gnome, gnu, wikimedia, the Linux foundation etc. First you have to start by fixing a bug, which is not a easy task, believe me, i have gone through this stage, the pressure is enormous, and also you have to do in a fix limited span of time. After that there comes the big task of writing a proposal, which is again not a easy task, different orgs have there different template designed, so that they can easily evaluate the proposals, as working for wikimedia, i got a simple template and then you just have to get started.

Most of the ideas proposed are from the idea-page of that org, but you just cant copy the whole stuff and paste in your proposal, you have to be specific about your idea and how you are willing to execute what ever is your idea, with proper timeline and phases.


I may not get the chance for working as intern in GSoC, this year, as they can only choose one candidate, and they make sure, that only the best gets it, having said that, one should not lose there hope, and should continue to contribute, because thats the main agenda of GSoC. i.e. more and more student contribute to Open Source. And i will continue to do so.
 
Also in midst of all these, proper communication is also very important, you have to on IRC, mailing-list, and in regular contact with mentors and admins. Even all these things does not guarantees the approval of your proposal, so the cool thing would be to relax, just try to give your best, be in contact with your mentors and try to improve your final proposal.