Version control for an agile team
A version control system is not just a tool to manage the content of a project, it's defines how the project team collaborate and interact with each other. And it plays an important part when the team decides how they are going to manage the changes to the code.
Version controlling systems started with lock based version controlling with RCS, SCCS in 70’s. And the next generation CVSwere CVS in 1986, Perforce (1995), CVSNT (1998), and then we got Subversion (2000); they were commonly referred as centralized version controlling systems which means they have a central repository which keeps all the content and the history. Individual clients (team members) have their local code which can be sync with the central repository. And also a client can get the historical versions of the files as well.
Figure1: Centralized version controlling
In this type of version controlling systems every change had to be submitted to the central repository. Let's say A needs to some change and B need's to get that change to proceed his work. Then A should check-in or push the change to the central repository and B need's to get or pull those changes from the central server. These changes will also be visible to C, whether this is desired or not. This model is called a centralized version control systems. Arch, Monotone and Bitkeeper were the first Distributed version control systems (DVCS). In December 1999 Linus Torvalds, the creator of Linux kernel, chose Bitkeeper in order to manage the mainline kernel sources. At that time Bitkeeper was the only truly distributed version control system which had repositories for every user of the source control system. That means in a DVCS all the clients have a repository which can be called a local repository containing all historical revisions and branches.
Figure2: Distributed Version Controlling
So in this model since each endpoint has the total repository it can be act as a server itself. There is no central point which controls everything but each endpoint can directly push or pull updates from any other endpoint which makes it kind of a peer to peer network.
Figure3: DVCS in operation
One of the advantages of having a local repository for each endpoint is that we can work offline without connecting to a central repository like centralized version control systems. Since all the historical data is in the local repository we can get older versions and even merge them offline. This make developers work easy because developers can work where ever they are. And in distributed version control systems branching and merging is an easy task compared to other version control systems because every change acts as a kind of a branch and we need to merge that to the main branch. This is because DVCS's keep change sets instead of versions of the file. When we do a commit what it stores is the change we have done instead of a new version of older file like most of the centralized version control systems. This makes merge easy since it's just applying sequence of changes to a file instead of merging two versions of a file.
By encouraging branching and merging DVCS offers flexibility for the developers to experiment new ideas without affecting the main branch. For agile teams it's really important to have flexibility to change the code and experiment new requirement in different ways. Let's say for a new requirement or a feature team needs to do some R&D on several ways of doing it. Then with the DVCS team can create experimental branches to experiment different methods and if one experiment is successful then it's just a matter of merging that one in to the main development branch. For agile teams it's really important to have flexibility to change the code and experiment new requirements in different ways. For example, the team needs to do some R &D to figure out the best approach to implement a new requirement or feature. Then with the DVCS team can create branches to experiment different methods and select the branch having the most successful experiment and then it's just a matter of merging that branch in to the main development branch.
Figure 4: Diagram showing experimental branches
This allows developers to work freely. It doesn't really matter that a developer breaks the build in an experimental branch because he can work independently on their branch. And it increases the collaboration of the agile team because it's really easy to push the changes directly to any other member without affecting any other members in the team. This gives us another important advantage of DVCS for agile teams.
Figure 5: peer to peer communication
And this increases the collaboration and the effectiveness of agile teams. With the centralized model, if one team member needs to share his version of code with someone else, he needs to push his changes to the central server and then the other one needed to pull changes from the central. But in DVCS there is no central server to control; therefore one user can directly push his changes to any other user because it enables. This increases the effectiveness of an agile team in several ways because sometimes it is really important to work independently for two or three people in the team. And most importantly this enables two people to to do pair programmingwork withoutindependently without affecting other team member's code. And if you want to pair program remotely then the Dropbox will be the ideal tool.
Figure 5 shows a model with one central repository and several team members. The central repository has the stable version of the code. This is somewhat similar to a centralized model. But the link between A and B is enabled by the DVCS. If A and B needs to some pair programming they can directly push and pull the changes. This is more important, because sometimes they need sync unstable code. Of course you can do it with other centralized version control systems as well .But in that case the changes need to be emailed to the other developer.
Once we have chosen DVCS over centralized version control systems as the best option for our needs, then we need to consider which tool to use. Git and Mercurial are the well-known and widely used DVCS. Both of them are open source and have some similar functionality. Git is more complex to use rather than mercurial because it has more complex and more flexible model. Therefore mercurial is easy for someone coming from a centralized version controlling background to adapt to quickly. You may find links to good articles on git and mercurial at the references section. A version controlling system for an agile team should be agile too. That means the tool should be flexible enough for the team to use as a successful version controlling and a collaboration model. Choosing the right tool for a particular job is really important but it can be difficult task as well. Because we are familiar with one tool and mastered how it can be used, we tend to be bias towards it instead of looking at how a different tool can be more productive. But if we can change our mind set for exploring the different options we have and to choose the best tools that will help us, we can improve efficiency and the effectiveness of the team.
Reference:
Figure1: Centralized version controlling
In this type of version controlling systems every change had to be submitted to the central repository. Let's say A needs to some change and B need's to get that change to proceed his work. Then A should check-in or push the change to the central repository and B need's to get or pull those changes from the central server. These changes will also be visible to C, whether this is desired or not. This model is called a centralized version control systems. Arch, Monotone and Bitkeeper were the first Distributed version control systems (DVCS). In December 1999 Linus Torvalds, the creator of Linux kernel, chose Bitkeeper in order to manage the mainline kernel sources. At that time Bitkeeper was the only truly distributed version control system which had repositories for every user of the source control system. That means in a DVCS all the clients have a repository which can be called a local repository containing all historical revisions and branches.
So in this model since each endpoint has the total repository it can be act as a server itself. There is no central point which controls everything but each endpoint can directly push or pull updates from any other endpoint which makes it kind of a peer to peer network.
One of the advantages of having a local repository for each endpoint is that we can work offline without connecting to a central repository like centralized version control systems. Since all the historical data is in the local repository we can get older versions and even merge them offline. This make developers work easy because developers can work where ever they are. And in distributed version control systems branching and merging is an easy task compared to other version control systems because every change acts as a kind of a branch and we need to merge that to the main branch. This is because DVCS's keep change sets instead of versions of the file. When we do a commit what it stores is the change we have done instead of a new version of older file like most of the centralized version control systems. This makes merge easy since it's just applying sequence of changes to a file instead of merging two versions of a file.
By encouraging branching and merging DVCS offers flexibility for the developers to experiment new ideas without affecting the main branch. For agile teams it's really important to have flexibility to change the code and experiment new requirement in different ways. Let's say for a new requirement or a feature team needs to do some R&D on several ways of doing it. Then with the DVCS team can create experimental branches to experiment different methods and if one experiment is successful then it's just a matter of merging that one in to the main development branch. For agile teams it's really important to have flexibility to change the code and experiment new requirements in different ways. For example, the team needs to do some R &D to figure out the best approach to implement a new requirement or feature. Then with the DVCS team can create branches to experiment different methods and select the branch having the most successful experiment and then it's just a matter of merging that branch in to the main development branch.
Figure 4: Diagram showing experimental branches
This allows developers to work freely. It doesn't really matter that a developer breaks the build in an experimental branch because he can work independently on their branch. And it increases the collaboration of the agile team because it's really easy to push the changes directly to any other member without affecting any other members in the team. This gives us another important advantage of DVCS for agile teams.
Figure 5: peer to peer communication
And this increases the collaboration and the effectiveness of agile teams. With the centralized model, if one team member needs to share his version of code with someone else, he needs to push his changes to the central server and then the other one needed to pull changes from the central. But in DVCS there is no central server to control; therefore one user can directly push his changes to any other user because it enables. This increases the effectiveness of an agile team in several ways because sometimes it is really important to work independently for two or three people in the team. And most importantly this enables two people to to do pair programmingwork withoutindependently without affecting other team member's code. And if you want to pair program remotely then the Dropbox will be the ideal tool.
Figure 5 shows a model with one central repository and several team members. The central repository has the stable version of the code. This is somewhat similar to a centralized model. But the link between A and B is enabled by the DVCS. If A and B needs to some pair programming they can directly push and pull the changes. This is more important, because sometimes they need sync unstable code. Of course you can do it with other centralized version control systems as well .But in that case the changes need to be emailed to the other developer.
Once we have chosen DVCS over centralized version control systems as the best option for our needs, then we need to consider which tool to use. Git and Mercurial are the well-known and widely used DVCS. Both of them are open source and have some similar functionality. Git is more complex to use rather than mercurial because it has more complex and more flexible model. Therefore mercurial is easy for someone coming from a centralized version controlling background to adapt to quickly. You may find links to good articles on git and mercurial at the references section. A version controlling system for an agile team should be agile too. That means the tool should be flexible enough for the team to use as a successful version controlling and a collaboration model. Choosing the right tool for a particular job is really important but it can be difficult task as well. Because we are familiar with one tool and mastered how it can be used, we tend to be bias towards it instead of looking at how a different tool can be more productive. But if we can change our mind set for exploring the different options we have and to choose the best tools that will help us, we can improve efficiency and the effectiveness of the team.
Reference:
- http://www.infoq.com/articles/dvcs-guide&num=30
- http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Hi - this is SB2055 from StackOverflow. Can you let me know if you're available for hire?
ReplyDeleteThis comment has been removed by the author.
DeleteVsmarpeteo-po1997 Brian Thao link
ReplyDeletesmithasoblu