Please welcome Manish Sinha to the writing staff! Manish is a very clever individual, with experience working on everything from Zeitgeist to Elementary.
Hi OMG! Ubuntu! readers, this is my first post. I will mostly be writing about technical topics as editorials.
My aim is to explain tough technical subjects in a simple way which would useful for wannabe contributers who have found contributing too tough because of the steep learning curve associated with certain tools.
Collaboration is probably the most difficult and time consuming task when working as a team. When you first heard the phrase “version control” you might have started thinking about code and progammers. The issue of collaboration is not only with programmers but also with other areas and profession namely with design, documentation etc. Version control as a tool has been immensely famous within programming circles, but its use is not limited just for source code.
When you are working as a team on the same thing (like a similar design or a set of documentation files), then the biggest problem might be to make sure that every person has the latest work. When all of the contributors work together they make changes to every part, and then the changes need to be shared.
Solutions?
One solution is to email each other the changes only to open up your mailbox and get lost amongst the lolcat pics or reddit. The chances of skipping some of them is also high since you might end up getting too many emails. If you and some other guy change the same file, then taking out his/her changes and incorporating them into yours can be a nightmare.
Another solution is to send all changes to one person and he/she will take care of merging multiple files and keeping the files up to date. This involves one person dedicated to this work. What a waste of time!
More issues? Gah!
Another issue you might face is that some point of time you find that the current situation of your design or documentation is not so good and the one you had 4 days back looked better. What will you do?
Look at the files sent to you 4 days back from someone. Hunt those files in your mailbox, join all the bits and pieces together and you might still not be sure if you have the correct set of files.
How about someone asks you – “How much work did you people do in the last one month”. There can be time when you want to brag about how much work you people did as a team, or if you’re working as a contractor or an employee, it’s useful to have a record of work.
Summing up the major issues
The major problems highlighted above are:
- Collaboration amongst many people who are working on same set of files
- Keeping track of files and reverting back to some savepoint/milestone.
This is where version control systems (VCS) come into the picture. I am avoiding the term “source control system” as it sounds as if it was meant only for source code. The above two problems highighted are solved by VCS brilliantly.
In a nutshell, most of the VCS consists of two parts. A central server which is used by all the members of the team as a common area where they put their work and also fetch other people’s work from there. It is an attempt to synchronize oneself with everyone else.
The second part, the client tool of the version control system helps you push your work to the server and pull other’s work from the server.
The Basics
Get your copy
If you are a person who just joined the team, you might want to fetch all the files. In this case you’ll be creating a clone of the set of files.
You provide the URL of the server to your VCS client and it will fetch all the files for you. Then you can start working on those files.
Make your changes
After some work on the files (fixing bugs, adding new features etc) you decide that this work is enough for now and you want to share these changes with other people.
The VCS client tracks all the files. You can ask it to show which files you have changed and what you have changed in those files.
Save your changes
After checking that the changes are fine, you need to commit your changes. A commit is nothing but a save point or a milestone. You can have many savepoints in a codebase.
Check and Analyze the changes
You can even find the changes you made between 3rd and 4th commit or 23rd and 25th commit. This is because your VCS knows the current situation of files and it also knows what content was present when you made the 23rd commit and what content was present when you made the 26th commit.
In the screenshot below we are showing the changes made between commit no 1714 and 1716:
After making the commit, your VCS will tell you that there are no pending changes.
This happens because you committed all the pending changes. In this case you need to submit your changes on the server. This is done by pushing your changes to the remote URL from where you made a copy of the files.
Sync with your team
After pushing you might be interested in knowing if someone else pushed their work while you were making your changes and committing it. This is done by asking your VCS client to pull the changes from the remote server.
You can try to pull again after some time if you come to know that someone else in the team has pushed their changes too. It is usually a good practice to pull the changes before you start working on the files. This might not be necessary in every scenario, but you will always having the latest changes which is usually better.
In the screenshot below, I try to pull the changes and was notified that there are no more changes.
Notes
This was just an introduction to what a version control system actually is.
The one I used in the snapshots is bazaar (aka. bzr) which is used in Launchpad and few other places (e.g. GNU Savannah).
The other ones in the category of VCS are Subversion, Git, Mercurial etc.
There are two kinds of version control: Centralized and Distributed. Bazaar is an example of distributed version control system – DVCS. Git and mercurial also fall in this category while Subversion (svn) is a centralized VCS.
This article was targeted at people who always feared using any kind of version control systems, so if you start nitpicking, there will be many mistakes! The future articles will be very precise and will use actual terms.
In future parts you should expect:
- What is git?
- Git and Bzr using graphical applications instead of command line
- How to use Bazaar with Launchpad
- The difference between a centralized and distribution version control system
.. and many more.
Thanks!