Why is distributed source control considered harder?

Question

It seems rather common (around here, at least) for people to recommend SVN to newcomers to source control because it's "easier" than one of the distributed options. As a very casual user of SVN before switching to Git for many of my projects, I found this to be not the case at all.

It is conceptually easier to set up a DCVS repository with git init (or whichever), without the problem of having to set up an external repository in the case of SVN.

And the base functionality between SVN, Git, Mercurial, Bazaar all use essentially identical commands to commit, view diffs, and so on. Which is all a newcomer is really going to be doing.

The small difference in the way Git requires changes to be explicitly added before they're committed, as opposed to SVN's "commit everything" policy, is conceptually simple and, unless I'm mistaken, not even an issue when using Mercurial or Bazaar.

So why is SVN considered easier? I would argue that this is simply not true.

Answer 1

If you use the version control only for yourself, SVN is probably harder, since the setup is harder. If you however want to work with multiple developers over the web, a server side control has advantages:

• You have one central place, that always has the official state-of-the-art source, being the SVN server
• Since everyone always merges his changes against a central server, there are much less collisions and much less manual fixing of collisions
• You have central control over the source
• You have an official revision number instead of a revision hash, being the same among all developers and showing the official progress (it's an up counting number, unlike a hash, which is just an identity fingerprint, so you can see which code is newer or older, just by this number

Answer 2

A distributed versioning system is A Very Good Thing (tm), but I find the primary barrier to adoption being educating users on the new possibilities a new SCM gives.

This coupled with an often lack-luster amount of UI tools (half-finished tortoise implementations etc), brings a blank stare to the eye of many co-workers who long since foreswore the commandline for the sake of a good UI tool.

Also, with tools like CVS I find that people loathe branching and merging because they really really don't want to be stuck an entire day doing three way merges, often not really sure which would be the right merge to do.

My point is: Start out by telling people what they gain (not just "hey watch this new cool toy"), and prep them to the fact that using a commandline IS the way to go and that frequent constant time branching is a good thing.

Many systems such as mercurial comes with complete patch-queue system, meaning that from a Continuous Integration standpoint you know that whatever goes into production has been approved by QA. Stuff like this is hard to do properly with CVS or SVN.

With Mercurial people would have private repositories for their current work and all developers share a developer-tree on a server. The CI system monitors the developer-tree and pulls all changes, builds, and performs unittests. If everything passes it propagates the changes to a Testing-tree from where a deliverable is built for the QA persons. Every changeset that is added gets a token. When QA deems a feature to be complete, they annotate the Testing tree with this token, and the associated changesets are then automatically propagated to the Production-tree.

Using this approach you will never commit anything by hand to the production branch, or the testing branch. Rather the state of the code, and the sign off from QA determines the contents of your production branch,