why to use a distributed vcs
almost a year ago i got my hands onto mercurial, a "new" bastard from the new and "hyped" distributed version control systems (vcs). i played around with it for a while and considered it pretty practical for my own needs, mostly for my own home brew software and some of my config files. until then i used mostly svn ... and so did fluxbox.
if you are working alone on some stuff, the distributed nature of the vcs doesnt really matter at first. but then, it does:
sitting at the airport without wifi i changed some of my config files and commited. i changed some work related project stuff and commited. without access to the company's vpn, because it is quite natural that some of the customers are not going to give you some visitor account so that you can transfer data "home" :) uh oh, danger danger. well, i could commit, store the stuff on the encrypted part of my laptop and then sync with the company repository when i am back home.
for fluxbox henrik and i played around with git as one of the other distributed vcs with a big "hype" in the last years (it was developed by linus for doing the version control at the linux kernel). at that time i had already some knowledge in using hg (which i still prefer for my stuff because it works much better on win32 [a must for the company i am working at]) but we wanted to test alternatives anyway to see what works better for fluxbox. henrik choose to use git at wayfinder where he works and so he become a bit pro-git and "anti"-hg just because he was more familiar with git. they work pretty much similar anyway, so i didn't really bothered and the rest of the gang didn't as well.
why did we even toying around with git / hg? i mean, we used svn for a couple of years, cvs before that. well, basically we went away from cvs for some reasons, partly because lack of features, partly because hosting the repository at sf.net started to suck. cvs was not available 24/7 (or better became a bit unstable on the servers from sf.net back then) and since the centralized nature of the vcs we decided to switch over to a more "reliable" alternative, which was berlios.de at those days. all was good until berlios.de seemed to have hit the same problems as sf.net some time before. but what if the central server does not work ... very unfortunate if you think of pushing changes to the server as well as fetching the latest changes.
another really important issue was, that for each new feature i had some directories with a fresh copy the current version. you can call it "branch" but it was not a real branch since it was not really tracked by the vcs. if each of us devs at fluxbox would have to make all the ideas public they are currently working on and pushing it into the one central repository, that place would become pretty much crowded. and that would be for useful stuff as well as for stuff that shouldn't see the daylight at all. so, i tended to not create a branch back in the cvs/svn days because some of the ideas were just rough material. but the downside was clear: no version control of my own code. bummer.
things are different now: i have my own little sandbox here, filled with some ideas PLUS the version control. if the central server we decided to use to publish the official fluxbox repository over at http://git.fluxbox.org/" dies or becomes unavailable ... well, thats bad for sure but all of the dev team PLUS all anonymous contributors can continue to keep track of their changes. and if the stuff from some of the contributors is worth sucking it into the main line of the project, well, thats just fine: it ends up in the main line as if the contributor had write access to the repository.
and thats better for all of us.
if you need a deeper and better explanation and/or further discussion in the topic of distributed vcs, then go and take a look over there.
