Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

6 Answers 6

up vote 14 down vote accepted

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.

share|improve this answer
2  
I think it's because the various projects try so hard to push the "distributed" nature of their systems. For me, the "central repository" is the one we pull production from. –  Peter Rowell May 7 '11 at 5:28
1  
You can have a central repository. You don't have to. –  user1249 May 7 '11 at 8:28
    
Excellent point. My team uses "central" git repositories for our projects. They are shared folders, not servers, but the benefits are all there. –  Ryan Lynch May 7 '11 at 19:26

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 I should consider or not consider Mercurial or Git or any other DVCS?

share|improve this answer

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

share|improve this answer

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.

share|improve this answer
    
Heh, "root" canal... –  Maxpm May 7 '11 at 5:37
1  
Be fair now, branching with svn has always been easy. It's merging that drives people insane. –  Karl Bielefeldt May 7 '11 at 18:18
    
@Karl: You are absolutely correct! –  Peter Rowell May 7 '11 at 18:19

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.

share|improve this answer
    
git has a CVS emulator which may be exactly what you need at work - kernel.org/pub/software/scm/git/docs/git-cvsserver.html –  user1249 May 7 '11 at 20:38
    
Thanks, I'll look into it. –  rupjones May 8 '11 at 3:22

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:

  1. Your devs understand version control best practices and follow them. No particular product will make you better unless this is the case (though DVCSs tend to nudge you the right direction).
  2. You're not choosing SourceSafe. Nothing will save you if this is the case.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.