• warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 2 to gmap_gmap() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.
  • warning: Parameter 1 to tac_lite_node_grants() expected to be a reference, value given in /home/rbezemer/softwarebyrichard.com/includes/module.inc on line 483.

What is the Best Source Control for My Team?

All software development teams are hunting for that perfect source control system that perfectly handles every case. But lets face it source control is confusing and it's a huge investment of time to investigate which source control system to use, and if you pick wrong, it can be very costly to your project. This is probably the biggest reason new Source Control Systems take so long to take traction, Why would any business manager take a known risk of changing the source control system when the current one works. It worked for our last release...Right.

Source control is a confusing endeavor which is made more difficult by the fact the majority of developers do not have a lot of experience with it. It's frustrating, we all use some form of source control on a daily basis but how many of us actually understand what is going on in the back end? At most companies source control setup and administration is handles by a select few and is so shrouded in mystery developers are hesitant to ask to many questions (probably due to the fact if they understand it to well they will be seen as the "expert" everyone in the office bugs about their checkin and why my commit broke the build...)

InfoQ has a fantastic write up about comparing the benefits of distributed source control systems here. I am personally not convinced distributed source control is the way to go. They have received a lot of press recently with Linus Torvalds pushing how great git is and how "real" developers should be only using distributed source control. While distributed source control is great for open source projects where one person tends to own the code and you have a few external developers working on the odd feature, yes distributed is probably the way to go. However in a corporate environment where you have a team plugging away towards a release I would be very worried to go away from a centralized system. I'm going to build on the differences between the two different systems. 

 

Centralized source control systems (such as Subversion) have a lot of good things going for them. It represents the progression of code in a very linear way. It's easy to see how the code got from point A to point B and track how a piece of code evolved during the development cycle. The one draw back is on a very large, or well established project you can have very deep trees to represent all the development branches that occurred during the development cycle.

 

The repository has a well defined owner, which would be your centralized server. If you have a new person joining the team you can just point them to the one central server and one main branch that they can work from. Build integration systems ( such as Cruise Control or Hudson ) are simple to set up with centralized source control as well. You can simple create a new build project for each branch and all code can be verified and unit tested, and potentially released from on of these systems.

The biggest draw back of a centralized system is there tends not to be as dedicated owner of the codebase which makes branching and merging more difficult. Each individual user is expected to have a rudimentary understanding of merging and be able to merge their changes in with everyone elses on the main development branch. This causes much more havoc when you have the cowboy developer on your team who is always blowing away your changes with their latest and greatest code produced during their last all nighter coding session. These developers tend not to play nice with the stable branch and like to think their code is more important than everyone elses and push the responsibility of integrating their code to everyone else using the branch.

You also pay for this in size, since you are tracking everyone's changes all on one server as you can imagine it eats up a lot of space both on the server and on each users individual development machines.

 

Distributed source control (such as Git, Mercurial, or Bazaar )  basically follows the philosophy that everyone owns the code. There does not have to be a central server and everyone is basically working on their own branch of the code. This works well if your teams uses the one feature per developer methology and as you can imagine plays right into the hand of the cowboy developer as they don't have to pay attention to what other are working on and "getting in the way" of their code.

 

Developer changes are tracked individual, and it basically works like you think it would. If you want to work on a piece of code, you basically go to each developer working on the project and say I need your changes to work on my code, and go round and round until you have all the code you need. Of course this makes it easy for developers to show other developers exactly what the code looks like on their system without polluting the trunk with testing or debug code, or for extreme programmers to synch two developers changes together. Quite often in a distributed system there is a maintenance or production "user" which takes care of creating a view of all the independent developers changes into one cohesive released project.

One side effect is distributed source control offers you the option of having localized commites. Since you are basically working on your own version of the code, you can check your code in offline and not have to report you changes back to a centralized server. While this is handy if you are testing and want to undo changes you accidentally added or remove code that didn't work, I find it's almost redundant now as lately ide's  tend to have this feature built in to them (like Eclipse). It's a handy feature to have but may lure developers into thinking their code is backed up when it may not be.

So what is the best system for a team to use? The short answer is anything. Any source control is better than none. In my experience for a well defined team of developers you can't beat a centralized system where all developers must ensure their code plays well with everyone elses. You can plan a release schedule around a branch and simply build off that branch to periodically release trial software to testing or for demo purposes. There is no running around involved to merge together individuals code, it is done for you by design.

The biggest advantage is code ownership. In a centralized system your development branch is the ultimate authority on the current state of the codebase. All developers must ensure their code integrates well with everyone elses before it is able to be used by anyone, and if you have a new developer to the team you can point them to one location for everything they need.

It is missing the nice feature of being able to share the exact state of code on your system, but with a little bit of planning this can be accounted for with feature or research branches where developers can share code without having to worry about breaking the build. If you have the strong developer on your team who has a definite ownership of the codebase, the distributed system is definitely more advantageous and you can see how it would make enforcing code reviews easy as all changes whould have to be pulled together by one lead developer.

 

The biggest key to getting source control figured out is to just keep trying new things with it. Until you create that feature branch and merge another developers changes in, you will always be scared of doing it. Source control is one area where each developer should push themselves to learn the system and terminology and not be afraid to try things with it. It is source control after all, you can always revert your changes :)

 

If you want more information of source control basics, Kalid Azad has a great introductory article here and a good distributed source control article here. Also I take no credit for the fancy source control diagrams, they are straight from the linked article.

Your rating: None Average: 2.3 (3 votes)

Comments

your blog is looking good!

your blog is looking good!