What is a modern source code repository for small companies?

What is currently (2011) the recommendation source code repository for a company with only one location.

The distributed repositories are to difficult because there are 2 steps to checkout and checkin. There is a completely copy of the repository on every system. This are approx. 50 GB with our current system. This consume many time if you want checkout a fresh system. There is no backup of the local systems. etc.

Currently we use subversion. But subversi开发者_运维百科on has large problems with merging.

An Eclipse plugin will be very nice because this is our used IDE.

Is there any new star on the horizon?

What is currently (2011) the recommendation source code repository for a company with only one location.

Git or Mercurial.

The distributed repositories are to difficult because there are 2 steps to checkout and checkin.

Sounds to me like you see DVCSes as "Subversion but distributed". They are not so and thinking about them like that will make you miss their advantages.

There are no two steps to commit for DVCSes. There are two steps for commit with Git (stage, then commmit), but that's a Git feature, not a DVCS feature.

I think (please correct me if I'm wrong) that you consider the two steps to be the commit (local) and push (to a central repository). You only need to do that if you want each and every change made by each and every developer to be immediately available to the others.

With centralized systems (i.e. SVN) that is simply unavoidable. With DVCS you can use commits to be backup points instead of publishings.

The difference is that in SVN you cannot afford to commit code that is incomplete, because it affects the whole team (you do, and until you fix it nobody in the team will have usable code). In DVCS you commit (and merge) as you wish (locally) and only synchronize when you have something stable. Once you get used to it, "the SVN way" looks to be unnecessarily constricting.

The way we worked with DVCS was as follows: we (8 developers or so) had one central repository that was synchronized weekly, before each internal release (to the testing team). Each of us would synchronize their sources before the build (pull changes from the server, merge, pull). Then, one of us would make a build on the server machine.

Many times we would have two colleagues working on two sides of a new feature, and synchronizing beta-code only between ourselves. When we would have something stable, we would put it on the server. In the mean time, the other developers didn't have to see incomplete or broken code and the central codebase was kept stable, while we could still commit and have full benefits of source control.

There is a completely copy of the repository on every system.

This is good. It means that by virtue of creating a local repository you have 100% full redundancy and the server single failure point is effectively eliminated. If your server HDD crashes, you just clone a local repository from one of the developers to the new server HDD.

This are approx. 50 GB with our current system.

But you only synchronize them once per client. After the initial synchronization all subsequent ones are incremental.

This consume many time if you want checkout a fresh system.

You might be surprised. Both Hg and Git compress data before transfer (I'm not sure if SVN does that) and they also compress the repository itself. Considering that these systems store changes instead of files (i.e. change deltas, not full files) the repository might be smaller using a DVCS than when using SVN.

The downside (you can read that "the upside" if you consider redundancy and backup issues) is that you copy the full repository locally with each cloning process.

There is no backup of the local systems.

There's just no need - backup of DVCS repositories is usually a non-issue. Each local system is a full copy of the central repository (containing full history) and the central repository is a full backup of each client repository (synchronized at each push/pull).

With one central repository and one developer you have 100+100% redundancy. With two developers, 100+200% redundancy.

It doesn't get safer than this.

Currently we use subversion. But subversion has large problems with merging.

Regarding merging, subversion is broken by design because it SVN doesn't store any metadata to decide how to merge (as SVN tracks files, not changes). When SVN merges, it tries to make educated guesses, which are in trivial cases OK. For non-trivial cases you end up trying to solve a complex (for humans) problem manually when it is your tool/computer that should be doing that.

As I just documented, the new star in term of Eclipse plugin is... a DVCS (Git through EGit).
While it may not be what you are after, I still point this out as the current "new star" on Eclipse, since all Eclipse projects are now on Git repos, and Eclipse is committed to provide a good support for Git tooling.

However, that includes many challenges as I put this new VCS in my enterprise environment, listed here:
"Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?"

• The size limits for Git is an important one: you cannot just create one repo and put everything (your 50GB) in it.
  You need to split your source base into several repos and externalize binaries to an artifact repository like Nexus (see "What is a repository").
• And then authentication issue needs to be addressed, mainly through a wrapper able to identify who is pushing/pulling: I use gitolite.