Distributed Source Control systems in FLOSS communities

Git logoThe final instance of the posts about the different tools used by an open source community is the core and most important part. After all software is usually ran by code. And code is what gives developers the upper hand in using the final liberties of the free software rights. The right to modify it’s code.

So how does people modify it’s code? Well there are some standard tools that allow to keep track of all the modifications of the code. These systems are called differently but you can identify SCM, or DSCM which enable developers to perform ‘commits’ on the code and keep a version of those modifications.

Here is an example, lets assume this story is being modified by 3 developers: john, patric and bob:

When I was little I had a pony.

John comes and add:

When I was little I had a pony, the pony was named katy.

John has created a new version of the story, however the previous version still exist and patric can compare the new version to the old one. The tool used here is called, diff for differential:

Ver #01 – – When I was little I had a pony.

Ver #02 ++ When I was little I had a pony, the pony was named katy.

Patric can see here where has this been modified. He can apply corrections to it by renaming the pony katy to Katy for example, and Bob could eventually see the version 02 to the new 03 version, or 03 to 01 and see how it’s different.

Code in software behave like this except it also take into account the history of the files and folders itself.

A DSCM system will usually have plugins to connect it to the web. This makes it easier for people to see and learn how the version management take place. If you ever been in sourceforge, google code, or any big open source development project you will be able to see this systems.

More to it, the DSCM could be connected with mailing lists and provide email notifications on any change happening on the source tree (what lives in the DSCM system).

Programers more involved with things like Github can be more related with how these source trees work, and how branches, and forks, take place. Github is a service tha provides some kind of social media withing the plain Git vesion control features as well as insert an Issue tracker to it.

Here comes a big difference in development, usually Git projects tend to be more distributed, while other versions of DSCM systems like Subversion, or CVS were monolitical. The difference is simple, while the code resides on your computer as well as on the system everytime you do a checkout, in git the changes are handled in a more distributed fashion as opposed to the earlier systems. This is why Git right now is the premier and favorite control.

However not all projects use git, and for the ones that don’t usually there was a level between been a commiter and being a casual programer doing some ‘hit n run‘ code. Meaning a random patch, but don’t expect to contribute again. These ‘hit n run’ programers usually couldnt submit their patch to the source tree, so a different system was used in that case. The issue tracker.

The issue tracker serves for creating and keep a track of issues, whenever is usability, documentation, testing and yes, programming bugs. A programmer that found a bug and fix it on it’s own, but holds no attachment to the project, will use the Issue tracker to report the bug and also attach a PATCH. This is the bit of code that was modified and is up for the team of developers to integrate it back into the source tree.

In a community there was a criteria to upgrade casual developers to commiters when they scored a certain ammount of succesful patches, and some other protocols were met (like signing a license code agreement) so the project can legally stand about the status of the code.

Commiters usually were required a gpg key to be able to sign their code, and be able to be approved by the DSCM system, otherwise the commit was rejected. This is also a key component of the FLOSS developer. More information could be found on their wiki stating each step of the way on becoming a contributor, but for the most part. The cycle is similar on all projects.