Having had a number of instances of merge problems and other difficulties with a large Subversion repository and a team of 10+ developers I'm considering whether SVN is the right tool and what else to consider? Primary system being managed is a large PHP web application with release cycles averaging 2-3 weeks apart and 4+ concurrent projects in active development at any time.

Is subversion the right system or should we adopt Git, Mercurial or something else?

  • 3
    Just a warning: This could very easily devolve into "my favorite system is" answers. Perhaps a better way of asking would be more along the lines of "Pros and Cons of different source control systems for this situation." – Michael K Jun 16 '11 at 19:31
  • Perforce has good merge features - but it's quite expensive. – ChrisF Jun 16 '11 at 19:41
  • 3
    On what basis should we recommend Git, Mercurial, or for that matter SCCS? I don't think there's anything like a single right answer for such a vague question, so all I could do is recommend my favorite. – David Thornley Jun 16 '11 at 19:43
  • 1
    What are your current painpoints? – user1249 Jun 16 '11 at 20:35

Subversion and CVS are both strongly centralized systems, and, as such, they're not well suited to teams that aren't.

GIT was programmed specifically to get around this. It's by nature decentralized. Now, this may cause it's own set of problems, but it might be worth trying if Subversion is letting you down.

  • 3
    You can make git behave like SVN, but you can't make SVN behave like git. – Rein Henrichs Jun 16 '11 at 19:55
  • @rein: I actually prefer SVN for my personal use, but for big collaborations? Git all the way. – Satanicpuppy Jun 16 '11 at 19:57

Do your developers generally work in locations where they will have a good network connection to your servers? If so, then SVN may be suitable. If not, consider a distributed VCS like git or Mercurial (since these are easier to work with when you don't always have a connection to a server).

Do your developers primarly use Windows machines? Then consider SVN or Mercurial (git does not support Windows as well as SVN and Mercurial).

  • Just FYI, Git works like a champion on Windows. I use it locally to connect to an SVN Repository everyday. See Cygwin or the git bash Shell.. (I also use pure git for other projects on Windows...) – edwardsmatt Jun 16 '11 at 23:08

For large teams, distributed version control is definitely the best way to go. The most popular ones are Git and Mercurial. They are pretty similar in most respects. The commands and workflow are nearly identical. The only difference I have encountered is that Mercurial is slightly more user-friendly (well, at least, there is generally less typing involved), but Git is slightly faster (since it is written mostly in C while Mercurial is written mostly in Python).

  • Mercurial was much faster when I tried it, but that's because of the time spent looking for the extra commands I had to type just to get GIT to do things that Mercurial could do in one go. – Warren P Jun 17 '11 at 1:41
  • What I meant was that I found that Git was more high performance than Mercurial was. Pulls and pushes seemed to go a lot faster with Git. But you are right, hg ci -Am "message" is a lot less typing than git add . ; git commit -am "message". – Zhehao Mao Jun 18 '11 at 14:45

I am currently working in an environment very similar to what you describe @Bob. (Except Java instead of PHP).

We have a couple of concurrent Subversion branches running at the moment, and I use git locally (as the other developers in the team do not use git) to manage merging across the branches.

I would suggest just give it a try in a sandboxed environment, you can maintain your Subversion Central Repository but have a local git repository and dcommit your local changes up to subversion.

See here for an example usage


Is free a concern, or will you consider commercial? BitKeeper is arguably the very best system out there, though it's also priced that way. Don't let their straight-out-of-the-90's website fool you, their product is first rate.

When I last used bitkeeper, merges were quite literally a non-issue. Working with branches is an integral part of using BitKeeper (so much so, you could easily create several a day) so merging changes was just a natural part of the development flow. And it pretty much always got the merge right automatically. Hand-merging code rarely had to be done.

Their customer support is quite good too -- if you call you'll almost certainly talk to one of the developers that wrote and/or designed the code you're asking about.

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