When it comes to very small projects (just a few devs), how effective are distributed version-control systems (e.g., git) compared to systems with a central repository?
I like the idea of having a central repository because it seems much more elegant and organized. However, after watching Linus Torvalds's Google Talk, I have my doubts. Are all those benefits really noticeable with such a small project, though?
DVCS doesn't mean you can't have a central repository. I have no idea how so many people get that into their heads. Possible svn workflows are a subset of possible git workflows, so if you want to start out using git as simply as this, there's nothing stopping you. However, the reverse isn't true if you want to use distributed features later. Personally, I prefer to have options available I might never use, rather than later find I want to use an option that isn't available.
It largely depends on your developers.
If your developers are distributed (multiple locations, different time zones, possibly disconnected for periods of time (travel, etc.)), then distributed version control systems have a lot of advantages. I've been in the unfortunate situation of working on a centralized version control system across large distances and different time zones where checking in/out and branching were very slow, and the result is that everyone stops using version control properly. The learning curve for DVCS is higher, but in distributed situations the benefits often outweigh the curve.
If you devs are all in the same office working the same hours with lightning-fast connections to the server, checking in/out and branching are quick and easy. In that case, it comes down to learning curve and preference - if your devs are all old hands with Subversion, there's not a lot of reason to move to a DVCS. If they're all stoked about moving to a DVCS, they'll learn it fast enough.
All of this assumes that:
I mostly work solo, but I'm adamant about everything going through Mercurial. It allows me to be working on different tasks, with different development timelines, but still be able to respond quickly to a client's need for a new feature. It makes having several different branches so easy I almost don't think about it anymore. With SVN (and CVS and RCS and SCCS) branching merging was so painful I'd rather have root canal work done without an anesthetic.
I have one website where I have two non-techies modifying Django templates and such, and they needed about 5 minutes training (and a couple of scripts) to be able to use hg to update, commit, and push to staging and then to production. They particularly like the built-in web server that shows who did what and when.
I think the advantages of a distributed version control system are apparent on any scale. I'm going to refer to git from now on, since that is the DVCS that I have the most experience with, and it's easier to say and read than DVCS.
I really look at the advantages of centralized version control systems as a subset of the advantages of git. If you want to have a central repository with git, go ahead. It can be on a server if you like, just like your SVN server; or it can be on a network drive, or even a usb stick. You can connect to your central repository commit, just like you can with CVS; or you can spend the day working in the park without an internet connection, commit all you like, then push to your server at the end of the day. I prefer the latter.
My development team is small, we vary between 3-5 developers depending on the project we are working on. Our work environment has strange constraints that make a centralized system difficult to implement. Instead we use Git to allow us to coordinate our work between the various independent networks we develop in. The real advantage of Git, or any DVCS, is that it lets you stop thinking in terms of physical development resources: servers, developers, parks; and frees you to think purely in terms of branches and time, which are the true dimensions in VCS space.
That's all I have to say that's somewhat original, here are some links that should prove more informative:
http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/
http://tom.preston-werner.com/2009/05/19/the-git-parable.html
Perhaps another extensive answer I made here will help you understand about how DVCSs work (it has diagrams =P): I'm a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?
It's not just coordinated control across a common set of files. The versioning capabilities of VCS are extremely useful when you're doing any kind of development "in anger". Distinct markers on versions, and the ability to track changes across the life of the application immediately come to mind. Most automated build systems (bamboo, hudson, teamcity etc) assume that you'll be working with a VCS.
As an aside, I've resisted introducing git at work, as I simply don't trust some of the people I work with to be able to competantly use it. Subversion (or CVS) suits our environment perfectly.
