Versionning systems : centralized systems VS distributed ones.
I have decided to share with you some of my experiences I lived while working on Fyrtorn, my big android project (I hope you’ll hear of it sooner or later!). So today, I’ll talk about a very important point for any organized devvie… Versioning.
So, what is Versioning? Just to remind you guys, it’s a very nice system that stores every evolution of your code in a different version, so that you can retrieve any version anytime anywhere on any computer. Cool, eh ?
There are two main branches (no pun intended…? ) in the world of versioning : centralized versioning systems and distributed ones.
In Centralized systems, there is only one repository containing your sources, and it is located on your source server. When you want to modify your code, you have to upload the code on your machine, make your modifications on it, and then send everything back to the server. The latter will then create a new version based on these modifications. CVS or Subversion (SVN) use this versionning system.
Pros and cons :
- They were historically the first system to appear… so there are more internet servers supporting this technology than for distributed systems, although the most known ones are trying to support all of them.
- As there is only one centralized repository, it somehow limits bad surprises while creating a new version : since you ideally have to upload (commit) your code for each atomic improvement, it limits the size of modifications, and therefore avoids too big merging operations.
- It is less reliable than distributed versionning systems. Since it is all centralized, it is impossible to retrieve all your source history without having an access to the main server. And that makes a lot of data loss if this latter crashes.
As for Distributed systems, everything is located on the server. However, to make modifications to your project, you first have to clone the repository to create your own one locally: therefore, you can have some kind of “local versioning”, on which you can commit atomic modifications. Then, when you feel everything is ready, you can send all your commits to the main server, which takes them into account. Mercurial or Git are some common distributed versioning systems among others.
Pros and cons :
- You can always rollback to the last commit, or you can even cancel all your modifications. It makes distributed versioning really better for working locally.
- However, the presence of a local repository means that there will be bigger merging trouble if you ever forget to update…
- Still, the biggest advantage in versioning is that in case of a server crash, there are still many local repos available, since each teammate has to clone it on their computer to make any modification. That’s significantly less trouble in case of a server crash, believe me.
Which system is better? Well, this is another trolling question in the computer science community. In my opinion, Distributed systems are better, because of their reliability (which is something I value a lot, and which is the main raison d’être of versionning after all)… but you can do what you want, really.
Oh, and last point : avoid Visual SourceSafe at any rate. Really. I mean it. This will give you nightmares otherwise. Here’s a good article about why you shouldn’t.
And you, what do you use as a versioning system ?