RSSfeed
22nd April 2011, 16:13
Hi OMG Ubuntu readers, this is my first post. I would be mostly writing on technical topics as editorials. My aim is to explain the tough technical topics in a simple way which would be probably useful for wanna contributers who have found contributing too tough because of the steep learning curve associated with the associated tools.
Collaboration is probably the most tough and time consuming thing when working as a team. When you heard the word “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 it’s use is not limited just for source code.
When you are working as a team on the same thing like same design or a set of documentation files, then the biggest problem might be to make sure that every person has the latest work or each other. Example when all of them work together they make changes to every part, then the changes needs to be shared.
Solutions?
One solution is to mail each other their 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 mails. If you and some other guy changes the same file, then taking out his/her changes and incorporating them in yours is a nightmare.
Another solution can be to send this to one person and he/she will take care of the merging multiple files and keeping the files upto date. This involves one person dedicated to this work. What an utter wastage of human labor.
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.
Summing up the major issues
The major problems highlighted above are:
Collaboration amongst many people who are working on same set of files
Keeping a track of files and reverting back to some savepoint/milestone.
This is where version control systems(VCS) come in 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 very brilliantly.
In a nutshell, most of the VCS consist 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 syncronize oneself with everyone else. 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 make 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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/CloneRepo-500x66.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/clonerepo/)
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/FinishedCloneRepo-500x130.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/finishedclonerepo/)
Make your changes
After some work you decide that this much work is enough and you want to share these changes with other people. *The VCS client tracks all the files. You can ask it to show which all files you have changed and what you have changed in those files.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/ChangesMade-500x280.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/changesmade/)
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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/MakeTheCommit-500x322.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/makethecommit/)
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 all contents were present when you made the 23rd commit and what all contents were present when you made the 26th commit. In the snap below we are showing the changes made between commit no 1714 and 1716
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/ChangesBetweenRevisions-500x350.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/changesbetweenrevisions/)
After making the commit, your VCS will tell you that there are no pending changes. This happens because you commited 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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/WorkingBranchClean.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/workingbranchclean/)
Sync with your team
After pushing you might be interested in knowing if someone else pushed their work meanwhile 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 snap below, I try to pull the changes and was notified that there are no more changes
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/NoRevisionsToPull-500x96.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/norevisionstopull/)
Notes
This was just an introduction part of what a version control system actually is. The one which I used in the snapshots is bazaar 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 which is 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 would be many mistakes. The future articles will be very precise and will use actual terms.
In the future parts you should expect
What is git?
Using git and bzr using graphical application instead of command line
How to use bazaar with Launchpad
What is the difference between a centralized and distribution version control system
.. and many more.
http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/0/di (http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/0/da)
http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/1/di (http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/1/da)
http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:wBxX2hOkimM (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:wBxX2hOkimM) http://feeds.feedburner.com/~ff/d0od?d=qj6IDK7rITs (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:qj6IDK7rITs) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:V_sGLiPBpWU (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:V_sGLiPBpWU) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:-BTjWOF_DHI (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:-BTjWOF_DHI) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:gIN9vFwOqvQ (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:gIN9vFwOqvQ) http://feeds.feedburner.com/~ff/d0od?d=yIl2AUoC8zA (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:yIl2AUoC8zA)
http://feeds.feedburner.com/~r/d0od/~4/-rU6lhVMsjY
Mer ... (http://feedproxy.google.com/~r/d0od/~3/-rU6lhVMsjY/)
Collaboration is probably the most tough and time consuming thing when working as a team. When you heard the word “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 it’s use is not limited just for source code.
When you are working as a team on the same thing like same design or a set of documentation files, then the biggest problem might be to make sure that every person has the latest work or each other. Example when all of them work together they make changes to every part, then the changes needs to be shared.
Solutions?
One solution is to mail each other their 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 mails. If you and some other guy changes the same file, then taking out his/her changes and incorporating them in yours is a nightmare.
Another solution can be to send this to one person and he/she will take care of the merging multiple files and keeping the files upto date. This involves one person dedicated to this work. What an utter wastage of human labor.
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.
Summing up the major issues
The major problems highlighted above are:
Collaboration amongst many people who are working on same set of files
Keeping a track of files and reverting back to some savepoint/milestone.
This is where version control systems(VCS) come in 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 very brilliantly.
In a nutshell, most of the VCS consist 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 syncronize oneself with everyone else. 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 make 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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/CloneRepo-500x66.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/clonerepo/)
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/FinishedCloneRepo-500x130.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/finishedclonerepo/)
Make your changes
After some work you decide that this much work is enough and you want to share these changes with other people. *The VCS client tracks all the files. You can ask it to show which all files you have changed and what you have changed in those files.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/ChangesMade-500x280.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/changesmade/)
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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/MakeTheCommit-500x322.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/makethecommit/)
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 all contents were present when you made the 23rd commit and what all contents were present when you made the 26th commit. In the snap below we are showing the changes made between commit no 1714 and 1716
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/ChangesBetweenRevisions-500x350.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/changesbetweenrevisions/)
After making the commit, your VCS will tell you that there are no pending changes. This happens because you commited 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.
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/WorkingBranchClean.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/workingbranchclean/)
Sync with your team
After pushing you might be interested in knowing if someone else pushed their work meanwhile 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 snap below, I try to pull the changes and was notified that there are no more changes
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/04/NoRevisionsToPull-500x96.png (http://www.omgubuntu.co.uk/2011/04/understanding-version-control-systems-part-i/norevisionstopull/)
Notes
This was just an introduction part of what a version control system actually is. The one which I used in the snapshots is bazaar 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 which is 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 would be many mistakes. The future articles will be very precise and will use actual terms.
In the future parts you should expect
What is git?
Using git and bzr using graphical application instead of command line
How to use bazaar with Launchpad
What is the difference between a centralized and distribution version control system
.. and many more.
http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/0/di (http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/0/da)
http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/1/di (http://feedads.g.doubleclick.net/~a/puEH1o_1pZ5meZPU2yF70UUgtDU/1/da)
http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:wBxX2hOkimM (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:wBxX2hOkimM) http://feeds.feedburner.com/~ff/d0od?d=qj6IDK7rITs (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:qj6IDK7rITs) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:V_sGLiPBpWU (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:V_sGLiPBpWU) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:-BTjWOF_DHI (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:-BTjWOF_DHI) http://feeds.feedburner.com/~ff/d0od?i=-rU6lhVMsjY:NhxZGzBa3NI:gIN9vFwOqvQ (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:gIN9vFwOqvQ) http://feeds.feedburner.com/~ff/d0od?d=yIl2AUoC8zA (http://feeds.feedburner.com/~ff/d0od?a=-rU6lhVMsjY:NhxZGzBa3NI:yIl2AUoC8zA)
http://feeds.feedburner.com/~r/d0od/~4/-rU6lhVMsjY
Mer ... (http://feedproxy.google.com/~r/d0od/~3/-rU6lhVMsjY/)