We are bootstrapping a new team of very small size (say 2-5) my question is: which type of version control works best for these kind of teams, either centralized or distributed.
closed as too broad by gnat, Kilian Foth, GlenH7♦, Dan Pichelman, user40980 Sep 4 '14 at 14:45
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Distributed all the way, there is really no point for centralized anymore IMHO, specially if you are talking about team development.
Another vote for Mercurial, no hassles to setup under windows and bitbucket.org has free repositories (that can be private) with unlimited space.
If you are planning to work on a open source project, git and Github seem to be more adequate/popular. However, if you haven't ventured into DVCSs, I recommend you start with Mercurial and this awesome guide.
the one that you will all use consistently
[personally, i like Mercurial]
Probably the best answer is "whatever you're comfortable with." Even when working on personal stuff, I use Git. It seems to do a pretty good job of scaling both up and down and my limited experience with Mercurial is about the same.
I think you should choose whatever you are comfortable with. In a small team, you will not have different code-trees (like the Linux-kernel), so a central repository is OK. But you can have this setup also with distributed VCS. So I would go with popularity and personal experience. Popular are SVN, git and Mercurial. You should decide, which o them is best used with your team (experience, tool-support in your choosen IDE etc.).
It really depends of whether or not your developers are going to develop a lot of code offline or not, but only to choose between a distributed or centralized repository, since this is the first thing you should decide. Then, if you decide that a centralized approach works better than SVN is all you need. On the other side if you go for a distributed approach than go for git, even on windows it's good enough since now you have tortoise git (the same interface that also exists for svn). Also, don't count so much on the IDE support because you might get a nasty surprise if you ever use that, and you might find that files that shouldn't be commit do get committed in your behalf by the IDE.
Ask your team, if some one want to take care of it. It is much better to have stable system, and responsible person, than good system when none care about it, and none able to restore it from backup.
If there is such person - he will already know what to use, so just accept his decision. If not - get some hosted solution. It would be very stupid try GIT (one of the best) if all of developers never touched Shell/Linux.
It also depends of number of "nontechnical" people, that need to read/contribute. Just make sure that they could use it, and there are tools available.
SVN is widely supported in tools. Tooling is the key; different people will have different skill sets. Some will prefer command line, some will prefer IDE based tools, some will prefer graphical tools. At the moment SVN seems to be the most widely supported tool.
Other than that Mercurial or Git.
I think that in small companies there are arguments for having certain things centralized. (Think for example about offsite backup. When you only have 2 persons working on a project and they are housing in the same building and there is a fire, decentralized to all of two computers might not be enough.)
However: having a partly centralized solution doesn't limit you to a centralized system. You can just push to an outside server with something like git or mercurial.