There are a lots of flame wars out there about the best DVCS (Distributed version control system), like others (IMHO) ego wars (KDE vs GNOME, VIM vs EMACS, etc). There are very good options like git, mercurial, bazaar or darcs and many people (as GNOME is doing right now with all the survey thing).
Even in my company, we were (actually, we’re already) discussing about the right one for our day by day at work. We’re almost sure to adopt a good dvcs is better than our well known Subversion, but we don’t know the best option.
We could follow the typical technical reasons people usually does, but we must also pay attention to other (more practical) reason. For example, we develop linux distributions (mostly) based on Ubuntu, so that tell us we should use bazaar to make easy clones, branches, merges and any kind of tasks in order to collaborate.
But, in other hand, we work with rails. Rails and projects around use git intensively, so makes sense to use git as well.
And we also work with other projects which still use subversion or even others systems.
After think about the best possibility it’s clear for me that choose just one makes no sense at all. We can choose one for working internally, but we’ll still have to deal with with other system we work or collaborate with.
Our major project is the technical level and background of the people here is very heterogeneous. We got very geek guys and people who just got out from the university and don’t know to much about real life tools…
So, we need something with learning curve small enough to normal people could just use the dvcs and good enough to use in professional projects.
But I really think the best way, at last, is to learn the basics of each one (of the most common ones), use internally just a good one, but bring to the people the way to use whatever they want or need for each project. I think John is right about that… why to choose for the people? Let’s people decide by themselves.
I was talking with Alberto about this and we agree (didn’t we? :-P) that to have a kind of interface which makes abstraction about which dvcs is below and gives us compatibility between them, probably is better than try to push people to one or another system just because we think is the best.
There ar to much big (and little ones) projects which have already chosen git, bazaar, mercurial or other and are very happy with their decision to just change because someone say so…
I don’t think to expect that is very realistic…
I know this is possible and we as open source and free software people doing all the time: make open standards, communication APIs, and abstractions layers. I don’t see more complex than a lot of projects (GNOME itself) does al the time.
I think I will sum myself to the John’s count he is meaning to do something similar 🙂
Unfortunatly my experience about abstract interface is that you will lose the advantages of all the systems, and keep only what they can all manage.
Different projects choose different VCS’s and developers interacting with them obviously adapt. Being opinionated and not burdening people with unnecessary choices is a good thing, and GNOME as a project should make a decision to use one, just as Rails, Ubuntu etc did. Trying to please everybody in a huge community is not the way to go IMO. Not to mention the burden from the sysadmin point view.
Pascal: Yes, you’re right, but I think the most of the advantages come from the local thing of those systems, so doesn’t really matters so much how you store and serve the code plus the metadata. The only thing that matters is you can use your local branches and comunucate with upstream with no troubles.
Marko: Yes, of course, but I think those VCSs spend too much time to be differents and “the best”, than to be compatibles and maybe that could be the point. If the VCSs are compatibles, you don’t need maintain 3 mirros of the same code and almost the same metadata, converting all the time and checking those conversions…. (which is what actuallly can make harder the sysadmin work…). We’ll just have one system and we serve the code and the metadata in one single place, but people can still use git, hg, bzr or whatever this layer support.